[jira] [Commented] (IGNITE-17274) Startup of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[
https://issues.apache.org/jira/browse/IGNITE-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561631#comment-17561631
]
Ignite TC Bot commented on IGNITE-17274:
{panel:title=Branch: [pull/10123/head] Base: [master] : Possible Blockers
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Compatibility){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6660612]]
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6660613]]
{color:#d04437}Snapshots{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6660632]]
* IgniteSnapshotTestSuite:
EncryptedSnapshotTest.testSnapshotRestoringAfterMultipleReencryption[Encryption
is enabled.] - Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}JDBC Driver{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6660596]]
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testIntDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=null, backups=2, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=FULL_SYNC, persistenceEnabled=false,
useBinaryArrays=false] - Test has low fail rate in base branch 0,0% and is not
flaky
{color:#d04437}Cache 1{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=6660546]]
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6660622]]
* org.apache.ignite.testsuites.IgniteBinaryCacheQueryTestSuite2:
org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartDistributedJoinSelfTest.
- History for base branch is absent.
{color:#d04437}Queries 1 (lazy=true){color} [[tests 1 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6660621]]
* IgniteBinaryCacheQueryLazyTestSuite:
BasicIndexMultinodeTest.testEqualFieldsDynamicIndexesWithPersistence - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=6660615]]
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6660578]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryCounterReplicatedTxTest.testTwoQueryListener - Test has low
fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10123/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#8b}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6660622]]
* {color:#8b}org.apache.ignite.testsuites.IgniteBinaryCacheQueryTestSuite2:
org.apache.ignite.internal.processors.cache.distributed.near.IgniteCacheQueryNodeRestartDistributedJoinSelfTest.
- FAILED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6660650buildTypeId=IgniteTests24Java8_RunAll]
> Startup of large numbers of servers slowed by linear lookup in
> IgniteServiceProcessor
> -
>
> Key: IGNITE-17274
> URL: https://issues.apache.org/jira/browse/IGNITE-17274
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.13
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Using a small POC, spinning up many servers is slow. In addition, the
> startup time appears to be exponential.
> Using timing measurements, found a linear lookup inside the
> IgniteServiceProcessor that is taking most of the time.
> Replacing that linear lookup with a Map lookup, and maintaining the map,
> significantly speeds up the process, and startup time is now linear with the
> number of services started.
> Note this was tested with 20K and 50K services on a 1-node ignite cluster.
> Timings against the stock 2.13.0 code come in at 30s for 20K and 250s for 50K
> services. Modifying the linear lookup to use a Map, the timing come in at 8s
> for 20K and 14s for 50K services.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16054) Skipped attempt to connect to other TcpDiscovery nodes if SSL is enabled and first node from list is down.
[
https://issues.apache.org/jira/browse/IGNITE-16054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561545#comment-17561545
]
Dmitry Pavlov commented on IGNITE-16054:
[~shishkovilja] from your comment abover, I propose to reject this ticket as
can't reproduce.
> Skipped attempt to connect to other TcpDiscovery nodes if SSL is enabled and
> first node from list is down.
> --
>
> Key: IGNITE-16054
> URL: https://issues.apache.org/jira/browse/IGNITE-16054
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ivan Daschinsky
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: discovery, ise
> Attachments: IGNITE-16054_TcpDiscoverySslReconnectTest.patch,
> IGNITE-16054_TcpDiscoverySslWithWrongServerTest.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After IGNITE-4147, if node is attempting to connect to the first node and it
> is down, with enabled SSL, we mistakenly treat {{SSLException}} as handshake
> error and fail fast without attempts to connect to others.
> We should examine cause of {{SSLException}} anf if it is an instance of
> {{IOException}}, we should attempt to connect to other nodes.
> {code}
> 2021-12-02 15:19:06,003 [main] [ERROR]
> (org.apache.ignite.internal.IgniteKernal%7d657515-18b3-4189-a920-ba5040ad24ae)
> [org.apache.ignite.logger.java.JavaLogger::error:310] mdc:()| Got exception
> while starting (will rollback startup routine).
> org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1973)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1324)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> ru.XX.XX.common.core.IgniteCacheConfiguration.igniteInstance(IgniteCacheConfiguration.java:20)
> at
> ru.XX.XX.common.core.IgniteCacheConfiguration$$EnhancerBySpringCGLIB$$d8cb8bdc.CGLIB$igniteInstance$1()
> at
> ru.XX.XX.common.core.IgniteCacheConfiguration$$EnhancerBySpringCGLIB$$d8cb8bdc$$FastClassBySpringCGLIB$$38a3b050.invoke()
> at
> org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244)
> at
> org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331)
> at
> ru.XX.XX.common.core.IgniteCacheConfiguration$$EnhancerBySpringCGLIB$$d8cb8bdc.igniteInstance()
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:653)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:638)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1334)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1177)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:564)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:524)
> at
>
[jira] [Commented] (IGNITE-17269) Java service interceptor
[
https://issues.apache.org/jira/browse/IGNITE-17269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561534#comment-17561534
]
Ignite TC Bot commented on IGNITE-17269:
{panel:title=Branch: [pull/10128/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10128/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [[tests
6|https://ci2.ignite.apache.org/viewLog.html?buildId=6502683]]
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testOrder[clusterSingleton=false,
sticky=false] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testException[clusterSingleton=false,
sticky=false] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testOrder[clusterSingleton=true, sticky=true]
- PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testException[clusterSingleton=true,
sticky=true] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testOrder[clusterSingleton=false, sticky=true]
- PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
IgniteServiceCallInterceptorTest.testException[clusterSingleton=false,
sticky=true] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6502702buildTypeId=IgniteTests24Java8_RunAll]
> Java service interceptor
>
>
> Key: IGNITE-17269
> URL: https://issues.apache.org/jira/browse/IGNITE-17269
> Project: Ignite
> Issue Type: Sub-task
> Components: managed services
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-79, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement interceptor for java service.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17274) Startup of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561530#comment-17561530 ] Pavel Tupitsyn commented on IGNITE-17274: - Changes look good to me. TC build started: https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/6660650 > Startup of large numbers of servers slowed by linear lookup in > IgniteServiceProcessor > - > > Key: IGNITE-17274 > URL: https://issues.apache.org/jira/browse/IGNITE-17274 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.13 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Fix For: 2.14 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Using a small POC, spinning up many servers is slow. In addition, the > startup time appears to be exponential. > Using timing measurements, found a linear lookup inside the > IgniteServiceProcessor that is taking most of the time. > Replacing that linear lookup with a Map lookup, and maintaining the map, > significantly speeds up the process, and startup time is now linear with the > number of services started. > Note this was tested with 20K and 50K services on a 1-node ignite cluster. > Timings against the stock 2.13.0 code come in at 30s for 20K and 250s for 50K > services. Modifying the linear lookup to use a Map, the timing come in at 8s > for 20K and 14s for 50K services. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17293) Fix Netty buffer leak in MarshallableTest
[ https://issues.apache.org/jira/browse/IGNITE-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561525#comment-17561525 ] Roman Puchkovskiy commented on IGNITE-17293: Thanks! > Fix Netty buffer leak in MarshallableTest > - > > Key: IGNITE-17293 > URL: https://issues.apache.org/jira/browse/IGNITE-17293 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 20m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=all=6659100=all&_focus=3590] > > [org.apache.ignite:ignite-network] 2022-07-01 13:34:40:579 +0300 > [ERROR][main][ResourceLeakDetector] LEAK: ByteBuf.release() was not called > before it's garbage-collected. See > https://netty.io/wiki/reference-counted-objects.html for more information. > Recent access records: > Created at: > io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:96) > io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) > io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:174) > io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:108) > org.apache.ignite.internal.network.serialization.MarshallableTest.read(MarshallableTest.java:150) > org.apache.ignite.internal.network.serialization.MarshallableTest.testMarshallable(MarshallableTest.java:84) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17294) Fix flaky test SqlViewExporterSpiTest#testComputeBroadcast
Amelchev Nikita created IGNITE-17294:
Summary: Fix flaky test SqlViewExporterSpiTest#testComputeBroadcast
Key: IGNITE-17294
URL: https://issues.apache.org/jira/browse/IGNITE-17294
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The compute task finishes before a view query execution due to an error on
not-local node:
{noformat}
Caused by: java.lang.IllegalMonitorStateException
at
java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:151)
...
org.apache.ignite.internal.processors.cache.metric.SqlViewExporterSpiTest.lambda$testComputeBroadcast$450c1f96$1(SqlViewExporterSpiTest.java:237)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14207) Access to system views is not controlled by security processor
[
https://issues.apache.org/jira/browse/IGNITE-14207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-14207:
---
Labels: ise (was: )
> Access to system views is not controlled by security processor
> --
>
> Key: IGNITE-14207
> URL: https://issues.apache.org/jira/browse/IGNITE-14207
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now, it is impossible to restrict access to system views (SYS scheme)
> with {{IgniteSecurityProcessor}}; this should be fixed.
> Suggestions:
> - add new {{SecurityPermission}};
> - authorize this permission before accessing any system view.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17203) SQL API: Implement scale and precision metadata
[ https://issues.apache.org/jira/browse/IGNITE-17203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561498#comment-17561498 ] Pavel Tupitsyn commented on IGNITE-17203: - [~amashenkov] I don't think .NET limitations should dictate server-side precision and scale. Let's support what we can according to SQL standard and deal with .NET and other platform limitations separately. > SQL API: Implement scale and precision metadata > --- > > Key: IGNITE-17203 > URL: https://issues.apache.org/jira/browse/IGNITE-17203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > *scale()* and *precision()* in *ColumnMetadata* interface return incorrect > values. Implement them properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17277) Add a user info to the sql queries view
[
https://issues.apache.org/jira/browse/IGNITE-17277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561490#comment-17561490
]
Ignite TC Bot commented on IGNITE-17277:
{panel:title=Branch: [pull/10124/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10124/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6659737]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite3:
SystemViewSecurityTest.testSqlQueryView - PASSED{color}
{color:#8b}Queries 3 (lazy=true){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6659214]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite3:
SystemViewSecurityTest.testSqlQueryView - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6659239buildTypeId=IgniteTests24Java8_RunAll]
> Add a user info to the sql queries view
>
>
> Key: IGNITE-17277
> URL: https://issues.apache.org/jira/browse/IGNITE-17277
> Project: Ignite
> Issue Type: Improvement
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add a user info who started a query to the queries system view.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17062) Add ability to process local events synchronously
[
https://issues.apache.org/jira/browse/IGNITE-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561477#comment-17561477
]
Vladislav Pyatkov commented on IGNITE-17062:
[~Denis Chudov] In general, it looks good to me.
I left several minor comments in the PR.
> Add ability to process local events synchronously
> -
>
> Key: IGNITE-17062
> URL: https://issues.apache.org/jira/browse/IGNITE-17062
> Project: Ignite
> Issue Type: Task
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Local events (org.apache.ignite.internal.manager.Event) logic should be
> reworked a bit in order to await all subscribers to process corresponding
> event before publishing the action. Let's check an example of an expected
> behavior:
> # TableManager prepares table for creation.
> # TableManager notifies all subscribers with Table.CREATE event propagating
> to-be-created table.
> # TableManager (with the help of
> org.apache.ignite.internal.manager.Producer) awaits all subscribers to
> acknowledge that Table.CREATE event was successfully processed. E.g.
> SqlQueryProcessor prepares calcite schemes and sends ack by completing
> event's Future like it's done within ConfigurationRegistry events.
> # TableManager on Compound-Like-Future.allOff(events) publishes
> corresponding action, e.g. makes table visible to everyone.
> Proposed solution is very similar to what we already have in
> ConfigurationRegistry
> {code:java}
> public interface ConfigurationListener {
> /**
> * Called on property value update.
> *
> * @param ctx Notification context.
> * @return Future that signifies the end of the listener execution.
> */
> CompletableFuture onUpdate(ConfigurationNotificationEvent ctx);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17293) Fix Netty buffer leak in MarshallableTest
Roman Puchkovskiy created IGNITE-17293: -- Summary: Fix Netty buffer leak in MarshallableTest Key: IGNITE-17293 URL: https://issues.apache.org/jira/browse/IGNITE-17293 Project: Ignite Issue Type: Bug Components: networking Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha6 [https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=all=6659100=all&_focus=3590] [org.apache.ignite:ignite-network] 2022-07-01 13:34:40:579 +0300 [ERROR][main][ResourceLeakDetector] LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information. Recent access records: Created at: io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:96) io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:174) io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:108) org.apache.ignite.internal.network.serialization.MarshallableTest.read(MarshallableTest.java:150) org.apache.ignite.internal.network.serialization.MarshallableTest.testMarshallable(MarshallableTest.java:84) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17288) Fix broken links in Javadoc
[ https://issues.apache.org/jira/browse/IGNITE-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17288: Ignite Flags: (was: Docs Required,Release Notes Required) > Fix broken links in Javadoc > --- > > Key: IGNITE-17288 > URL: https://issues.apache.org/jira/browse/IGNITE-17288 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to fix the the following failed links in javadocs: > Failed link: http://gee.cs.oswego.edu/dl/papers/fj.pdf > Failed link: > http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17288) Fix broken links in Javadoc
[ https://issues.apache.org/jira/browse/IGNITE-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17288: Component/s: documentation > Fix broken links in Javadoc > --- > > Key: IGNITE-17288 > URL: https://issues.apache.org/jira/browse/IGNITE-17288 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to fix the the following failed links in javadocs: > Failed link: http://gee.cs.oswego.edu/dl/papers/fj.pdf > Failed link: > http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17288) Fix broken links in Javadoc
[ https://issues.apache.org/jira/browse/IGNITE-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17288: Fix Version/s: 2.14 > Fix broken links in Javadoc > --- > > Key: IGNITE-17288 > URL: https://issues.apache.org/jira/browse/IGNITE-17288 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to fix the the following failed links in javadocs: > Failed link: http://gee.cs.oswego.edu/dl/papers/fj.pdf > Failed link: > http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17288) Fix broken links in Javadoc
[ https://issues.apache.org/jira/browse/IGNITE-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561471#comment-17561471 ] Pavel Tupitsyn commented on IGNITE-17288: - Merged to master: d84d4451385b4cbcd6feb44726ee9c2b8d18b9a1 > Fix broken links in Javadoc > --- > > Key: IGNITE-17288 > URL: https://issues.apache.org/jira/browse/IGNITE-17288 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We need to fix the the following failed links in javadocs: > Failed link: http://gee.cs.oswego.edu/dl/papers/fj.pdf > Failed link: > http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17288) Fix broken links in Javadoc
[ https://issues.apache.org/jira/browse/IGNITE-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561458#comment-17561458 ] Igor Gusev commented on IGNITE-17288: - [~ptupitsyn] Please review and merge. > Fix broken links in Javadoc > --- > > Key: IGNITE-17288 > URL: https://issues.apache.org/jira/browse/IGNITE-17288 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We need to fix the the following failed links in javadocs: > Failed link: http://gee.cs.oswego.edu/dl/papers/fj.pdf > Failed link: > http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17203) SQL API: Implement scale and precision metadata
[ https://issues.apache.org/jira/browse/IGNITE-17203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561437#comment-17561437 ] Andrey Mashenkov commented on IGNITE-17203: --- I've jfound we use Short.MAX_VALUE as max precision and scale for numeric types. AFAIK, decimal in .NET is limited with 38 digits. What is a use case that requires support for such large values? > SQL API: Implement scale and precision metadata > --- > > Key: IGNITE-17203 > URL: https://issues.apache.org/jira/browse/IGNITE-17203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 10m > Remaining Estimate: 0h > > *scale()* and *precision()* in *ColumnMetadata* interface return incorrect > values. Implement them properly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17292) [Ignite Website] Ignite Summit 2022_Update website banners
Evgenia created IGNITE-17292:
Summary: [Ignite Website] Ignite Summit 2022_Update website banners
Key: IGNITE-17292
URL: https://issues.apache.org/jira/browse/IGNITE-17292
Project: Ignite
Issue Type: Task
Components: website
Reporter: Evgenia
Attachments: Ignite Summit events.jpg, docs.jpg, ignite-Summit.jpg
Please add a new Ignite Summit and update event banners.
All the links should lead to [https://ignite-summit.org/2022-june]
Places to update banners:
1) Featured events
[Distributed Database - Apache Ignite|https://ignite.apache.org/]
2) Doc's banner
[https://ignite.apache.org/docs/latest/]
3) Text banner at the top (doc's page)
Change from {color:#FF}[Virtual Ignite Summit—June 14th—Full
Agenda|https://ignite-summit.org/2022-june/schedule/]{color} to Ignite
Summit—June 2022—Recordings Now Available!
([https://ignite-summit.org/2022-june])
4) Update event page with a new image
[Apache Ignite Events - Meetups, Summit,
Conference|https://ignite.apache.org/events.html#summit]
Images attached
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17240) Provide an ability to configure logging backend through IgniteClient.Builder
[
https://issues.apache.org/jira/browse/IGNITE-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561424#comment-17561424
]
Pavel Tupitsyn commented on IGNITE-17240:
-
[~korlov]
Client-related changes look good to me.
However, there are many changes that are not related to the client, is that
intentional?
> Provide an ability to configure logging backend through IgniteClient.Builder
>
>
> Key: IGNITE-17240
> URL: https://issues.apache.org/jira/browse/IGNITE-17240
> Project: Ignite
> Issue Type: Improvement
> Components: clients
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> Need to extend {{org.apache.ignite.client.IgniteClient.Builder}} in order to
> provide an ability to specify {{{}LoggerFactory{}}}, where {{LoggerFactory}}
> is the following interface:
>
> {code:java}
> public interface LoggerFactory {
> default System.Logger forClass(Class clazz) {
> return forName(Objects.requireNonNull(clazz).getName());
> }
>
> System.Logger forName(String name);
> } {code}
> The configured backend should be stored within
> {{{}org.apache.ignite.client.IgniteClientConfiguration{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17219) Revise types support in schema module
[ https://issues.apache.org/jira/browse/IGNITE-17219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561420#comment-17561420 ] Pavel Tupitsyn commented on IGNITE-17219: - [~zstan] I've mostly reviewed the parts related to client protocol. Looks good to me. > Revise types support in schema module > - > > Key: IGNITE-17219 > URL: https://issues.apache.org/jira/browse/IGNITE-17219 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Looks like not all types are properly integrated into the system: some of > them can't be serialised within SchemaDescriptor (temporal types), for some > of them default value is improperly converted from schemaDefinition to a > changer (byte array). > Lets extend test coverage in order to find out all such missed places and fix > them. Cases to consider: > * (de-)serialisation of all supported types and theirs default > * conversion from schemaDefinition to changer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-16760) Performance degradation of IgniteTables#tables after configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561378#comment-17561378
]
Denis Chudov edited comment on IGNITE-16760 at 7/1/22 11:10 AM:
After some discussions, we decided to make only tombstone skipping within the
work on this ticket. Other improvements will be done under other tickets (
IGNITE-16760 ).
was (Author: denis chudov):
After some discussions, we decided to make only tombstone skipping within the
work on this ticket. Other improvements will be done under other tickets.
> Performance degradation of IgniteTables#tables after configuration changes
> --
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> for (Table t : ign.tables().tables()) {
> ;
> }
> {code}
> On begin {{IgniteTables#tables}} takes ~ 0.7 sec.
> The time of the operation is grown.
> The time after ~100 iteration is about 20 sec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17193) Map IgniteException to problem json
[ https://issues.apache.org/jira/browse/IGNITE-17193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17193: - Issue Type: Improvement (was: Task) > Map IgniteException to problem json > --- > > Key: IGNITE-17193 > URL: https://issues.apache.org/jira/browse/IGNITE-17193 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 50m > Remaining Estimate: 0h > > According to https://www.rfc-editor.org/rfc/rfc7807.html HTTP API has to > return application/problem+json if an error happens. > https://cwiki.apache.org/confluence/display/IGNITE/IEP-84%3A+Error+handling > describes how Ignite 3 throws exceptions. > The aim of this ticket is to map IgniteException to application/problem+json. > Note, that there is no implementation of IEP-84. So, leave TODOs with Jira > tickets where it is needed. > Mapping strategy: > “title”: a short, human-readable summary of the problem type > “status”: HTTP status code > “code”: error code > “type”: URI to the error documentation (optional) > “detail”: a human-readable explanation of the problem (optional) > “invalid-params”: list of parameters that did not pass the validation > (optional) > “node”: Ignite 3 node name (optional) > “trace-id”: unique identifier that will help to trace the error in the log > (optional). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17291) Implement metastorage cursor batching
[
https://issues.apache.org/jira/browse/IGNITE-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17291:
-
Description:
In order to increase metaStorage.range() performance that currently retrieves
entries one by one it's possible to implement simple batching. As an initial
solution we might hardcode the batch-size.
Basically speaking it's required to update CursorNextCommand.
Instead of
{code:java}
Entry e = (Entry) cursorDesc.cursor().next();
clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter())); {code}
we might use something similar to
{code:java}
List batch = new ArrayList<>(RANGE_CURSOR_BATCH_SIZE);
for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
Entry e = (Entry) cursorDesc.cursor().next();
batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter()));
if (! cursorDesc.cursor.hasNext()) {
break;
}
}
clo.result(new MultipleEntryResponse(batch));{code}
It's not trivial to reimplement rocks cursors to also use batching, however
it's not that important because rocks cursors are always local.
was:
In order to increase metaStorage.range() performance that currently retrieves
entries one by one it's possible to implement simple batching. As an initial
solution we might hardcode the batch-size.
Basically speaking it's required to update CursorNextCommand.
Instead of
{code:java}
Entry e = (Entry) cursorDesc.cursor().next();
clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter())); {code}
we might use something similar to
{code:java}
for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
Entry e = (Entry) cursorDesc.cursor().next();
batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter()));
if (! cursorDesc.cursor.hasNext()) {
break;
}
} {code}
It's not trivial to reimplement rocks cursors to also use batching, however
it's not that important because rocks cursors are always local.
> Implement metastorage cursor batching
> -
>
> Key: IGNITE-17291
> URL: https://issues.apache.org/jira/browse/IGNITE-17291
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> In order to increase metaStorage.range() performance that currently retrieves
> entries one by one it's possible to implement simple batching. As an initial
> solution we might hardcode the batch-size.
> Basically speaking it's required to update CursorNextCommand.
> Instead of
> {code:java}
> Entry e = (Entry) cursorDesc.cursor().next();
> clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
> e.updateCounter())); {code}
> we might use something similar to
> {code:java}
> List batch = new
> ArrayList<>(RANGE_CURSOR_BATCH_SIZE);
> for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
> Entry e = (Entry) cursorDesc.cursor().next();
> batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
> e.updateCounter()));
> if (! cursorDesc.cursor.hasNext()) {
> break;
> }
> }
> clo.result(new MultipleEntryResponse(batch));{code}
> It's not trivial to reimplement rocks cursors to also use batching, however
> it's not that important because rocks cursors are always local.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17291) Implement metastorage cursor batching
[
https://issues.apache.org/jira/browse/IGNITE-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17291:
-
Description:
In order to increase metaStorage.range() performance that currently retrieves
entries one by one it's possible to implement simple batching. As an initial
solution we might hardcode the batch-size.
Basically speaking it's required to update CursorNextCommand.
Instead of
{code:java}
Entry e = (Entry) cursorDesc.cursor().next();
clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter())); {code}
we might use something similar to
{code:java}
for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
Entry e = (Entry) cursorDesc.cursor().next();
batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter()));
if (! cursorDesc.cursor.hasNext()) {
break;
}
} {code}
It's not trivial to reimplement rocks cursors to also use batching, however
it's not that important because rocks cursors are always local.
was:
In order to increase metaStorage.range() performance that currently retrieves
entries one by one it's possible to implement simple batching. As an initial
solution we might hardcode the batch-size.
Basically speaking it's required to update CursorNextCommand.
Instead of
{code:java}
Entry e = (Entry) cursorDesc.cursor().next();
clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter())); {code}
we might use something similar to
{code:java}
for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
Entry e = (Entry) cursorDesc.cursor().next();
batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter()));
if (! cursorDesc.cursor.hasNext()) {
break;
}
} {code}
> Implement metastorage cursor batching
> -
>
> Key: IGNITE-17291
> URL: https://issues.apache.org/jira/browse/IGNITE-17291
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> In order to increase metaStorage.range() performance that currently retrieves
> entries one by one it's possible to implement simple batching. As an initial
> solution we might hardcode the batch-size.
> Basically speaking it's required to update CursorNextCommand.
> Instead of
> {code:java}
> Entry e = (Entry) cursorDesc.cursor().next();
> clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
> e.updateCounter())); {code}
> we might use something similar to
> {code:java}
> for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
> Entry e = (Entry) cursorDesc.cursor().next();
>
> batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
> e.updateCounter()));
>
> if (! cursorDesc.cursor.hasNext()) {
> break;
> }
> } {code}
> It's not trivial to reimplement rocks cursors to also use batching, however
> it's not that important because rocks cursors are always local.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17291) Implement metastorage cursor batching
[
https://issues.apache.org/jira/browse/IGNITE-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17291:
-
Description:
In order to increase metaStorage.range() performance that currently retrieves
entries one by one it's possible to implement simple batching. As an initial
solution we might hardcode the batch-size.
Basically speaking it's required to update CursorNextCommand.
Instead of
{code:java}
Entry e = (Entry) cursorDesc.cursor().next();
clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter())); {code}
we might use something similar to
{code:java}
for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
Entry e = (Entry) cursorDesc.cursor().next();
batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
e.updateCounter()));
if (! cursorDesc.cursor.hasNext()) {
break;
}
} {code}
> Implement metastorage cursor batching
> -
>
> Key: IGNITE-17291
> URL: https://issues.apache.org/jira/browse/IGNITE-17291
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> In order to increase metaStorage.range() performance that currently retrieves
> entries one by one it's possible to implement simple batching. As an initial
> solution we might hardcode the batch-size.
> Basically speaking it's required to update CursorNextCommand.
> Instead of
> {code:java}
> Entry e = (Entry) cursorDesc.cursor().next();
> clo.result(new SingleEntryResponse(e.key(), e.value(), e.revision(),
> e.updateCounter())); {code}
> we might use something similar to
> {code:java}
> for (int i = 0; i < RANGE_CURSOR_BATCH_SIZE; i++) {
> Entry e = (Entry) cursorDesc.cursor().next();
>
> batch.add(new SingleEntryResponse(e.key(), e.value(), e.revision(),
> e.updateCounter()));
>
> if (! cursorDesc.cursor.hasNext()) {
> break;
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17219) Revise types support in schema module
[ https://issues.apache.org/jira/browse/IGNITE-17219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561405#comment-17561405 ] Evgeny Stanilovsky commented on IGNITE-17219: - [~ptupitsyn], [~korlov] can you make a review plz ? > Revise types support in schema module > - > > Key: IGNITE-17219 > URL: https://issues.apache.org/jira/browse/IGNITE-17219 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Looks like not all types are properly integrated into the system: some of > them can't be serialised within SchemaDescriptor (temporal types), for some > of them default value is improperly converted from schemaDefinition to a > changer (byte array). > Lets extend test coverage in order to find out all such missed places and fix > them. Cases to consider: > * (de-)serialisation of all supported types and theirs default > * conversion from schemaDefinition to changer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17291) Implement metastorage cursor batching
Alexander Lapin created IGNITE-17291: Summary: Implement metastorage cursor batching Key: IGNITE-17291 URL: https://issues.apache.org/jira/browse/IGNITE-17291 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17290) 2.8.1 IgniteAsyncCallback annotation doesnt seem to work .
Veena Mithare created IGNITE-17290:
--
Summary: 2.8.1 IgniteAsyncCallback annotation doesnt seem to work .
Key: IGNITE-17290
URL: https://issues.apache.org/jira/browse/IGNITE-17290
Project: Ignite
Issue Type: Bug
Environment: Ignite 2.8.1
Reporter: Veena Mithare
We have a cluster of 20 client nodes +3 server nodes on ignite version 2.8.1.
Around 10 nodes listen issue a continuous query to listen to updates from the
same cache. If for some reason tcpcommunication spi is not able to send the
cache update notification to one of the clients( because the client is
unreachable or network issue ), the rest of the clients get delayed updates .It
looks as if the process of sending notifications to clients is in a synchronous
loop.
Details of the issues observed are listed here :
[https://lists.apache.org/thread/tzzksk2cm4dwhd84bcswgosvbvjv01nq]
[https://lists.apache.org/thread/c9bksffx4xv0osz4388ljotmrqto6437]
Please note we do have IgniteAsyncCallBack annotation on our remote filter and
local listener .
@IgniteAsyncCallback
class RemoteCacheEntryEventFilter implements
CacheEntryEventFilter {
@IgniteAsyncCallback
class ProphetCacheEntryUpdatedListener implements
ContinuousQueryWithTransformer.EventListener {
We use ContinuousQueryWithTransformer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17284) Fix missing features on the Thin Clients documentation
[ https://issues.apache.org/jira/browse/IGNITE-17284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561384#comment-17561384 ] Maxim Muzafarov commented on IGNITE-17284: -- Merged to the master branch cherry-picked to 2.13 > Fix missing features on the Thin Clients documentation > --- > > Key: IGNITE-17284 > URL: https://issues.apache.org/jira/browse/IGNITE-17284 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > There is lack of DataStreamer support on our documentation pages: > https://ignite.apache.org/docs/latest/thin-clients/getting-started-with-thin-clients > The DataStreamer has been implemented for the .NET thin client. > https://issues.apache.org/jira/browse/IGNITE-14187 > Full list of supported features > https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features > Retry Policy are also implemented: > https://issues.apache.org/jira/browse/IGNITE-16026 > https://issues.apache.org/jira/browse/IGNITE-16025 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16970) IEP-88: CLI Tool
[ https://issues.apache.org/jira/browse/IGNITE-16970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin updated IGNITE-16970: --- Epic Name: IEP-88 (Apache Ignite CLI Project) (was: IEP-88) > IEP-88: CLI Tool > > > Key: IGNITE-16970 > URL: https://issues.apache.org/jira/browse/IGNITE-16970 > Project: Ignite > Issue Type: Epic >Reporter: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > Develop an advanced CLI Tool with an explicit focus on usability. > A user should download the tool from the website and then use it to: > * Connect to a cluster to monitor its state and perform management > operations (configuration changes, cluster init). > * Connect to a cluster to run SQL queries. > * Connect to a cluster to get the cluster status (topology, version). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16760) Performance degradation of IgniteTables#tables after configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561378#comment-17561378
]
Denis Chudov commented on IGNITE-16760:
---
After some discussions, we decided to make only tombstone skipping within the
work on this ticket. Other improvements will be done under other tickets.
> Performance degradation of IgniteTables#tables after configuration changes
> --
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> for (Table t : ign.tables().tables()) {
> ;
> }
> {code}
> On begin {{IgniteTables#tables}} takes ~ 0.7 sec.
> The time of the operation is grown.
> The time after ~100 iteration is about 20 sec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-16760) Performance degradation of IgniteTables#tables after configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-16760:
-
Assignee: Denis Chudov
> Performance degradation of IgniteTables#tables after configuration changes
> --
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> for (Table t : ign.tables().tables()) {
> ;
> }
> {code}
> On begin {{IgniteTables#tables}} takes ~ 0.7 sec.
> The time of the operation is grown.
> The time after ~100 iteration is about 20 sec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-16872) 'Invalid cross-device link error' exception when extending WAL segments size
[
https://issues.apache.org/jira/browse/IGNITE-16872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16872:
--
Assignee: Aleksey Plekhanov
> 'Invalid cross-device link error' exception when extending WAL segments size
>
>
> Key: IGNITE-16872
> URL: https://issues.apache.org/jira/browse/IGNITE-16872
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> If required WAL segments size is more than current WAL segments size
> (configuration changes) Ignite extend this size on startup (see
> {{{}FileWriteAheadLogManager#formatWorkSegments{}}}). To do this each segment
> copied to the new temp file, temp file is extended and temp file is moved to
> the original segment file (using {{ATOMIC_MOVE}} option). But temp files are
> created in the current work dir ({{{}file().getName(){}}} used instead of
> {{{}file().getAbsolutePath(){}}}:
> {code:java}
> File tmpDst = new File(fd.file().getName() + TMP_SUFFIX);
> {code}
> And if WAL path is configured to another device there can be an exception
> {{{}AtomicMoveNotSupportedException{}}}:
> {noformat}
> Caused by: java.nio.file.AtomicMoveNotSupportedException:
> .wal.tmp ->
> /opt/ignite/ssd/data/wal/consistentId/.wal: Invalid
> cross-device link
> at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:394) ~[?:1.8.0_321]
> at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> ~[?:1.8.0_321]
> at java.nio.file.Files.move(Files.java:1395) ~[?:1.8.0_321]
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.formatWorkSegments(FileWriteAheadLogManager.java:3471){noformat}
> We should create temp files in the same directory as WAL segments (on the
> same device).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17288) Fix broken links in Javadoc
[ https://issues.apache.org/jira/browse/IGNITE-17288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-17288: --- Assignee: Igor Gusev > Fix broken links in Javadoc > --- > > Key: IGNITE-17288 > URL: https://issues.apache.org/jira/browse/IGNITE-17288 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > > We need to fix the the following failed links in javadocs: > Failed link: http://gee.cs.oswego.edu/dl/papers/fj.pdf > Failed link: > http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17062) Add ability to process local events synchronously
[
https://issues.apache.org/jira/browse/IGNITE-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561367#comment-17561367
]
Denis Chudov commented on IGNITE-17062:
---
[~alapin] could you pls also help with review?
> Add ability to process local events synchronously
> -
>
> Key: IGNITE-17062
> URL: https://issues.apache.org/jira/browse/IGNITE-17062
> Project: Ignite
> Issue Type: Task
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Local events (org.apache.ignite.internal.manager.Event) logic should be
> reworked a bit in order to await all subscribers to process corresponding
> event before publishing the action. Let's check an example of an expected
> behavior:
> # TableManager prepares table for creation.
> # TableManager notifies all subscribers with Table.CREATE event propagating
> to-be-created table.
> # TableManager (with the help of
> org.apache.ignite.internal.manager.Producer) awaits all subscribers to
> acknowledge that Table.CREATE event was successfully processed. E.g.
> SqlQueryProcessor prepares calcite schemes and sends ack by completing
> event's Future like it's done within ConfigurationRegistry events.
> # TableManager on Compound-Like-Future.allOff(events) publishes
> corresponding action, e.g. makes table visible to everyone.
> Proposed solution is very similar to what we already have in
> ConfigurationRegistry
> {code:java}
> public interface ConfigurationListener {
> /**
> * Called on property value update.
> *
> * @param ctx Notification context.
> * @return Future that signifies the end of the listener execution.
> */
> CompletableFuture onUpdate(ConfigurationNotificationEvent ctx);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17289) IgniteWorkerTest#testUpdateHeartbeat is flaky
Denis Chudov created IGNITE-17289: - Summary: IgniteWorkerTest#testUpdateHeartbeat is flaky Key: IGNITE-17289 URL: https://issues.apache.org/jira/browse/IGNITE-17289 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Assignee: Kirill Tkalenko https://ci.ignite.apache.org/project.html?projectId=ignite3_Test=725903858531552074=testDetails_ignite3_Test=%3Cdefault%3E It is flaky on windows at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17288) Fix broken links in Javadoc
Igor Gusev created IGNITE-17288: --- Summary: Fix broken links in Javadoc Key: IGNITE-17288 URL: https://issues.apache.org/jira/browse/IGNITE-17288 Project: Ignite Issue Type: Task Reporter: Igor Gusev We need to fix the the following failed links in javadocs: Failed link: http://gee.cs.oswego.edu/dl/papers/fj.pdf Failed link: http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17272) Logical recovery works incorrectly for encrypted caches
[
https://issues.apache.org/jira/browse/IGNITE-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17272:
---
Component/s: cache
> Logical recovery works incorrectly for encrypted caches
> ---
>
> Key: IGNITE-17272
> URL: https://issues.apache.org/jira/browse/IGNITE-17272
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.13
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When encryption is enabled for a particular cache, its WAL records get
> encrypted and wrapped in an {{EncryptedRecord}}. This encrypted record type
> is considered a {{PHYSICAL}} record, which leads to such records being
> omitted during logical recovery regardless of the fact that it can contain
> logical records.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17272) Logical recovery works incorrectly for encrypted caches
[
https://issues.apache.org/jira/browse/IGNITE-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17272:
---
Affects Version/s: 2.13
> Logical recovery works incorrectly for encrypted caches
> ---
>
> Key: IGNITE-17272
> URL: https://issues.apache.org/jira/browse/IGNITE-17272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When encryption is enabled for a particular cache, its WAL records get
> encrypted and wrapped in an {{EncryptedRecord}}. This encrypted record type
> is considered a {{PHYSICAL}} record, which leads to such records being
> omitted during logical recovery regardless of the fact that it can contain
> logical records.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17272) Logical recovery works incorrectly for encrypted caches
[
https://issues.apache.org/jira/browse/IGNITE-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561364#comment-17561364
]
Ivan Bessonov commented on IGNITE-17272:
Looks good to me, thank you! I'll merge it to master
> Logical recovery works incorrectly for encrypted caches
> ---
>
> Key: IGNITE-17272
> URL: https://issues.apache.org/jira/browse/IGNITE-17272
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When encryption is enabled for a particular cache, its WAL records get
> encrypted and wrapped in an {{EncryptedRecord}}. This encrypted record type
> is considered a {{PHYSICAL}} record, which leads to such records being
> omitted during logical recovery regardless of the fact that it can contain
> logical records.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17219) Revise types support in schema module
[ https://issues.apache.org/jira/browse/IGNITE-17219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-17219: --- Assignee: Evgeny Stanilovsky > Revise types support in schema module > - > > Key: IGNITE-17219 > URL: https://issues.apache.org/jira/browse/IGNITE-17219 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Looks like not all types are properly integrated into the system: some of > them can't be serialised within SchemaDescriptor (temporal types), for some > of them default value is improperly converted from schemaDefinition to a > changer (byte array). > Lets extend test coverage in order to find out all such missed places and fix > them. Cases to consider: > * (de-)serialisation of all supported types and theirs default > * conversion from schemaDefinition to changer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17287) SchemaSerializerImpl and ClientMessagePacker have the same types (un)pack code functionality, deduplication needed.
[
https://issues.apache.org/jira/browse/IGNITE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-17287:
Affects Version/s: 3.0.0-alpha6
> SchemaSerializerImpl and ClientMessagePacker have the same types (un)pack
> code functionality, deduplication needed.
> ---
>
> Key: IGNITE-17287
> URL: https://issues.apache.org/jira/browse/IGNITE-17287
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-alpha6
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> ByteBuffer vs Netty.ByteBuf are also difference, but seems its not a problem.
> Check for example:
> ClientMessagePacker#packDateTime:
> {code:java}
> public void packDateTime(LocalDateTime val) {
> packExtensionTypeHeader(ClientMsgPackType.DATETIME);
> buf.writeInt(val.getYear());
> buf.writeByte(val.getMonthValue());
> buf.writeByte(val.getDayOfMonth());
> buf.writeByte(val.getHour());
> buf.writeByte(val.getMinute());
> buf.writeByte(val.getSecond());
> buf.writeInt(val.getNano());
> }
> {code}
> SchemaSerializerImpl#appendDefaultValue
> {code:java}
> case DATETIME: {
> LocalDateTime date = (LocalDateTime) val;
> buf.putInt(date.getYear());
> buf.put((byte) date.getMonthValue());
> buf.put((byte) date.getDayOfMonth());
> buf.put((byte) date.getHour());
> buf.put((byte) date.getMinute());
> buf.put((byte) date.getSecond());
> buf.putInt(date.getNano());
> break;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17287) SchemaSerializerImpl and ClientMessagePacker have the same types (un)pack code functionality, deduplication needed.
[
https://issues.apache.org/jira/browse/IGNITE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-17287:
Description:
ByteBuffer vs Netty.ByteBuf are also difference, but seems its not a problem.
Check for example:
ClientMessagePacker#packDateTime:
{code:java}
public void packDateTime(LocalDateTime val) {
packExtensionTypeHeader(ClientMsgPackType.DATETIME);
buf.writeInt(val.getYear());
buf.writeByte(val.getMonthValue());
buf.writeByte(val.getDayOfMonth());
buf.writeByte(val.getHour());
buf.writeByte(val.getMinute());
buf.writeByte(val.getSecond());
buf.writeInt(val.getNano());
}
{code}
SchemaSerializerImpl#appendDefaultValue
{code:java}
case DATETIME: {
LocalDateTime date = (LocalDateTime) val;
buf.putInt(date.getYear());
buf.put((byte) date.getMonthValue());
buf.put((byte) date.getDayOfMonth());
buf.put((byte) date.getHour());
buf.put((byte) date.getMinute());
buf.put((byte) date.getSecond());
buf.putInt(date.getNano());
break;
}
{code}
was:
Check for example:
ClientMessagePacker#packDateTime:
{code:java}
public void packDateTime(LocalDateTime val) {
packExtensionTypeHeader(ClientMsgPackType.DATETIME);
buf.writeInt(val.getYear());
buf.writeByte(val.getMonthValue());
buf.writeByte(val.getDayOfMonth());
buf.writeByte(val.getHour());
buf.writeByte(val.getMinute());
buf.writeByte(val.getSecond());
buf.writeInt(val.getNano());
}
{code}
SchemaSerializerImpl#appendDefaultValue
{code:java}
case DATETIME: {
LocalDateTime date = (LocalDateTime) val;
buf.putInt(date.getYear());
buf.put((byte) date.getMonthValue());
buf.put((byte) date.getDayOfMonth());
buf.put((byte) date.getHour());
buf.put((byte) date.getMinute());
buf.put((byte) date.getSecond());
buf.putInt(date.getNano());
break;
}
{code}
> SchemaSerializerImpl and ClientMessagePacker have the same types (un)pack
> code functionality, deduplication needed.
> ---
>
> Key: IGNITE-17287
> URL: https://issues.apache.org/jira/browse/IGNITE-17287
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> ByteBuffer vs Netty.ByteBuf are also difference, but seems its not a problem.
> Check for example:
> ClientMessagePacker#packDateTime:
> {code:java}
> public void packDateTime(LocalDateTime val) {
> packExtensionTypeHeader(ClientMsgPackType.DATETIME);
> buf.writeInt(val.getYear());
> buf.writeByte(val.getMonthValue());
> buf.writeByte(val.getDayOfMonth());
> buf.writeByte(val.getHour());
> buf.writeByte(val.getMinute());
> buf.writeByte(val.getSecond());
> buf.writeInt(val.getNano());
> }
> {code}
> SchemaSerializerImpl#appendDefaultValue
> {code:java}
> case DATETIME: {
> LocalDateTime date = (LocalDateTime) val;
> buf.putInt(date.getYear());
> buf.put((byte) date.getMonthValue());
> buf.put((byte) date.getDayOfMonth());
> buf.put((byte) date.getHour());
> buf.put((byte) date.getMinute());
> buf.put((byte) date.getSecond());
> buf.putInt(date.getNano());
> break;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17285) Ambiguous output of INDEXES SytemView if cache is created via DDL
[
https://issues.apache.org/jira/browse/IGNITE-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561337#comment-17561337
]
Aleksey Plekhanov commented on IGNITE-17285:
Ignite unwraps _KEY fields for indexes of tables created by SQL, see comment
for
[this|https://github.com/apache/ignite/commit/c3462f3b09c52c4c0bcb55867015449a2fb6]
commit (related tickets IGNITE-8386, IGNITE-10217).
> Ambiguous output of INDEXES SytemView if cache is created via DDL
> --
>
> Key: IGNITE-17285
> URL: https://issues.apache.org/jira/browse/IGNITE-17285
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: SqlIndexSystemViewReproducerTest.patch,
> create_table.txt, query_entity.txt
>
>
> There is a difference in 'COLUMNS ' and 'INLINE_SIZE' columns content in
> system view 'INDEXES', when you create SQL-cache by means of QueryEntity and
> by means of DDL.
> As you can see in reproducer [^SqlIndexSystemViewReproducerTest.patch] ,
> there are two "equal" attepmts to create cache: via DDL, and via Cache API +
> QueryEntity.
> Primary keys contains equal set of fields, affinity fields are the same.
> Outputs of system views TABLES, TABLE_COLUMNS and BINARY_METADATA are the
> same for both ways of cache creation. Table content (i.e. select *) is also
> the same, if you do not take into account the order of output.
> There are example sqlline outputs for table from reproducer:
> # [^create_table.txt] - for table, created by DDL.
> # [^query_entity.txt] - for table, created by Cache API.
> As you can see, colums and content differs in INDEXES view: in case of DDL,
> indexes does not have '_KEY' column, and have explicit set of columns from
> primary key. Also, there is a duplication of affinity column 'ID' for :
> {code}
> "ID" ASC, "FIRSTNAME" ASC, "LASTNAME" ASC, "ID" ASC
> {code}
> In case of creation table via Cache API + QueryEntity, no exlicit primary key
> columns are shown, but '_KEY' column is, and there is no duplication of
> affinity column 'ID' in '_key_PK_hash' index.
> Reproducer dumps indexes ({{org.h2.index.Index}}) collection content, which
> is obtained from {{GridH2Table#getIndexes}}. It seems, that information
> differs in this class too.
> Example output:
> {code:java|title=Cache API + QueryEntity}
> Index name Columns
> _key_PK__SCAN_ [_KEY, ID]
> _key_PK_hash [_KEY, ID]
> _key_PK [_KEY, ID]
> AFFINITY_KEY [ID, _KEY]
> PERSONINFO_CITYNAME_IDX [CITYNAME, _KEY, ID]
> {code}
> {code:java|title=DDL}
> Index name Columns
> _key_PK__SCAN_ [ID, FIRSTNAME, LASTNAME]
> _key_PK_hash [_KEY, ID]
> _key_PK [ID, FIRSTNAME, LASTNAME]
> AFFINITY_KEY [ID, FIRSTNAME, LASTNAME]
> PERSONINFO_CITYNAME_IDX [CITYNAME, ID, FIRSTNAME, LASTNAME]
> {code}
> If such difference is not a bug, it should be documented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17287) SchemaSerializerImpl and ClientMessagePacker have the same types (un)pack code functionality, deduplication needed.
Evgeny Stanilovsky created IGNITE-17287:
---
Summary: SchemaSerializerImpl and ClientMessagePacker have the
same types (un)pack code functionality, deduplication needed.
Key: IGNITE-17287
URL: https://issues.apache.org/jira/browse/IGNITE-17287
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Evgeny Stanilovsky
Check for example:
ClientMessagePacker#packDateTime:
{code:java}
public void packDateTime(LocalDateTime val) {
packExtensionTypeHeader(ClientMsgPackType.DATETIME);
buf.writeInt(val.getYear());
buf.writeByte(val.getMonthValue());
buf.writeByte(val.getDayOfMonth());
buf.writeByte(val.getHour());
buf.writeByte(val.getMinute());
buf.writeByte(val.getSecond());
buf.writeInt(val.getNano());
}
{code}
SchemaSerializerImpl#appendDefaultValue
{code:java}
case DATETIME: {
LocalDateTime date = (LocalDateTime) val;
buf.putInt(date.getYear());
buf.put((byte) date.getMonthValue());
buf.put((byte) date.getDayOfMonth());
buf.put((byte) date.getHour());
buf.put((byte) date.getMinute());
buf.put((byte) date.getSecond());
buf.putInt(date.getNano());
break;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17286) Race between completing table creation and stopping TableManager
[
https://issues.apache.org/jira/browse/IGNITE-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-17286:
---
Description:
As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
following:
java.lang.AssertionError: Raft groups are still running
The leftover Raft groups always relate to table partitions (and NOT
metastorage/cmg).
It looks like this can happen due to TableManager.stop() being called before
some table creation is completed (on some Ignite node). As a result,
TableManager.stop() does not see this table, so the table does not get stopped,
and its Raft groups are left forever.
Adding a delay to table creation completion
public void onSqlSchemaReady(long causalityToken) {
if (Math.random() < 0.33) {
try
{ Thread.sleep(1000); }
catch (InterruptedException e)
{ // ignore }
}
LOG.info("SCHEMA READY FOR " + causalityToken);
tablesByIdVv.complete(causalityToken);
}
makes the failure manifest itself easily.
The reproducer is in
[https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
To run the reproducer, just run
ItComputeTest.executesColocatedByClassNameWithTupleKey()
It usually takes less than 10 iterations to bump into the assertion.
was:
As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
following:
java.lang.AssertionError: Raft groups are still running
The leftover Raft groups always relate to table partitions (and NOT
metastorage/cmg).
It looks like this can happen due to TableManager.stop() being called before
some table creation is completed (on some Ignite node). As a result,
TableManager.stop() does not see this table, so the table does not get stopped,
and its Raft groups are left forever.
Adding a delay to table creation completion
public void onSqlSchemaReady(long causalityToken) {
if (Math.random() < 0.33) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// ignore
}
}
LOG.info("SCHEMA READY FOR " + causalityToken);
tablesByIdVv.complete(causalityToken);
}
makes the failure manifest itself easily.
> Race between completing table creation and stopping TableManager
>
>
> Key: IGNITE-17286
> URL: https://issues.apache.org/jira/browse/IGNITE-17286
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
> following:
> java.lang.AssertionError: Raft groups are still running
> The leftover Raft groups always relate to table partitions (and NOT
> metastorage/cmg).
> It looks like this can happen due to TableManager.stop() being called before
> some table creation is completed (on some Ignite node). As a result,
> TableManager.stop() does not see this table, so the table does not get
> stopped, and its Raft groups are left forever.
> Adding a delay to table creation completion
> public void onSqlSchemaReady(long causalityToken) {
> if (Math.random() < 0.33) {
> try
> { Thread.sleep(1000); }
> catch (InterruptedException e)
> { // ignore }
> }
> LOG.info("SCHEMA READY FOR " + causalityToken);
> tablesByIdVv.complete(causalityToken);
> }
> makes the failure manifest itself easily.
> The reproducer is in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
> To run the reproducer, just run
> ItComputeTest.executesColocatedByClassNameWithTupleKey()
> It usually takes less than 10 iterations to bump into the assertion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561329#comment-17561329
]
Norbert Löffler commented on IGNITE-16136:
--
Dear development experts, [~mmuzaf] , in coodination with our Top management
I'm autorized to tell you this is an important issue for us. Is there a way to
get this more prioritized ? (maybe sponsor the fix by a donation to the Apache
Foundation or the like)
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(Ljava/util/concurrent/ConcurrentMap;ILjava/lang/ClassLoader;Lorg/apache/ignite/marshaller/MarshallerContext;Lorg/apache/ignite/internal/marshaller/optimized/OptimizedMarshallerIdMapper;)Lorg/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor;
> (OptimizedMarshallerUtils.java:264)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:341)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:198)
> at
> java.io.ObjectInputStream.readObject(Ljava/lang/Class;)Ljava/lang/Object;
>
[jira] [Created] (IGNITE-17286) Race between completing table creation and stopping TableManager
Roman Puchkovskiy created IGNITE-17286:
--
Summary: Race between completing table creation and stopping
TableManager
Key: IGNITE-17286
URL: https://issues.apache.org/jira/browse/IGNITE-17286
Project: Ignite
Issue Type: Bug
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-alpha6
As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
following:
java.lang.AssertionError: Raft groups are still running
The leftover Raft groups always relate to table partitions (and NOT
metastorage/cmg).
It looks like this can happen due to TableManager.stop() being called before
some table creation is completed (on some Ignite node). As a result,
TableManager.stop() does not see this table, so the table does not get stopped,
and its Raft groups are left forever.
Adding a delay to table creation completion
public void onSqlSchemaReady(long causalityToken) {
if (Math.random() < 0.33) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// ignore
}
}
LOG.info("SCHEMA READY FOR " + causalityToken);
tablesByIdVv.complete(causalityToken);
}
makes the failure manifest itself easily.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
