[jira] [Updated] (IGNITE-12418) Add documentation for Sql default query timeout
[ https://issues.apache.org/jira/browse/IGNITE-12418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12418: Component/s: documentation > Add documentation for Sql default query timeout > --- > > Key: IGNITE-12418 > URL: https://issues.apache.org/jira/browse/IGNITE-12418 > Project: Ignite > Issue Type: Task > Components: cache, documentation, sql >Reporter: Saikat Maitra >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12303) Change comment for an enumeration item CACHE_DESTROY
[ https://issues.apache.org/jira/browse/IGNITE-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988519#comment-16988519 ] wang cheng edited comment on IGNITE-12303 at 12/5/19 6:41 AM: -- I am new here,I think I can fix it. was (Author: hadoop1024): I am new here,I think I can fix. > Change comment for an enumeration item CACHE_DESTROY > > > Key: IGNITE-12303 > URL: https://issues.apache.org/jira/browse/IGNITE-12303 > Project: Ignite > Issue Type: Wish > Components: documentation, security >Reporter: Surkov Aleksandr >Assignee: Albert Iskhakov >Priority: Minor > Labels: newbie > > For the _org.apache.ignite.plugin.security.SecurityPermission#CACHE_DESTROY_ > enumeration element it would be worth changing the comment. "Cache create > permission." it's not very good. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12303) Change comment for an enumeration item CACHE_DESTROY
[ https://issues.apache.org/jira/browse/IGNITE-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988519#comment-16988519 ] wang cheng commented on IGNITE-12303: - I am new here,I think I can fix. > Change comment for an enumeration item CACHE_DESTROY > > > Key: IGNITE-12303 > URL: https://issues.apache.org/jira/browse/IGNITE-12303 > Project: Ignite > Issue Type: Wish > Components: documentation, security >Reporter: Surkov Aleksandr >Assignee: Albert Iskhakov >Priority: Minor > Labels: newbie > > For the _org.apache.ignite.plugin.security.SecurityPermission#CACHE_DESTROY_ > enumeration element it would be worth changing the comment. "Cache create > permission." it's not very good. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12398) Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we connect Ignite Visor Command Line Interface
[ https://issues.apache.org/jira/browse/IGNITE-12398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ravi Kumar Powli updated IGNITE-12398: -- Flags: Patch,Important > Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting down if we > connect Ignite Visor Command Line Interface > - > > Key: IGNITE-12398 > URL: https://issues.apache.org/jira/browse/IGNITE-12398 > Project: Ignite > Issue Type: Bug > Components: aws, s3, visor >Affects Versions: 2.7 > Environment: Production >Reporter: Ravi Kumar Powli >Priority: Blocker > Fix For: None > > > We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery. If > we connect any one cluster node using Ignite Visor Command Line Interface it > got hang and automatically cluster nodes(all the three nodes) are going down. > Please find the below exception stacktrace. > [SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] Critical system > error detected. Will be handled accordingly to configured handler > [hnd=NoOpFailureHandler [super=AbstractFailureHandler > [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]] > java.lang.NullPointerException > at > org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.key(TcpDiscoveryS3IpFinder.java:247) > at > org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder.registerAddresses(TcpDiscoveryS3IpFinder.java:205) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4616) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4232) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2816) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2611) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7188) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700) > at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:36:54,600][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%][] > Critical system error detected. Will be handled accordingly to configured > handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler > [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker > [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache, > finished=true, heartbeatTs=1574332614423]]] > class org.apache.ignite.IgniteException: GridWorker > [name=tcp-disco-msg-worker, igniteInstanceName=DataStoreIgniteCache, > finished=true, heartbeatTs=1574332614423] > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826) > at > org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:169) > at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:153) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:36:59] Ignite node stopped OK [name=DataStoreIgniteCache, > uptime=00:01:13.934] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988366#comment-16988366
]
Saikat Maitra edited comment on IGNITE-7285 at 12/5/19 1:20 AM:
[~Pavlukhin]
I have created this follow up documentation issue:
https://issues.apache.org/jira/browse/IGNITE-12418
I have also updated this issue as RESOLVED and updated Fix Version to 2.8
Regards,
Saikat
was (Author: samaitra):
[~Pavlukhin]
I have created this follow up documentation issue:
**https://issues.apache.org/jira/browse/IGNITE-12418
I have also updated this issue as RESOLVED and updated Fix Version to 2.8
Regards,
Saikat
> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 10h 40m
> Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be
> very useful to have default timeout value provided on cache startup. Let's
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988366#comment-16988366
]
Saikat Maitra commented on IGNITE-7285:
---
[~Pavlukhin]
I have created this follow up documentation issue:
**https://issues.apache.org/jira/browse/IGNITE-12418
I have also updated this issue as RESOLVED and updated Fix Version to 2.8
Regards,
Saikat
> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 10h 40m
> Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be
> very useful to have default timeout value provided on cache startup. Let's
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12418) Add documentation for Sql default query timeout
Saikat Maitra created IGNITE-12418: -- Summary: Add documentation for Sql default query timeout Key: IGNITE-12418 URL: https://issues.apache.org/jira/browse/IGNITE-12418 Project: Ignite Issue Type: Task Components: cache, sql Reporter: Saikat Maitra -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12417) .NET: ASP.NET Core Identity Store
Pavel Tupitsyn created IGNITE-12417: --- Summary: .NET: ASP.NET Core Identity Store Key: IGNITE-12417 URL: https://issues.apache.org/jira/browse/IGNITE-12417 Project: Ignite Issue Type: New Feature Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Implement ASP.NET Core identity store based on Apache Ignite (Thin Client or Classic API). * Docs: https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-3.1=visual-studio * RavenDB example: https://www.eximiaco.tech/en/2019/07/27/writing-an-asp-net-core-identity-storage-provider-from-scratch-with-ravendb/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12188) Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly if there is more then one cache in cache group
[
https://issues.apache.org/jira/browse/IGNITE-12188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12188:
-
Fix Version/s: 2.8
> Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly
> if there is more then one cache in cache group
>
>
> Key: IGNITE-12188
> URL: https://issues.apache.org/jira/browse/IGNITE-12188
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Aleksey Plekhanov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-35, await
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Initial partitions counter is set to a total number of partitions for cache
> group but decremented each time partition processed for each cache.
> Reproducer:
> {code:java}
> @Test
> public void testIndexRebuildMetrics() throws Exception {
> IgniteEx ignite = startGrid(new IgniteConfiguration()
> .setConsistentId("ignite")
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)))
> .setCacheConfiguration(
> new CacheConfiguration Integer>("c1").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class),
> new CacheConfiguration Integer>("c2").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class)
> ));
> ignite.cluster().active(true);
> for (int i = 0; i < 10_000; i++)
> ignite.cache("c1").put(i, i);
> ignite.cluster().active(false);
> File dir = U.resolveWorkDirectory(U.defaultWorkDirectory(),
> DFLT_STORE_DIR, false);
> U.delete(new File(dir, "ignite/cacheGroup-grp/index.bin"));
> ignite.cluster().active(true);
> doSleep(1_000L);
>
> assertTrue(ignite.context().cache().cache("c1").context().group().metrics().getIndexBuildCountPartitionsLeft()
> >= 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12108) [IEP-35] Migrate Communication Metrics.
[ https://issues.apache.org/jira/browse/IGNITE-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12108: - Fix Version/s: 2.8 > [IEP-35] Migrate Communication Metrics. > --- > > Key: IGNITE-12108 > URL: https://issues.apache.org/jira/browse/IGNITE-12108 > Project: Ignite > Issue Type: New Feature >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-35, await > Fix For: 2.8 > > Time Spent: 7h 10m > Remaining Estimate: 0h > > ||*Name*||*Description*|| > |communication.tcp.outboundMessagesQueueSize|Number of messages waiting to be > sent| > |communication.tcp.sentBytes|Total number of bytes received by current node| > |communication.tcp.receivedBytes|Total number of bytes sent by current node| > |communication.tcp.sentMessagesCount|Total number of messages sent by current > node| > |communication.tcp.receivedMessagesCount|Total number of messages received by > current node| > |communication.tcp.sentMessagesByType.|Total number of messages > with given type sent by current node| > |communication.tcp.receivedMessagesByType.|Total number of > messages with given type received by current node| > |communication.tcp..sentMessagesToNode|Total number of messages sent > by current node to the given node| > |communication.tcp..receivedMessagesFromNode|Total number of messages > received by current node from the given node| > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12187) [IEP-35] Move GridMetricManager and dependent classes to org.apache.ignite.internal.managers
[
https://issues.apache.org/jira/browse/IGNITE-12187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12187:
-
Fix Version/s: 2.8
> [IEP-35] Move GridMetricManager and dependent classes to
> org.apache.ignite.internal.managers
>
>
> Key: IGNITE-12187
> URL: https://issues.apache.org/jira/browse/IGNITE-12187
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Amelchev Nikita
>Priority: Trivial
> Labels: IEP-35
> Fix For: 2.8
>
>
> Right now metric internal classes are in
> {{org.apache.ignite.internal.processors.metric}} package.
> Seems, we should move it to {{org.apache.ignite.internal.managers.metric}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11923) [IEP-35] Migrate IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11923: - Fix Version/s: 2.8 > [IEP-35] Migrate IgniteMXBean > - > > Key: IGNITE-11923 > URL: https://issues.apache.org/jira/browse/IGNITE-11923 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Sergey Kalashnikov >Priority: Major > Labels: IEP-35, await > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `IgniteMXBean` to the new > metric framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11987) [IEP-35] Add ability to configure metrics
[ https://issues.apache.org/jira/browse/IGNITE-11987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11987: - Fix Version/s: 2.8 > [IEP-35] Add ability to configure metrics > - > > Key: IGNITE-11987 > URL: https://issues.apache.org/jira/browse/IGNITE-11987 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Ignite should be able to: > * Configure Histogram metrics > * Configure HitRate metrics. > We should provide 2 ways to configure metric: > 1. -Configuration file.- Discussed on dev-list. Agreed to go with the > simplest solution - JMX method. > 2. JMX method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9974) Drop Hadoop assemblies
[ https://issues.apache.org/jira/browse/IGNITE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-9974: - Fix Version/s: 2.9 > Drop Hadoop assemblies > -- > > Key: IGNITE-9974 > URL: https://issues.apache.org/jira/browse/IGNITE-9974 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > After dropping Hadoop binaries from release delivery (see IGNITE-9953) it is > required to drop assemblies and corresponding files / profiles if exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12382) Clarify "collocated" flag documentation
[ https://issues.apache.org/jira/browse/IGNITE-12382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12382: - Ignite Flags: (was: Docs Required,Release Notes Required) > Clarify "collocated" flag documentation > --- > > Key: IGNITE-12382 > URL: https://issues.apache.org/jira/browse/IGNITE-12382 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.7.6 >Reporter: Denis A. Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.8 > > > Documentation of the JDBC and ODBC drivers doesn't explain when and why the > "collocated" flag needs to be set. The docs are vague and not clear: > https://apacheignite-sql.readme.io/docs/jdbc-driver > https://apacheignite-sql.readme.io/docs/connection-string-and-dsn > In fact, the optimization is useful for queries with GROUP BY operand. The > docs need to be improved with the content of the Javadoc and a summary shared > in the dev list discussion: > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/SqlFieldsQuery.html#isCollocated-- > http://apache-ignite-developers.2346864.n4.nabble.com/Collocated-replicatedOnly-flags-for-Thin-JDBC-driver-td44357.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12322) Changing baseline via set command may cause NPEs if configured NodeFilter takes node attributes into account
[
https://issues.apache.org/jira/browse/IGNITE-12322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12322:
-
Ignite Flags: (was: Release Notes Required)
> Changing baseline via set command may cause NPEs if configured NodeFilter
> takes node attributes into account
>
>
> Key: IGNITE-12322
> URL: https://issues.apache.org/jira/browse/IGNITE-12322
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
>
> VisorBaselineTask doesn't allow to add() offline baseline node, but allows to
> set() collection of nodes where at least one is offline and doesn’t belong to
> current BLT.
> We should prohibit passing offline nodes to setBaselineTopology(…) (in case
> they are not part of current BLT): otherwise we won't be able to calculate
> affinity in case NodeFilter is configured.
> {code:java}
> 2019-07-16 13:38:01.658 ERROR 16507 --- [exchange-worker-#165]
> .c.d.d.p.GridDhtPartitionsExchangeFuture : Failed to reinitialize local
> partitions (rebalancing will be stopped): GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=481, minorTopVer=1],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=e53b5aca-9432-4cbe-9626-da480b86d417, addrs=ArrayList [10.12.85.13,
> 127.0.0.1], sockAddrs=HashSet [lpposput50143.phx.aexp.com/10.12.85.13:47550,
> /127.0.0.1:47550], discPort=47550, order=288, intOrder=148,
> lastExchangeTime=1563309481590, loc=true, ver=2.5.7#20190326-sha1:b45b8438,
> isClient=false], topVer=481, nodeId8=e53b5aca, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1563309481580]DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=bb76b94db61-f4fff892-04f6-4153-9210-1a19749fec35,
> reqId=1b5cae87-ad46-4d62-8525-bc1a5015b0d8,
> initiatingNodeId=e53b5aca-9432-4cbe-9626-da480b86d417, activate=true,
> baselineTopology=BaselineTopology [id=3, branchingHash=-1403071463,
> branchingType='New BaselineTopology',
> baselineNodes=[/dev/shm/ignite/storagepath/lpposput50142.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50143.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50133.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50134.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50141.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50140.phx.aexp.com]],
> forceChangeBaselineTopology=true, timestamp=1563309481551],
> affTopVer=AffinityTopologyVersion [topVer=481, minorTopVer=1], super=],
> nodeId=e53b5aca, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.cluster.DetachedClusterNode.attribute(DetachedClusterNode.java:69)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at com.aexp.rc.ignite.CacheNodeFilter.apply(CacheNodeFilter.java:14)
> ~[classes!/:0.1.0-SNAPSHOT]
> at com.aexp.rc.ignite.CacheNodeFilter.apply(CacheNodeFilter.java:6)
> ~[classes!/:0.1.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1362)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopology.createBaselineView(BaselineTopology.java:331)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.calculate(GridAffinityAssignmentCache.java:347)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$15.applyx(CacheAffinitySharedManager.java:1899)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$15.applyx(CacheAffinitySharedManager.java:1895)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.lambda$forAllRegisteredCacheGroups$e0a6939d$1(CacheAffinitySharedManager.java:1268)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:10529)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_161]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_161]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[na:1.8.0_161]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]
> Suppressed: java.lang.NullPointerException: null
> ... 14 common frames omitted
> Suppressed: java.lang.NullPointerException: null
> ... 14 common frames omitted
> Suppressed:
[jira] [Updated] (IGNITE-12322) Changing baseline via set command may cause NPEs if configured NodeFilter takes node attributes into account
[
https://issues.apache.org/jira/browse/IGNITE-12322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12322:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Changing baseline via set command may cause NPEs if configured NodeFilter
> takes node attributes into account
>
>
> Key: IGNITE-12322
> URL: https://issues.apache.org/jira/browse/IGNITE-12322
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
>
> VisorBaselineTask doesn't allow to add() offline baseline node, but allows to
> set() collection of nodes where at least one is offline and doesn’t belong to
> current BLT.
> We should prohibit passing offline nodes to setBaselineTopology(…) (in case
> they are not part of current BLT): otherwise we won't be able to calculate
> affinity in case NodeFilter is configured.
> {code:java}
> 2019-07-16 13:38:01.658 ERROR 16507 --- [exchange-worker-#165]
> .c.d.d.p.GridDhtPartitionsExchangeFuture : Failed to reinitialize local
> partitions (rebalancing will be stopped): GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=481, minorTopVer=1],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=e53b5aca-9432-4cbe-9626-da480b86d417, addrs=ArrayList [10.12.85.13,
> 127.0.0.1], sockAddrs=HashSet [lpposput50143.phx.aexp.com/10.12.85.13:47550,
> /127.0.0.1:47550], discPort=47550, order=288, intOrder=148,
> lastExchangeTime=1563309481590, loc=true, ver=2.5.7#20190326-sha1:b45b8438,
> isClient=false], topVer=481, nodeId8=e53b5aca, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1563309481580]DiscoveryCustomEvent
> [customMsg=ChangeGlobalStateMessage
> [id=bb76b94db61-f4fff892-04f6-4153-9210-1a19749fec35,
> reqId=1b5cae87-ad46-4d62-8525-bc1a5015b0d8,
> initiatingNodeId=e53b5aca-9432-4cbe-9626-da480b86d417, activate=true,
> baselineTopology=BaselineTopology [id=3, branchingHash=-1403071463,
> branchingType='New BaselineTopology',
> baselineNodes=[/dev/shm/ignite/storagepath/lpposput50142.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50143.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50133.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50134.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50141.phx.aexp.com,
> /dev/shm/ignite/storagepath/lpposput50140.phx.aexp.com]],
> forceChangeBaselineTopology=true, timestamp=1563309481551],
> affTopVer=AffinityTopologyVersion [topVer=481, minorTopVer=1], super=],
> nodeId=e53b5aca, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.cluster.DetachedClusterNode.attribute(DetachedClusterNode.java:69)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at com.aexp.rc.ignite.CacheNodeFilter.apply(CacheNodeFilter.java:14)
> ~[classes!/:0.1.0-SNAPSHOT]
> at com.aexp.rc.ignite.CacheNodeFilter.apply(CacheNodeFilter.java:6)
> ~[classes!/:0.1.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.affinityNode(GridCacheUtils.java:1362)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopology.createBaselineView(BaselineTopology.java:331)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.calculate(GridAffinityAssignmentCache.java:347)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$15.applyx(CacheAffinitySharedManager.java:1899)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$15.applyx(CacheAffinitySharedManager.java:1895)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.lambda$forAllRegisteredCacheGroups$e0a6939d$1(CacheAffinitySharedManager.java:1268)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:10529)
> ~[ignite-core-2.5.7.jar!/:2.5.7]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_161]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_161]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ~[na:1.8.0_161]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_161]
> Suppressed: java.lang.NullPointerException: null
> ... 14 common frames omitted
> Suppressed: java.lang.NullPointerException: null
> ... 14 common frames omitted
>
[jira] [Updated] (IGNITE-12336) CacheMetricsImpl instance will be created twice in case of near cache is configured
[
https://issues.apache.org/jira/browse/IGNITE-12336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12336:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> CacheMetricsImpl instance will be created twice in case of near cache is
> configured
> ---
>
> Key: IGNITE-12336
> URL: https://issues.apache.org/jira/browse/IGNITE-12336
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{CacheMetricsImpl}} instance will be created twice for DHT cache in case of
> near cache is configured.
> It is absolutely redundant instance because cache context already contains
> metrics instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12038) Fix several failing tests after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-12038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12038: - Ignite Flags: (was: Docs Required) > Fix several failing tests after IGNITE-10078 > > > Key: IGNITE-12038 > URL: https://issues.apache.org/jira/browse/IGNITE-12038 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > *New stable failure of a flaky test in master > LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6585115376754732686=%3Cdefault%3E=testDetails > *New stable failure of a flaky test in master > GridCacheRebalancingWithAsyncClearingMvccTest.testPartitionClearingNotBlockExchange > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7007912051428984819=%3Cdefault%3E=testDetails > *New stable failure of a flaky test in master > GridCacheRebalancingAsyncSelfTest.testComplexRebalancing > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8829809273565657995=%3Cdefault%3E=testDetails -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12327) Cross-cache tx is mapped on wrong primary when enlisted caches have incompatible assignments.
[ https://issues.apache.org/jira/browse/IGNITE-12327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12327: - Ignite Flags: (was: Docs Required,Release Notes Required) > Cross-cache tx is mapped on wrong primary when enlisted caches have > incompatible assignments. > - > > Key: IGNITE-12327 > URL: https://issues.apache.org/jira/browse/IGNITE-12327 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > > This is happening when supplier node is left while rebalancing is partially > completed on demander. > Suppose we have 2 cache groups, rebalance is in progress and for first group > rebalance is done and for second group rebalance is partially done (some > partitions are still MOVING). > At this moment supplier node dies and corresponding topology version is (N,0). > New assignment is computed using current state of partitions and for first > group will be ideal and the same as for next topology (N,1) which will be > triggered after all rebalancing is completed by CacheAffinityChangeMessage. > For second group affinity will not be ideal. > If transaction is started while PME is in progress (N, 0)->(N,1), first lock > request will pass remap check if it's enslists rebalanced group. All > subsequent lock requests will use invalid topology from previous assignment. > Possible fix: return actual locked topology version from first lock request > and use it for all subsequent requests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12140) .NET: TestBaselineTopology pollutes environment variables
[ https://issues.apache.org/jira/browse/IGNITE-12140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12140: - Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: TestBaselineTopology pollutes environment variables > - > > Key: IGNITE-12140 > URL: https://issues.apache.org/jira/browse/IGNITE-12140 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.8 > > > PersistenceTest.TestBaselineTopology sets IGNITE_BASELINE_AUTO_ADJUST_ENABLED > env var, there are two issues: > * If the test fails, the variable is not reset > * If the test succeeds, the variable is cleared instead of being reset to > previous value (whatever it might be) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12232) NPE while node join processing
[ https://issues.apache.org/jira/browse/IGNITE-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12232: - Ignite Flags: (was: Docs Required,Release Notes Required) > NPE while node join processing > -- > > Key: IGNITE-12232 > URL: https://issues.apache.org/jira/browse/IGNITE-12232 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: PetrovMikhail >Assignee: Ryabov Dmitrii >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > ServerImpl.RingMessageWorker#processNodeAddedMessage method throws npe > exception in case DiscoverySpiNodeAuthenticator#authenticateNode returns null. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12179) Test and javadoc fixes
[ https://issues.apache.org/jira/browse/IGNITE-12179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12179: - Ignite Flags: (was: Docs Required,Release Notes Required) > Test and javadoc fixes > -- > > Key: IGNITE-12179 > URL: https://issues.apache.org/jira/browse/IGNITE-12179 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > *.testTtlNoTx flaky failed on TC > TcpCommunicationSpiFreezingClientTest failed > TcpCommunicationSpiFaultyClientSslTest.testNotAcceptedConnection failed > testCacheIdleVerifyPrintLostPartitions failed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12168) [ML] Flaky ML example tests
[ https://issues.apache.org/jira/browse/IGNITE-12168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12168: - Ignite Flags: (was: Docs Required,Release Notes Required) > [ML] Flaky ML example tests > --- > > Key: IGNITE-12168 > URL: https://issues.apache.org/jira/browse/IGNITE-12168 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Discussed here > [http://apache-ignite-developers.2346864.n4.nabble.com/After-IGNITE-12148-the-Examples-suite-has-unstable-tests-td43469.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12346) .NET: Platform error:System.NullReferenceException
[
https://issues.apache.org/jira/browse/IGNITE-12346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12346:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> .NET: Platform error:System.NullReferenceException
> --
>
> Key: IGNITE-12346
> URL: https://issues.apache.org/jira/browse/IGNITE-12346
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Denis A. Magda
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.8
>
>
> Came across [this StackOverflow
> issue|https://stackoverflow.com/questions/58624177/blocked-system-critical-thread-has-been-detected]
> and the found an NPE that might cause the rest of instabilities:
> {code:java}
> class org.apache.ignite.IgniteException: Platform
> error:System.NullReferenceException: Ññûëêà íà îáúåêò íå óêàçûâàåò íà
> ýêçåìïëÿð îáúåêòà.
>â
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheEntryFilterApply(Int64
> memPtr)
>â Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Int32
> type, Int64 val)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:404)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:460)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:512)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
> Method)
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheEntryFilterApply(PlatformCallbackGateway.java:143)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCacheEntryFilterImpl.apply(PlatformCacheEntryFilterImpl.java:70)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$InternalScanFilter.apply(GridCacheQueryManager.java:3139)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12413) .NET: XMLDoc does not work when using Ignite NuGet from .NET Core
[ https://issues.apache.org/jira/browse/IGNITE-12413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12413: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > .NET: XMLDoc does not work when using Ignite NuGet from .NET Core > - > > Key: IGNITE-12413 > URL: https://issues.apache.org/jira/browse/IGNITE-12413 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > * Create new .NET Core project (2.x or 3.x): dotnet new console > * Install nightly build of 2.8.0: dotnet add package Apache.Ignite -v > 2.8.0-alpha20191118 > * Open the project in any IDE (VS, VSCode, Rider) and start using Ignite APIs > There is no documentation in IDE tooltips. NuGet package is malformed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12159) Ignite spark doesn't support Alter Column syntax
[
https://issues.apache.org/jira/browse/IGNITE-12159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12159:
-
Issue Type: Task (was: Bug)
> Ignite spark doesn't support Alter Column syntax
>
>
> Key: IGNITE-12159
> URL: https://issues.apache.org/jira/browse/IGNITE-12159
> Project: Ignite
> Issue Type: Task
> Components: spark
>Affects Versions: 2.8
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Zinoviev
>Priority: Critical
> Labels: await
> Fix For: 2.8
>
>
> Steps:
> 1)Start the server
> 2)Run next SQL commands
> CREATE TABLE person (id LONG, name VARCHAR(64), age LONG, city_id DOUBLE,
> zip_code LONG, PRIMARY KEY (name)) WITH "backups=1"
> ALTER TABLE person ADD COLUMN (first_name VARCHAR(64), last_name VARCHAR(64))
> 3)After that run next spark code:
> String configPath = "client.xml";
>
> SparkConf sparkConf = new SparkConf()
> .setMaster("local")
> .setAppName("Example");
> IgniteSparkSession.builder()
> .appName("Spark Ignite catalog example")
> .master("local")
> .config("ignite.disableSparkSQLOptimization", true)
> .igniteConfig(configPath)
> .getOrCreate();
>
> Dataset df2 = igniteSession.sql("select * from person");
> df2.show();
> The result will contain only 5 columns from CREATE TABLE call.
> [http://apache-ignite-users.70518.x6.nabble.com/Altered-sql-table-adding-new-columns-does-not-reflect-in-Spark-shell-td29265.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12227) Default auto-adjust baseline enabled flag calculated incorrectly in some cases
[ https://issues.apache.org/jira/browse/IGNITE-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12227: - Ignite Flags: (was: Docs Required,Release Notes Required) > Default auto-adjust baseline enabled flag calculated incorrectly in some cases > -- > > Key: IGNITE-12227 > URL: https://issues.apache.org/jira/browse/IGNITE-12227 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Blocker > Fix For: 2.8 > > > baselineAutoAdjustEnabled can be been different on different nodes because of > the calculation of default value happening locally on each node and including > only local configuration. It issue can happen by the following reasons: > * If IGNITE_BASELINE_AUTO_ADJUST_ENABLED flag set to a different value on > different nodes it leads to cluster hanging due to baseline calculation > finishing with the unpredictable state on each node. > * if cluster in mixed mode(included in-memory and persistent nodes) sometimes > flag is set to a different value due to calculation doesn't consider remote > nodes configuration. > Possible solution(both points required): > * Get rid of IGNITE_BASELINE_AUTO_ADJUST_ENABLED and replace it by the > explicit call of IgniteCluster#baselineAutoAdjustEnabled where it > required(test only). > * Calculating default value on the first started node as early as > possible(instead of activation) and this value always should be set to > distributed metastorage(unlike it happening now). It means that instead of > awaiting activation, the default value would be calculated by the first > started node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12286) NPE in SQLView exporter when filter is null
[
https://issues.apache.org/jira/browse/IGNITE-12286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12286:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> NPE in SQLView exporter when filter is null
> ---
>
> Key: IGNITE-12286
> URL: https://issues.apache.org/jira/browse/IGNITE-12286
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When filter is null in {{SqlViewMetricExporterSpi}} then NPE happens:
> {noformat}
> [2019-10-13 12:30:43,611][INFO ][main][root] >>> Starting test:
> SqlViewExporterSpiTest#testDataRegionMetrics <<<
> [2019-10-13 12:30:43,616][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteException: Failed to execute SQL query.
> Внутренняя ошибка: "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException"; SQL statement:
> SELECT REPLACE(name, 'io.dataregion.default.'), value, description FROM
> SYS.METRICS [5-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$executeSelect0$1(IgniteH2Indexing.java:1422)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iter(QueryCursorImpl.java:106)
> at
> org.apache.ignite.internal.processors.cache.query.RegisteredQueryCursor.iter(RegisteredQueryCursor.java:66)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:125)
> at
> org.apache.ignite.internal.processors.cache.metric.SqlViewExporterSpiTest.execute(SqlViewExporterSpiTest.java:589)
> at
> org.apache.ignite.internal.processors.cache.metric.SqlViewExporterSpiTest.testDataRegionMetrics(SqlViewExporterSpiTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [2019-10-13 12:30:43,619][INFO ][main][root] >>> Stopping test:
> SqlViewExporterSpiTest#testDataRegionMetrics in 8 ms <<<
> 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
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2090)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> SQL query. Внутренняя ошибка: "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException"; SQL statement:
> SELECT REPLACE(name, 'io.dataregion.default.'), value, description FROM
> SYS.METRICS [5-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:828)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:909)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$2.iterator(IgniteH2Indexing.java:578)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$2.iterator(IgniteH2Indexing.java:555)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.lambda$executeSelect0$1(IgniteH2Indexing.java:1419)
> ... 15 more
> Caused by: org.h2.jdbc.JdbcSQLException: Внутренняя ошибка:
> "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException"; SQL statement:
> SELECT REPLACE(name, 'io.dataregion.default.'), value, description FROM
> SYS.METRICS [5-197]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:307)
> at org.h2.command.Command.executeQuery(Command.java:216)
> at
> org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:114)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:821)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.spi.metric.sql.MetricRegistryLocalSystemView$1.advance(MetricRegistryLocalSystemView.java:75)
> at
>
[jira] [Updated] (IGNITE-12408) Metrics and SystemView documentation
[ https://issues.apache.org/jira/browse/IGNITE-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12408: - Issue Type: Task (was: Bug) > Metrics and SystemView documentation > > > Key: IGNITE-12408 > URL: https://issues.apache.org/jira/browse/IGNITE-12408 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Nikolay Izhikov >Priority: Blocker > Labels: IEP-35 > Fix For: 2.8 > > > We should provide the following documentation > - metric description. > - system view descirption. > - metrics exporter configuration guide. > - system view exporter configuration guide. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12408) Metrics and SystemView documentation
[ https://issues.apache.org/jira/browse/IGNITE-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12408: - Ignite Flags: (was: Docs Required,Release Notes Required) > Metrics and SystemView documentation > > > Key: IGNITE-12408 > URL: https://issues.apache.org/jira/browse/IGNITE-12408 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Nikolay Izhikov >Priority: Blocker > Labels: IEP-35 > Fix For: 2.8 > > > We should provide the following documentation > - metric description. > - system view descirption. > - metrics exporter configuration guide. > - system view exporter configuration guide. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12405) .NET: WithReadRepair does not work
[ https://issues.apache.org/jira/browse/IGNITE-12405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12405: - Ignite Flags: Docs Required (was: Docs Required,Release Notes Required) > .NET: WithReadRepair does not work > -- > > Key: IGNITE-12405 > URL: https://issues.apache.org/jira/browse/IGNITE-12405 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: .NET > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > WithReadRepair in .NET was partially implemented as part of IGNITE-10663, > however: > * It does not work due to missing Java part (no handling of > CacheOp.WithReadRepair in PlatformCache) > * There are no tests > This new API is not in any release yet, so we should either fix it or remove > from the public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11091) Visor shows all indexes in upper case
[ https://issues.apache.org/jira/browse/IGNITE-11091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11091: - Fix Version/s: (was: 2.8) > Visor shows all indexes in upper case > - > > Key: IGNITE-11091 > URL: https://issues.apache.org/jira/browse/IGNITE-11091 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Igor Akkuratov >Assignee: Igor Akkuratov >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > It's possible to create indexes with same name but in different cases using > SqlFieldsQuery, but visor shows all indexes in upper case. So it's impossible > to select which one you need. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11923) [IEP-35] Migrate IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11923: - Fix Version/s: (was: 2.8) > [IEP-35] Migrate IgniteMXBean > - > > Key: IGNITE-11923 > URL: https://issues.apache.org/jira/browse/IGNITE-11923 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Sergey Kalashnikov >Priority: Major > Labels: IEP-35, await > Time Spent: 10m > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `IgniteMXBean` to the new > metric framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8856) Incorrect behavior of BinaryTypeConfiguration in case of using a wildcard for type names
[
https://issues.apache.org/jira/browse/IGNITE-8856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-8856:
Fix Version/s: (was: 2.8)
> Incorrect behavior of BinaryTypeConfiguration in case of using a wildcard for
> type names
>
>
> Key: IGNITE-8856
> URL: https://issues.apache.org/jira/browse/IGNITE-8856
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>
> Let's consider the following BinaryConfiguration:
> {code:java}
>
>
> ...
>
>
> class="org.apache.ignite.binary.BinaryTypeConfiguration">
> value="org.apache.ignite.examples.*"/>
>
> class="org.apache.ignite.binary.BinaryBasicNameMapper">
> value="false"/>
>
>
>
>
>
>
>
> {code}
> My intention is using custom BinaryBasicMapper for all classes in the
> specified package and its sub packages,
> but BinaryContext implementation matches only classes that reside in the
> "org.apache.ignite.examples" package.
> Classes from sub-packages are not matched, and therefore do not use the
> specified BinaryBasicNameMapper.
> *UPD:*
> Well, it seems that the current behavior is not an error and was implemented
> in this way intentionally.
> On the other hand, I think it would be good to have the ability to specify
> sub-packages as well.
> For example, it can be achieved through the '**' pattern as follows:
> ||example||defenition||priority||
> |org.apache.ignite.examples.TestClass|matches exactly the one class|the
> highest priority|
> |org.apache.ignite.examples.*|matches all classes in the given package|medium|
> |org.apache.ignite.examples.**|matches all classes in the given package and
> its sub-packages|low|
> The proposed enhancement does not break the current behavior and allows to
> specify a filter for sub-packages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12378) .NET: Fix NuGet package warnings
[
https://issues.apache.org/jira/browse/IGNITE-12378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12378:
-
Fix Version/s: (was: 2.8)
> .NET: Fix NuGet package warnings
>
>
> Key: IGNITE-12378
> URL: https://issues.apache.org/jira/browse/IGNITE-12378
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> When uploading a NuGet package, the following warnings are issued:
> * {{The element is deprecated. Consider using the
> element instead.}}
> * {{The element is deprecated. Consider using the element
> instead.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8473) Add option to enable/disable WAL for several caches with single command
[
https://issues.apache.org/jira/browse/IGNITE-8473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-8473:
Fix Version/s: (was: 2.8)
> Add option to enable/disable WAL for several caches with single command
> ---
>
> Key: IGNITE-8473
> URL: https://issues.apache.org/jira/browse/IGNITE-8473
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: newbie
> Time Spent: 10m
> Remaining Estimate: 0h
>
> API method for disabling WAL in IgniteCluster accepts only one cache name.
> Every call triggers exchange and checkpoints cluster-wide - it takes plenty
> of time to disable/enable WAL for multiple caches.
> We should add option to disable/enable WAL for several caches with single
> command.
> New proposed API methods:
> {noformat}
> IgniteCluster.disableWal(Collection cacheNames)
> IgniteCluster.enableWal(Collection cacheNames)
> IgniteCluster.disableWal() // Disables WAL for all caches.
> IgniteCluster.enableWal() // Enables WAL for all caches.
> {noformat}
> Methods should return true if WAL state of at least one cache was actually
> changed by the call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12225:
-
Fix Version/s: (was: 2.8)
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11927) [IEP-35] Add ability to enable\disable subset of metrics
[ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11927: - Fix Version/s: (was: 2.8) > [IEP-35] Add ability to enable\disable subset of metrics > > > Key: IGNITE-11927 > URL: https://issues.apache.org/jira/browse/IGNITE-11927 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Andrey N. Gura >Priority: Major > Labels: IEP-35, await > Time Spent: 20m > Remaining Estimate: 0h > > Ignite should be able to: > * Enable or disable an arbitrary subset of the metrics. User should be able > to do it in runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12332) Fix flaky test GridCacheAtomicClientInvalidPartitionHandlingSelfTest#testPrimaryFullAsync
[ https://issues.apache.org/jira/browse/IGNITE-12332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12332: - Fix Version/s: (was: 2.8) > Fix flaky test > GridCacheAtomicClientInvalidPartitionHandlingSelfTest#testPrimaryFullAsync > - > > Key: IGNITE-12332 > URL: https://issues.apache.org/jira/browse/IGNITE-12332 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Alexei Scherbakov >Priority: Major > > Can be reproduced locally with range = 10_000 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10683) Prepare process of packaging and delivering thin clients
[
https://issues.apache.org/jira/browse/IGNITE-10683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10683:
-
Fix Version/s: (was: 2.8)
> Prepare process of packaging and delivering thin clients
>
>
> Key: IGNITE-10683
> URL: https://issues.apache.org/jira/browse/IGNITE-10683
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
>
> # **NodeJs client**
> #* +Instruction+:
> https://github.com/nobitlost/ignite/blob/ignite--docs/modules/platforms/nodejs/README.md#publish-ignite-nodejs-client-on-npmjscom-instruction
> #* +Uploaded+: https://www.npmjs.com/package/apache-ignite-client
> # **PHP client**
> #* +Instruction+:
> https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md#release-the-client-in-the-php-package-repository-instruction
> {panel}
> Cannot be uploaded on Packagist as the client should be in a dedicated
> repository for that -
> https://issues.apache.org/jira/browse/IGNITE-7783?focusedCommentId=16595476=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16595476
> Installation from the sources works.
> {panel}
> # **Python client**
> I have already registered the package `pyignite` on PyPI[1]. The person who
> is going to take the responsibility of maintaining it should create an
> account on PyPI and mail me in private, so that I can grant them the
> necessary rights. They also must install twine[3].
> The process of packaging is well described in the packaging tutorial[2]. In
> the nutshell, the maintainer must do the following:
> ## Clone/pull the sources from the git repository,
> ## Enter the directory in which the `setup.py` is resides (“the setup
> directory”), in our case it is `modules/platforms/python`.
> ## Create the packages with the command `python3 setup.py sdist bdist_wheel`.
> The packages will be created in `modules/platforms/python/dist` folder.
> ## Upload packages with twine: `twine upload dist/*`.
> It is very useful to have a dedicated Python virtual environment prepared to
> perform steps 3-4. Just do an editable install of `pyignite` into that
> environment from the setup directory: `pip3 install -e .` You can also
> install twine (`pip install twine`) in it.
> Consider also making a `.pypirc` file to save time on logging in to PyPI.
> Newest version of `twine` is said to support keyrings on Linux and Mac, but I
> have not tried this yet.
> [1] https://pypi.org/project/pyignite/
> [2] https://packaging.python.org/tutorials/packaging-projects/
> [3] https://twine.readthedocs.io/en/latest/
> Some other notes on PyPI and versioning.
> - The package version is located in the `setup.py`, it is a `version`
> argument of the `setuptools.setup()` function. Editing the `setup.py` is the
> only way to set the package version.
> - You absolutely can not replace a package in PyPI (hijacking prevention). If
> you have published the package by mistake, all you can do is delete the
> unwanted package, increment the version counter in `setup.py`, and try again.
> - If you upload the package through the web interface of PyPI (without
> twine), the package description will be garbled. Web interface does not
> support markdown.
> Anyway, I would like to join in the congratulations on successful release.
> Kudos to the team.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11312: - Fix Version/s: (was: 2.8) > JDBC: Thin driver doesn't reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Lev Agafonov >Priority: Major > Labels: newbie > Time Spent: 20m > Remaining Estimate: 0h > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12182) ExecutorService is inconsistent with Compute and Services, runs on clients
[ https://issues.apache.org/jira/browse/IGNITE-12182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12182: - Fix Version/s: (was: 2.8) > ExecutorService is inconsistent with Compute and Services, runs on clients > -- > > Key: IGNITE-12182 > URL: https://issues.apache.org/jira/browse/IGNITE-12182 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In IGNITE-860 the default behaviour was changed so that compute and service > tasks would be executed only on server nodes. This is a sensible default and > it's confusing that it's not also true for jobs run using the ExecutorService. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12320) Partial index rebuild fails in case indexed cache contains different datatypes
[
https://issues.apache.org/jira/browse/IGNITE-12320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12320:
-
Fix Version/s: (was: 2.8)
> Partial index rebuild fails in case indexed cache contains different datatypes
> --
>
> Key: IGNITE-12320
> URL: https://issues.apache.org/jira/browse/IGNITE-12320
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem is that in case cache contains different datatypes, all of them
> will be passed to IndexRebuildPartialClosure during iteration over partition.
> Perhaps, TableCacheFilter is supposed to filter out entries of unwanted
> types, but it doesn't work properly.
> Steps to reprocude:
> 1. Add entries of different types (both indexed and not) to cache
> 2. Trigger partial index rebuild
> Index rebuild will fail with the following error:
> {code:java}
> [2019-08-20
> 00:33:55,640][ERROR][pub-#302%h2.GridIndexFullRebuildTest3%][IgniteTestResources]
> 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=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=98629247,
> val2=844420635165670]], msg=Runtime failure on row: %s string representation>]]]
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=98629247,
> val2=844420635165670]], msg=Runtime failure on row: %s string representation>]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5126)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2236)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2183)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:285)
> at
> org.apache.ignite.internal.processors.query.h2.IndexRebuildPartialClosure.apply(IndexRebuildPartialClosure.java:49)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:3867)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processKey(SchemaIndexCacheVisitorImpl.java:254)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartition(SchemaIndexCacheVisitorImpl.java:217)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartitions(SchemaIndexCacheVisitorImpl.java:176)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.visit(SchemaIndexCacheVisitorImpl.java:135)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash0(IgniteH2Indexing.java:2191)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$7.body(IgniteH2Indexing.java:2154)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> get field because type ID of passed object differs from type ID this
> BinaryField belongs to [expected=-635374417, actual=1778229603]
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:287)
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:109)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:220)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:116)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:331)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:122)
> at
>
[jira] [Updated] (IGNITE-12187) [IEP-35] Move GridMetricManager and dependent classes to org.apache.ignite.internal.managers
[
https://issues.apache.org/jira/browse/IGNITE-12187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12187:
-
Fix Version/s: (was: 2.8)
> [IEP-35] Move GridMetricManager and dependent classes to
> org.apache.ignite.internal.managers
>
>
> Key: IGNITE-12187
> URL: https://issues.apache.org/jira/browse/IGNITE-12187
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Amelchev Nikita
>Priority: Trivial
> Labels: IEP-35
>
> Right now metric internal classes are in
> {{org.apache.ignite.internal.processors.metric}} package.
> Seems, we should move it to {{org.apache.ignite.internal.managers.metric}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12259) Create new module for support spring-5.2.X and spring-data-2.2.X
[ https://issues.apache.org/jira/browse/IGNITE-12259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12259: - Fix Version/s: (was: 2.8) > Create new module for support spring-5.2.X and spring-data-2.2.X > > > Key: IGNITE-12259 > URL: https://issues.apache.org/jira/browse/IGNITE-12259 > Project: Ignite > Issue Type: Wish >Reporter: Surkov Aleksandr >Assignee: Surkov Aleksandr >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The actual spring version is > [5.2.0.RELEASE|https://mvnrepository.com/artifact/org.springframework/spring-context/5.2.0.RELEASE], > spring data version is > [2.2.0.RELEASE.|https://mvnrepository.com/artifact/org.springframework.data/spring-data-commons/2.2.0.RELEASE] > It would be nice to add a module to support these versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9974) Drop Hadoop assemblies
[ https://issues.apache.org/jira/browse/IGNITE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9974: Fix Version/s: (was: 2.8) > Drop Hadoop assemblies > -- > > Key: IGNITE-9974 > URL: https://issues.apache.org/jira/browse/IGNITE-9974 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > After dropping Hadoop binaries from release delivery (see IGNITE-9953) it is > required to drop assemblies and corresponding files / profiles if exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8622) Zookeeper and TCP discovery SPI' getSpiState method inconsistent
[ https://issues.apache.org/jira/browse/IGNITE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-8622: Fix Version/s: (was: 2.8) > Zookeeper and TCP discovery SPI' getSpiState method inconsistent > > > Key: IGNITE-8622 > URL: https://issues.apache.org/jira/browse/IGNITE-8622 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Max Shonichev >Assignee: Ryabov Dmitrii >Priority: Minor > Labels: jmx > Time Spent: 10m > Remaining Estimate: 0h > > getSpiState of TcpDiscoverySpi Mbean returns uppercased human-readable state, > e.g. 'CONNECTED' > getSpiState of ZookeeperDiscoverySpi Mbean returns camelcased one, e.g. > 'Connected' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9913) Prevent data updates blocking in case of backup BLT server node leave
[ https://issues.apache.org/jira/browse/IGNITE-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9913: Fix Version/s: (was: 2.8) > Prevent data updates blocking in case of backup BLT server node leave > - > > Key: IGNITE-9913 > URL: https://issues.apache.org/jira/browse/IGNITE-9913 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Anton Vinogradov >Priority: Major > Attachments: 9913_yardstick.png, master_yardstick.png > > Time Spent: 9h > Remaining Estimate: 0h > > Ignite cluster performs distributed partition map exchange when any server > node leaves or joins the topology. > Distributed PME blocks all updates and may take a long time. If all > partitions are assigned according to the baseline topology and server node > leaves, there's no actual need to perform distributed PME: every cluster node > is able to recalculate new affinity assigments and partition states locally. > If we'll implement such lightweight PME and handle mapping and lock requests > on new topology version correctly, updates won't be stopped (except updates > of partitions that lost their primary copy). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12306) .NET: Java version is not taken into account when detecting JAVA_HOME
[ https://issues.apache.org/jira/browse/IGNITE-12306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12306: - Fix Version/s: (was: 2.8) > .NET: Java version is not taken into account when detecting JAVA_HOME > - > > Key: IGNITE-12306 > URL: https://issues.apache.org/jira/browse/IGNITE-12306 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > > When multiple Java versions are installed on the machine, random one is > picked up. > For example, when 7 and 8 are installed, only 8 is suitable for Ignite. > We should check versions and pick the right one: > * Collect all known versions > * Filter out all below 8 > * Pick the lowest > Lower versions are prioritized - we don't want to use latest. Brand new Java > version with breaking changes might be released where Ignite does not work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12389) Make GridCacheQueryFutureAdapter.enqueue() use parameter of List type instead Collection
[
https://issues.apache.org/jira/browse/IGNITE-12389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12389:
-
Fix Version/s: (was: 2.8)
> Make GridCacheQueryFutureAdapter.enqueue() use parameter of List type instead
> Collection
>
>
> Key: IGNITE-12389
> URL: https://issues.apache.org/jira/browse/IGNITE-12389
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7.6
>Reporter: Yuriy Shuliha
>Priority: Minor
>
> Make {{GridCacheQueryFutureAdapter.enqueue(Collection col)}} use parameter
> of List type instead Collection
> This will allow to avoid new {{ArrayList}} creation and directly call
> performance tolerant {{List.subList()}} method .
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12321) Rebalance doesn't happen after restart if node failed at the moment of rebalance.
[ https://issues.apache.org/jira/browse/IGNITE-12321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12321: - Fix Version/s: (was: 2.8) > Rebalance doesn't happen after restart if node failed at the moment of > rebalance. > - > > Key: IGNITE-12321 > URL: https://issues.apache.org/jira/browse/IGNITE-12321 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Steps to reproduce: > 1. Start 2 nodes in baseline > 2. Stream a lot of data. > 3. Stop the second node, clean the persistence and start it again(with the > same consistent id > 4. Kill the first node at the moment of rebalancing (make sure that not all > data was rebalanced) > 5. Partition loss will be detected. > 6. Return first node to the cluster. > 7. Result: > Data is not rebalanced, All data(primary and backup) is stored on the first > node only, while the second node has the same small subset of the data. It's > reproducible with any Partition loss policy. Resetting lost partitions, > activation/deactivation doesn't help. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12266) Add limit parameter to Platforms for processing TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12266: - Fix Version/s: (was: 2.8) > Add limit parameter to Platforms for processing TextQuery > - > > Key: IGNITE-12266 > URL: https://issues.apache.org/jira/browse/IGNITE-12266 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11987) [IEP-35] Add ability to configure metrics
[ https://issues.apache.org/jira/browse/IGNITE-11987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11987: - Fix Version/s: (was: 2.8) > [IEP-35] Add ability to configure metrics > - > > Key: IGNITE-11987 > URL: https://issues.apache.org/jira/browse/IGNITE-11987 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Time Spent: 3h 50m > Remaining Estimate: 0h > > Ignite should be able to: > * Configure Histogram metrics > * Configure HitRate metrics. > We should provide 2 ways to configure metric: > 1. -Configuration file.- Discussed on dev-list. Agreed to go with the > simplest solution - JMX method. > 2. JMX method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-8550:
Fix Version/s: (was: 2.8)
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12131) MMAP mode should be disabled by default for WAL manager
[ https://issues.apache.org/jira/browse/IGNITE-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12131: - Fix Version/s: (was: 2.8) > MMAP mode should be disabled by default for WAL manager > --- > > Key: IGNITE-12131 > URL: https://issues.apache.org/jira/browse/IGNITE-12131 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > MMAP mode has a bunch of problems (see for example > http://www.mapdb.org/blog/mmap_files_alloc_and_jvm_crash/ ) > Users are increasingly stumbling over these issues especially in virtualized > environments. > MMAP should be disabled by default because it requires additional care from > user stand point. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12354) QueryTimeoutException need to be added to differentiate query is cancelled due to timeout
[ https://issues.apache.org/jira/browse/IGNITE-12354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12354: - Fix Version/s: (was: 2.8) > QueryTimeoutException need to be added to differentiate query is cancelled > due to timeout > - > > Key: IGNITE-12354 > URL: https://issues.apache.org/jira/browse/IGNITE-12354 > Project: Ignite > Issue Type: Improvement > Components: platforms, sql >Affects Versions: 2.3 >Reporter: Saikat Maitra >Priority: Minor > > QueryTimeoutException need to be added to differentiate query is cancelled > due to timeout. > > As of today when Sql query get executed and does not return results in > specified timeout we throw exception as QueryCancellationException. There is > no way to differentiate if Sql query is cancelled by user manually or it is > cancelled due to timeout. > It will be better if we can separate exception with error message thrown when > Sql query is cancelled due to timeout reasons. > > It is related to https://issues.apache.org/jira/browse/IGNITE-7285 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12200) More informative assertion message at constructor of CachedDeploymentInfo (GridCacheDeploymentManager class)
[
https://issues.apache.org/jira/browse/IGNITE-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12200:
-
Fix Version/s: (was: 2.8)
> More informative assertion message at constructor of CachedDeploymentInfo
> (GridCacheDeploymentManager class)
>
>
> Key: IGNITE-12200
> URL: https://issues.apache.org/jira/browse/IGNITE-12200
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5, 2.7.5
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> /**
> * @param sndId Sender.
> * @param ldrId Loader ID.
> * @param userVer User version.
> * @param depMode Deployment mode.
> * @param participants Participants.
> */
> private CachedDeploymentInfo(UUID sndId, IgniteUuid ldrId, String userVer,
> DeploymentMode depMode,
> Map participants) {
> assert sndId.equals(ldrId.globalId()) || participants != null;
> this.sndId = sndId;
> this.ldrId = ldrId;
> this.userVer = userVer;
> this.depMode = depMode;
> this.participants = participants == null || participants.isEmpty() ? null
> :
> new ConcurrentLinkedHashMap<>(participants);
> }
> {code}
> The code above may produce the following stacktrace, where AssertionError
> should contain more informative message for better root cause analysis:
> {noformat}
> 2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2019-09-17
> 18:29:29.912[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
> Critical system error detected. Will be handled accordingly to configured
>
[jira] [Updated] (IGNITE-11609) Add support of authentication and SSL in yardstick IgniteThinClient benchmark
[ https://issues.apache.org/jira/browse/IGNITE-11609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11609: - Fix Version/s: (was: 2.8) > Add support of authentication and SSL in yardstick IgniteThinClient benchmark > - > > Key: IGNITE-11609 > URL: https://issues.apache.org/jira/browse/IGNITE-11609 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.7 >Reporter: Dmitry Sherstobitov >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Add support of following keys: > Mandatory authentication: > USER > PASSWORD > Mandatory SSL: > SSL_KEY_PASSWORD > SSL_KEY_PATH > Optional SSL: > SSL_CLIENT_STORE_TYPE (default JKS) > SSL_SERVER_STORE_TYPE (default JKS) > SSL_KEY_ALGORITHM (default SunX509) > SSL_TRUST_ALL (default false) > SSL_PROTOCOL (default TLS) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12326) JDBC thin returns java.util.Date instead of java.sql.Date if input values, putted to cache via cache API are LocalDate or java.sql.Date.
[ https://issues.apache.org/jira/browse/IGNITE-12326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12326: - Fix Version/s: (was: 2.8) > JDBC thin returns java.util.Date instead of java.sql.Date if input values, > putted to cache via cache API are LocalDate or java.sql.Date. > - > > Key: IGNITE-12326 > URL: https://issues.apache.org/jira/browse/IGNITE-12326 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > > JDBC thin returns java.util.Date instead of java.sql.Date if input values, > putted to cache via cache API are LocalDate or java.sql.Date. > Reproducers: > org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testSqlDateDataType > org.apache.ignite.jdbc.thin.JdbcThinCacheToJdbcDataTypesCoverageTest#testLocalDateDataType -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12192: - Fix Version/s: (was: 2.8) > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12236: - Fix Version/s: (was: 2.8) > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > Labels: newbie, patch > Time Spent: 10m > Remaining Estimate: 0h > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any up to date version of spring. Fixing > this would require updating that's the reason I'm > puting this as Improvement. > > [dev-list > discussion|[http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12236-RepositoryFactorySupport-getQueryLookupStrategy-no-longer-overriden-in-IgniteRepositoryy-tc43932.html]] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12190) Throw an exception for enabled text queries on persistent caches
[ https://issues.apache.org/jira/browse/IGNITE-12190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12190: - Fix Version/s: (was: 2.8) > Throw an exception for enabled text queries on persistent caches > > > Key: IGNITE-12190 > URL: https://issues.apache.org/jira/browse/IGNITE-12190 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > > As TEXT queries cannot be used with persistent caches we should throw a > meaningful exception when a TEXT query is executed against a persistent cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12308) Data types coverage for basic sql operations.
[ https://issues.apache.org/jira/browse/IGNITE-12308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12308: - Fix Version/s: (was: 2.8) > Data types coverage for basic sql operations. > - > > Key: IGNITE-12308 > URL: https://issues.apache.org/jira/browse/IGNITE-12308 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For more details see: https://issues.apache.org/jira/browse/IGNITE-12307 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12220:
-
Fix Version/s: (was: 2.8)
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12297) Detect lost partitions is not happened during cluster activation
[ https://issues.apache.org/jira/browse/IGNITE-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12297: - Fix Version/s: (was: 2.8) > Detect lost partitions is not happened during cluster activation > > > Key: IGNITE-12297 > URL: https://issues.apache.org/jira/browse/IGNITE-12297 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Kovalenko >Priority: Major > > We invoke `detectLostPartitions` during PME only if there is a server join or > server left. > However, we can activate a persistent cluster where a partition may have > MOVING status on all nodes. In this case, a partition may stay in MOVING > state forever before any other topology event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12307) Data types coverage for basic cache operations.
[ https://issues.apache.org/jira/browse/IGNITE-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12307: - Fix Version/s: (was: 2.8) > Data types coverage for basic cache operations. > --- > > Key: IGNITE-12307 > URL: https://issues.apache.org/jira/browse/IGNITE-12307 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The data types used for testing are not collected at single test/suite and > it's not clear which types are covered and which not. We should redesign the > coverage and cover following > Operations: > * put > * putAll > * remove > * removeAll > * get > * getAll > Data Types both for value and key (if applicable): > * byte/Byte > * short/Short > * int/Integer > * long/Long > * float/Float > * double/Double > * boolean/Boolean > * char/String > * Arrays of primitives (single type) > * Arrays of Objects (different types) > * Collections > ** List > ** Queue > ** Set > * Objects based on: > ** primitives only > ** primitives + collections > ** primitives + collections + nested objects > Persistance mode: > * in-memory > * PDS > Cache configurations: > * atomic/tx/mvcc > * replication/partitioned > * TTL/no TTL > * QueryEntnty > * Backups=1,2 > * EvictionPolicy > * writeSynchronizationMode(FULL_SYNC, PRIMARY_SYNC, FULL_ASYNC) > * onheapCacheEnabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12207) Inclusion of super.toString() info into some descenders of GridCacheMessage
[
https://issues.apache.org/jira/browse/IGNITE-12207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12207:
-
Fix Version/s: (was: 2.8)
> Inclusion of super.toString() info into some descenders of GridCacheMessage
> ---
>
> Key: IGNITE-12207
> URL: https://issues.apache.org/jira/browse/IGNITE-12207
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7, 2.7.6
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes when errors related to processing of descenders of GridCacheMessage
> happens, we could need information which contained at the GridCacheMessage
> class, in particular deployment information, contained if depInfo field. In
> the some message classes which extends GridCacheMessage, toString() method
> doesn't include the 'super' part, so we haven't that information at log error
> messages, as at example below:
> {noformat}
> 2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The assertion condition which produced error above includes the value which
> obtained from GridCacheMessage.depInfo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12111) Cluster ID and tag: properties to identify the cluster
[ https://issues.apache.org/jira/browse/IGNITE-12111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12111: - Fix Version/s: (was: 2.8) > Cluster ID and tag: properties to identify the cluster > -- > > Key: IGNITE-12111 > URL: https://issues.apache.org/jira/browse/IGNITE-12111 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > > To improve cluster management capabilities two new properties of the cluster > are introduced: > # A unique cluster ID (may be either a random UUID or random IgniteUUID). > Generated upon cluster start and saved to the distributed metastorage. > Immutable. Persistent clusters must persist the value. In-memory clusters > should keep the generated ID in memory and regenerate it upon restart. > # Human-readable cluster tag. Generated by default to some random (but still > meaningful) string, may be changed by user. Again survives restart in > persistent clusters and is regenerated in in-memory clusters on every restart. > These properties are exposed to standard APIs: > # EVT_CLUSTER_TAG_CHANGED event generated when tag is changed by user; > # JMX bean and control utility APIs to view ID and tag and change tag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11992) Improvements for new security approach
[ https://issues.apache.org/jira/browse/IGNITE-11992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11992: - Fix Version/s: (was: 2.8) > Improvements for new security approach > -- > > Key: IGNITE-11992 > URL: https://issues.apache.org/jira/browse/IGNITE-11992 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.8 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > 1. The visor tasks lost permission. > The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses > context. > 2. The GridRestProcessor does tasks outside "withContext" section. As result > context loses. > In additional: > Change a java docs for TaskEvent, CacheEvent, CacheQueryExecutedEvent and > CacheQueryReadEvent. > "Gets security subject ID initiated this task event, if available. > This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET > task event. > Subject ID will be set either to node ID or client ID initiated task > execution." > by: > "Gets security subject ID initiated this task event if IgniteSecurity is > enabled, otherwise returns null." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12296) .NET: Implement Log Throttle and print warning for unsafe PutAll ops
[ https://issues.apache.org/jira/browse/IGNITE-12296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12296: - Fix Version/s: (was: 2.8) > .NET: Implement Log Throttle and print warning for unsafe PutAll ops > > > Key: IGNITE-12296 > URL: https://issues.apache.org/jira/browse/IGNITE-12296 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ilya Kasnacheev >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Right now it's not possible to do one-time developer warnings in .Net as > there is no Log Throttle. Please implement one. Please also issue warning if > random-order collection is passed to PutAll, InvokeAll, RemoveAll, as it is > prime source for deadlocks and developer frustration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11704: - Fix Version/s: (was: 2.8) > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: rebalance > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11977) Data streamer pool MXBean is registered as ThreadPoolMXBean instead of StripedExecutorMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11977: - Fix Version/s: (was: 2.8) > Data streamer pool MXBean is registered as ThreadPoolMXBean instead of > StripedExecutorMXBean > > > Key: IGNITE-11977 > URL: https://issues.apache.org/jira/browse/IGNITE-11977 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stanislav Lukyanov >Assignee: Ruslan Kamashev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Data streamer pool is registered with a ThreadPoolMXBean while it is actually > a StripedExecutor and can use a StripedExecutorMXBean. > Need to change the registration in the IgniteKernal code. It should be > registered the same way as the striped executor pool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12380) Add event for node validation failure.
[ https://issues.apache.org/jira/browse/IGNITE-12380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12380: - Fix Version/s: (was: 2.8) > Add event for node validation failure. > -- > > Key: IGNITE-12380 > URL: https://issues.apache.org/jira/browse/IGNITE-12380 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > It's needed record an event of a special type in case a node can't join the > topology due to a failure of its validation by existing nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12188) Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly if there is more then one cache in cache group
[
https://issues.apache.org/jira/browse/IGNITE-12188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12188:
-
Fix Version/s: (was: 2.8)
> Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly
> if there is more then one cache in cache group
>
>
> Key: IGNITE-12188
> URL: https://issues.apache.org/jira/browse/IGNITE-12188
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Aleksey Plekhanov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-35, await
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Initial partitions counter is set to a total number of partitions for cache
> group but decremented each time partition processed for each cache.
> Reproducer:
> {code:java}
> @Test
> public void testIndexRebuildMetrics() throws Exception {
> IgniteEx ignite = startGrid(new IgniteConfiguration()
> .setConsistentId("ignite")
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)))
> .setCacheConfiguration(
> new CacheConfiguration Integer>("c1").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class),
> new CacheConfiguration Integer>("c2").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class)
> ));
> ignite.cluster().active(true);
> for (int i = 0; i < 10_000; i++)
> ignite.cache("c1").put(i, i);
> ignite.cluster().active(false);
> File dir = U.resolveWorkDirectory(U.defaultWorkDirectory(),
> DFLT_STORE_DIR, false);
> U.delete(new File(dir, "ignite/cacheGroup-grp/index.bin"));
> ignite.cluster().active(true);
> doSleep(1_000L);
>
> assertTrue(ignite.context().cache().cache("c1").context().group().metrics().getIndexBuildCountPartitionsLeft()
> >= 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7285:
Fix Version/s: (was: 2.8)
> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
> Labels: sql-stability
> Time Spent: 10h 40m
> Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be
> very useful to have default timeout value provided on cache startup. Let's
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12108) [IEP-35] Migrate Communication Metrics.
[ https://issues.apache.org/jira/browse/IGNITE-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12108: - Fix Version/s: (was: 2.8) > [IEP-35] Migrate Communication Metrics. > --- > > Key: IGNITE-12108 > URL: https://issues.apache.org/jira/browse/IGNITE-12108 > Project: Ignite > Issue Type: New Feature >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-35, await > Time Spent: 7h > Remaining Estimate: 0h > > ||*Name*||*Description*|| > |communication.tcp.outboundMessagesQueueSize|Number of messages waiting to be > sent| > |communication.tcp.sentBytes|Total number of bytes received by current node| > |communication.tcp.receivedBytes|Total number of bytes sent by current node| > |communication.tcp.sentMessagesCount|Total number of messages sent by current > node| > |communication.tcp.receivedMessagesCount|Total number of messages received by > current node| > |communication.tcp.sentMessagesByType.|Total number of messages > with given type sent by current node| > |communication.tcp.receivedMessagesByType.|Total number of > messages with given type received by current node| > |communication.tcp..sentMessagesToNode|Total number of messages sent > by current node to the given node| > |communication.tcp..receivedMessagesFromNode|Total number of messages > received by current node from the given node| > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11707) Tcp Discovery should drop pending metrics update message when new message is received
[ https://issues.apache.org/jira/browse/IGNITE-11707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11707: - Fix Version/s: (was: 2.8) > Tcp Discovery should drop pending metrics update message when new message is > received > - > > Key: IGNITE-11707 > URL: https://issues.apache.org/jira/browse/IGNITE-11707 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > > I've stumbled across the following behavior on a large cluster with large > number of caches: > When several new nodes are being added to the cluster, a client node may hang > infinitely on join. On server nodes one can observe tcp discovery message > worker continuously processing metrics update messages and writing metrics to > socket. From the logs it was clear that the cluster generated a lot of > metrics update messages and a node could not cope with it. > Even when metrics update message is generated on coordinator, this scenario > is possible when message round-trip/processing time is compared to the > metrics update frequency. > To mitigate the issue, we should drop a not-yet-processed metrics update > message when a new metrics update message is received. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-1436) C++: Port to MAC OS.
[ https://issues.apache.org/jira/browse/IGNITE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-1436: Fix Version/s: (was: 2.8) > C++: Port to MAC OS. > > > Key: IGNITE-1436 > URL: https://issues.apache.org/jira/browse/IGNITE-1436 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Stephen Darlington >Priority: Major > Labels: cpp > Time Spent: 10m > Remaining Estimate: 0h > > It will require minimal porting of "common" and "utils" stuff. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12317) Add EvictionFilter factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-12317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12317: - Fix Version/s: (was: 2.8) > Add EvictionFilter factory support in IgniteConfiguration. > -- > > Key: IGNITE-12317 > URL: https://issues.apache.org/jira/browse/IGNITE-12317 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Nikolai Kulagin >Assignee: Nikolai Kulagin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some entities on cache configuration are configured via factories, while > others are set directly, for example, eviction policy and eviction filter. > Need to add new configuration properties for eviction filter factory and > deprecate old ones (do not remove for compatibility). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6803) UriDeploymentSpi affects execution of other tasks, including Ignite internals
[
https://issues.apache.org/jira/browse/IGNITE-6803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-6803:
Fix Version/s: (was: 2.8)
> UriDeploymentSpi affects execution of other tasks, including Ignite internals
> -
>
> Key: IGNITE-6803
> URL: https://issues.apache.org/jira/browse/IGNITE-6803
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Assignee: Alexey Goncharuk
>Priority: Major
> Attachments: tc.png
>
>
> From the maillist:
> http://apache-ignite-users.70518.x6.nabble.com/Code-deployment-throught-UriDeploumentSpi-tt17807.html
> In our project we need to deploy custom compute tasks into cluster without
> cluster restart and p2p class loading.
> I try to use org.apache.ignite.spi.deployment.uri.UriDeploumentSpi for that
> purpose, but I have a problem.
> I have simple Ignite Service and Ignite Compute Task which use it throught
> @ServiceResource.
> This ComputeTask located into .gar file which was deployed via
> UriDeploumentSpi.
> If I have service implementation on each node(node singleton service) then it
> works great.
> But if I deploy service as a cluster singleton then task executes correctly
> only on node with this service.
> On other nodes @ServiceResource returns ServiceProxy that throws exception on
> service remote method invokation (lambda with service call cannot be
> deployed):
> {code}
> SEVERE: Failed to execute job
> [jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86,
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl [taskName=task-one,
> dep=GridDeployment [ts=1509275650885, depMode=SHARED,
> clsLdr=GridUriDeploymentClassLoader
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
> clsLdrId=7eb15d76f51-428ec712-e6d0-4eab-97f9-ce58d7b3e0f5, userVer=0,
> loc=true, sampleClsName=com.gridfore.tfedyanin.deploy.Task1,
> pendingUndeploy=false, undeployed=false, usage=1],
> taskClsName=com.gridfore.tfedyanin.deploy.Task1,
> sesId=38a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86,
> startTime=1509275650601, endTime=9223372036854775807,
> taskNodeId=7919c34c-9a48-4068-bcd6-70dad5595e86,
> clsLdr=GridUriDeploymentClassLoader
> [urls=[file:/C:/IdeaProjects/dmp_code_deployment/test/out/deployment/gg.uri.deployment.tmp/428ec712-e6d0-4eab-97f9-ce58d7b3e0f5/dirzip_task-one6814855127293591501.gar/]],
> closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1,
> fullSup=false, internal=false, subjId=7919c34c-9a48-4068-bcd6-70dad5595e86,
> mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false,
> state=INIT, res=null, hash=1254296516]], execName=null],
> jobId=68a96d76f51-7919c34c-9a48-4068-bcd6-70dad5595e86]]
> class org.apache.ignite.IgniteDeploymentException: Failed to auto-deploy task
> (was task (re|un)deployed?): class
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceTopologyCallable
> {code}
> Problem works as follows:
> - Ignite has to determine which node has deployed service, by name.
> - Ignite has to send ServiceTopologyCallable task.
> - Ignite tries to deploy ServiceTopologyCallable task using UriDeploymentSpi.
> - UriDeploymentSpi doesn't have it obviously, but it also tries to fallback
> towards "CLASS" loading from local ClassLoader
> - Which fails because it is told that ServiceTopologyCallable comes from its
> classloader and not from the local one!
> So I'm at loss where it should be fixed properly. It is also sad that we are
> using all that deploy pipeline to handle IgniteInternal tasks, but there
> obviously are non-internal local tasks which might be affected by same
> problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12193) [Phase-1] Rebalancing cache group keys metric counters
[ https://issues.apache.org/jira/browse/IGNITE-12193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12193: - Priority: Critical (was: Major) > [Phase-1] Rebalancing cache group keys metric counters > -- > > Key: IGNITE-12193 > URL: https://issues.apache.org/jira/browse/IGNITE-12193 > Project: Ignite > Issue Type: Sub-task >Reporter: Maxim Muzafarov >Assignee: Nikolai Kulagin >Priority: Critical > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 2h > Remaining Estimate: 0h > > Implement metrics counters related to the cache group: > * rebalancingPartitionsLeft long metric > * rebalancingReceivedKeys long metric > * rebalancingReceivedBytes long metric > * rebalancingStartTime long metric > * rebalancingFinishTime long metric -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12194) [Phase-2] Calculate expected rebalancing cache group keys
[ https://issues.apache.org/jira/browse/IGNITE-12194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12194: - Priority: Critical (was: Major) > [Phase-2] Calculate expected rebalancing cache group keys > - > > Key: IGNITE-12194 > URL: https://issues.apache.org/jira/browse/IGNITE-12194 > Project: Ignite > Issue Type: Sub-task >Reporter: Maxim Muzafarov >Priority: Critical > Labels: IEP-35 > Fix For: 2.8 > > > We need to implement expected to be rebalanced cache group keys and total > bytes. Currently, 'estimatedKeysCount' cache metric returns '-1' for some of > the cases (see comments IGNITE-11330). > * rebalancingExpectedKeys long metric > * rebalancingExpectedBytes long metric > * rebalancingEvictedPartitionsLeft long metric -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12411) [ML] Finish ML API and fix typos in method names
[ https://issues.apache.org/jira/browse/IGNITE-12411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-12411. -- Resolution: Fixed > [ML] Finish ML API and fix typos in method names > > > Key: IGNITE-12411 > URL: https://issues.apache.org/jira/browse/IGNITE-12411 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > There are a few typos in method naming that should be fixed before 2.8 release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987950#comment-16987950 ] Maxim Muzafarov commented on IGNITE-11704: -- Commit reverted as discussed on dev-list. The issue reopened. > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: rebalance > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reopened IGNITE-11704: -- Assignee: (was: Pavel Kovalenko) > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: rebalance > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12416) Avoid using deprecated the Ignite.active(boolean) methods in project
[ https://issues.apache.org/jira/browse/IGNITE-12416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12416: - Summary: Avoid using deprecated the Ignite.active(boolean) methods in project (was: Avoid use deprecated the Ignite.active(boolean) methods in project) > Avoid using deprecated the Ignite.active(boolean) methods in project > > > Key: IGNITE-12416 > URL: https://issues.apache.org/jira/browse/IGNITE-12416 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > > IgniteCluster#active(boolean) should be used instead of Ignite#active(boolean) > IgniteCluster#active() should be used instead of Ignite#active() > Since IEP-4 was merged and deprecates cluster activation methods > Deprecated methods usages provide many warnings on the build project stage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12416) Avoid use deprecated the Ignite.active(boolean) methods in project
Amelchev Nikita created IGNITE-12416: Summary: Avoid use deprecated the Ignite.active(boolean) methods in project Key: IGNITE-12416 URL: https://issues.apache.org/jira/browse/IGNITE-12416 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Assignee: Amelchev Nikita IgniteCluster#active(boolean) should be used instead of Ignite#active(boolean) IgniteCluster#active() should be used instead of Ignite#active() Since IEP-4 was merged and deprecates cluster activation methods Deprecated methods usages provide many warnings on the build project stage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12412) Incomplete check for ABA problem in PageMemoryImpl#PagePool
[
https://issues.apache.org/jira/browse/IGNITE-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987804#comment-16987804
]
Andrey N. Gura commented on IGNITE-12412:
-
@[~agoncharuk] I left a few comments to the PR. Please, take a look.
> Incomplete check for ABA problem in PageMemoryImpl#PagePool
> ---
>
> Key: IGNITE-12412
> URL: https://issues.apache.org/jira/browse/IGNITE-12412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In current implementation, {{PagePool#releasePage}} clears the counter part
> of the returned page ID, which effectively disables the ABA check intended in
> the class. This issue can be rarely reproduced on zOS during checkpoints
> (when pages are being taken and returned to the checkpoint pages pool).
> I managed to write a unit-test to reproduce this issue on x86.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[
https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987788#comment-16987788
]
Maxim Muzafarov commented on IGNITE-11704:
--
Flaky failure with corrupted B+Tree in the master branch.
https://ci.ignite.apache.org/viewLog.html?buildId=4807946=buildResultsDiv=IgniteTests24Java8_Cache9#testNameId1910487508546147692
{code:java}
class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1544803905,
val2=844420635196573]], msg=Runtime failure on cursor iteration]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5927)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5438)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5661)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl$1.next(IgniteCacheOffheapManagerImpl.java:3020)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition$2.hasNextX(GridDhtLocalPartition.java:1226)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.doClear(GridDhtLocalPartition.java:1295)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.clearTombstones(GridDhtLocalPartition.java:1242)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.PartitionsEvictManager$ClearTombstonesTask.run0(PartitionsEvictManager.java:673)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.PartitionsEvictManager$AbstractEvictionTask.run(PartitionsEvictManager.java:587)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7061)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.AssertionError: Key is not ready: CacheDataRowAdapter
[key=null, val=null, expireTime=-1, ver=null, cacheId=0, link=0001003c77d8]
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.key(CacheDataRowAdapter.java:837)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:382)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:63)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:5200)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.findLowerBound(BPlusTree.java:5317)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.fillFromBuffer0(BPlusTree.java:5588)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.fillFromBuffer(BPlusTree.java:5376)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5428)
... 14 more {code}
> Write tombstones during rebalance to get rid of deferred delete buffer
> --
>
> Key: IGNITE-11704
> URL: https://issues.apache.org/jira/browse/IGNITE-11704
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Pavel Kovalenko
>Priority: Major
> Labels: rebalance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently Ignite relies on deferred delete buffer in order to handle
> write-remove conflicts during rebalance. Given the limit size of the buffer,
> this approach is fundamentally flawed, especially in case when persistence is
> enabled.
> I suggest to extend the logic of data storage to be able to store key
> tombstones - to keep version for deleted entries. The tombstones will be
> stored when rebalance is in progress and should be cleaned up when rebalance
> is completed.
> Later this approach may be used to implement fast partition rebalance based
> on merkle trees (in this case, tombstones should be written on an
[jira] [Updated] (IGNITE-12374) Too low performance ~200TPS for single ODBC client
[
https://issues.apache.org/jira/browse/IGNITE-12374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12374:
Description:
Hi, in our test ignite performance with ODBC connection is too bad to proceed
with product integration. It is about ~200 TPS, each transaction with
select+update operation.
Please refer to attach sample program. It is just a simple test case.
Based on the profiling most of the time consumed by sql execution. Please
advice if the application did not do the right thing.
Thank you.
local ignite server, but the result same to remote container Ignite deployment
too.
{{cat /etc/apache-ignite/my-config.xml}}
{noformat}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{noformat}
{{g++ -I/usr/include -I./ignite/binary/include -I./ignite/common/include
-I./ignite/common/os/linux/include -I./ignite/common/os/win/include
-I./ignite/core/include -I./ignite/jni/include odbcsample.cc -o odbcsample
-lodbc -L./ignite-libs/libignite.so -L./ignite-libs/libignite-odbc.so}}
was:
Hi, in our test ignite performance with ODBC connection is too bad to proceed
with product integration. It is about ~200 TPS, each transaction with
select+update operation.
Please refer to attach sample program. It is just a simple test case.
Based on the profiling most of the time consumed by sql execution. Please
advice if the application did not do the right thing.
Thank you.
local ignite server, but the result same to remote container Ignite deployment
too.
cat /etc/apache-ignite/my-config.xml
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
g++ -I/usr/include -I./ignite/binary/include -I./ignite/common/include
-I./ignite/common/os/linux/include -I./ignite/common/os/win/include
-I./ignite/core/include -I./ignite/jni/include odbcsample.cc -o odbcsample
-lodbc -L./ignite-libs/libignite.so -L./ignite-libs/libignite-odbc.so
> Too low performance ~200TPS for single ODBC client
> --
>
> Key: IGNITE-12374
> URL: https://issues.apache.org/jira/browse/IGNITE-12374
> Project: Ignite
> Issue Type: Improvement
> Components: clients, odbc
>Affects Versions: 2.7.5
> Environment: Ignite server run on top of Kubernetes, with 2 server
> nodes, persistence enabled. Both CPU and RAM at server/client server is
> sufficient according to system reports.
>Reporter: swy
>Priority: Major
> Attachments: ignite-9bb53f34.0.log,
> ignite-logs-config-source-20191128.zip,
> ignite-logs-config-source-20191129.zip, my-config-zstan.xml, odbcsample,
> odbcsample.allchar.rebind.cc, odbcsample.cc, profiling01.png,
> profiling03.png, profling02.png, screenshot-1.png,
> snapshot-1574845275597.nps, threaddump-1573207804944.tdump,
> threaddump-1574845414243.tdump, values.yaml
>
>
> Hi, in our test ignite performance with ODBC connection is too bad to proceed
> with product integration. It is about ~200 TPS, each transaction with
> select+update operation.
> Please refer to attach sample program. It is just a simple test case.
> Based on the profiling most of the time consumed by sql execution. Please
> advice if the application did not do the right thing.
> Thank you.
> local ignite server, but the result same to remote container Ignite
> deployment too.
> {{cat /etc/apache-ignite/my-config.xml}}
> {noformat}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
> class="org.apache.ignite.configuration.ClientConnectorConfiguration"/>
>
>
>
>
>
> class="org.apache.ignite.binary.BinaryBasicIdMapper">
>
>
>
>
>
>
[jira] [Commented] (IGNITE-12188) Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly if there is more then one cache in cache group
[
https://issues.apache.org/jira/browse/IGNITE-12188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987750#comment-16987750
]
Aleksey Plekhanov commented on IGNITE-12188:
[~NSAmelchev], looks good to me. Please request bot visa after last changes.
> Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly
> if there is more then one cache in cache group
>
>
> Key: IGNITE-12188
> URL: https://issues.apache.org/jira/browse/IGNITE-12188
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Aleksey Plekhanov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-35, await
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Initial partitions counter is set to a total number of partitions for cache
> group but decremented each time partition processed for each cache.
> Reproducer:
> {code:java}
> @Test
> public void testIndexRebuildMetrics() throws Exception {
> IgniteEx ignite = startGrid(new IgniteConfiguration()
> .setConsistentId("ignite")
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)))
> .setCacheConfiguration(
> new CacheConfiguration Integer>("c1").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class),
> new CacheConfiguration Integer>("c2").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class)
> ));
> ignite.cluster().active(true);
> for (int i = 0; i < 10_000; i++)
> ignite.cache("c1").put(i, i);
> ignite.cluster().active(false);
> File dir = U.resolveWorkDirectory(U.defaultWorkDirectory(),
> DFLT_STORE_DIR, false);
> U.delete(new File(dir, "ignite/cacheGroup-grp/index.bin"));
> ignite.cluster().active(true);
> doSleep(1_000L);
>
> assertTrue(ignite.context().cache().cache("c1").context().group().metrics().getIndexBuildCountPartitionsLeft()
> >= 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-5378) JDBC thin: support query cancellation
[
https://issues.apache.org/jira/browse/IGNITE-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-5378:
---
Fix Version/s: (was: 2.1)
> JDBC thin: support query cancellation
> -
>
> Key: IGNITE-5378
> URL: https://issues.apache.org/jira/browse/IGNITE-5378
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Reporter: Vladimir Ozerov
>Priority: Major
>
> We need to support {{Statement.cancel()}} for thin JDBC driver. Ignite
> already able to cancel queries on a server side, so we should simply create
> new request-response pair for this.
> Special attention should be dedicated to precise specification semantics.
> Namely, query could be started from the one thread, but cancelled from
> another. Hence, concurrency should be implemented accurately.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8343) InetSocketAddress.getAddress() returns null, should check it in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-8343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-8343:
Priority: Critical (was: Major)
> InetSocketAddress.getAddress() returns null, should check it in
> TcpCommunicationSpi
> ---
>
> Key: IGNITE-8343
> URL: https://issues.apache.org/jira/browse/IGNITE-8343
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: test
> Attachments: TcpDiscoveryMultiJvmTest.java
>
>
> This is especially notorious in the following scenario:
> {code}
> // -Djava.net.preferIPv4Stack=true
> System.err.println(new InetSocketAddress("0:0:0:0:0:0:0:1%lo",
> 12345).getAddress()); // null
> {code}
> Yes we already warn if different nodes have differing preferIPv4Stack, still
> this is warning not a error, and there may be other cases where getAddress()
> returns null. Should make a check.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12412) Incomplete check for ABA problem in PageMemoryImpl#PagePool
[
https://issues.apache.org/jira/browse/IGNITE-12412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987683#comment-16987683
]
Alexey Goncharuk commented on IGNITE-12412:
---
[~agura], please take a look as well.
> Incomplete check for ABA problem in PageMemoryImpl#PagePool
> ---
>
> Key: IGNITE-12412
> URL: https://issues.apache.org/jira/browse/IGNITE-12412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In current implementation, {{PagePool#releasePage}} clears the counter part
> of the returned page ID, which effectively disables the ABA check intended in
> the class. This issue can be rarely reproduced on zOS during checkpoints
> (when pages are being taken and returned to the checkpoint pages pool).
> I managed to write a unit-test to reproduce this issue on x86.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12374) Too low performance ~200TPS for single ODBC client
[ https://issues.apache.org/jira/browse/IGNITE-12374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987679#comment-16987679 ] swy commented on IGNITE-12374: -- The intention is to have single instance run as closer as 10k to meet our target. In real case the logic will be much more complex including different data type so it will be challenging with current performance. So any further help will be appreciated to boost the performance to maximum. > Too low performance ~200TPS for single ODBC client > -- > > Key: IGNITE-12374 > URL: https://issues.apache.org/jira/browse/IGNITE-12374 > Project: Ignite > Issue Type: Improvement > Components: clients, odbc >Affects Versions: 2.7.5 > Environment: Ignite server run on top of Kubernetes, with 2 server > nodes, persistence enabled. Both CPU and RAM at server/client server is > sufficient according to system reports. >Reporter: swy >Priority: Major > Attachments: ignite-9bb53f34.0.log, > ignite-logs-config-source-20191128.zip, > ignite-logs-config-source-20191129.zip, my-config-zstan.xml, odbcsample, > odbcsample.allchar.rebind.cc, odbcsample.cc, profiling01.png, > profiling03.png, profling02.png, screenshot-1.png, > snapshot-1574845275597.nps, threaddump-1573207804944.tdump, > threaddump-1574845414243.tdump, values.yaml > > > Hi, in our test ignite performance with ODBC connection is too bad to proceed > with product integration. It is about ~200 TPS, each transaction with > select+update operation. > Please refer to attach sample program. It is just a simple test case. > Based on the profiling most of the time consumed by sql execution. Please > advice if the application did not do the right thing. > Thank you. > local ignite server, but the result same to remote container Ignite > deployment too. > cat /etc/apache-ignite/my-config.xml > > http://www.springframework.org/schema/beans; >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; >xsi:schemaLocation="http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd;> > class="org.apache.ignite.configuration.IgniteConfiguration"> > > class="org.apache.ignite.configuration.ClientConnectorConfiguration"/> > > > > > > class="org.apache.ignite.binary.BinaryBasicIdMapper"> > > > > > > > > g++ -I/usr/include -I./ignite/binary/include -I./ignite/common/include > -I./ignite/common/os/linux/include -I./ignite/common/os/win/include > -I./ignite/core/include -I./ignite/jni/include odbcsample.cc -o odbcsample > -lodbc -L./ignite-libs/libignite.so -L./ignite-libs/libignite-odbc.so -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12415) .NET: Thin client does not connect to old server nodes
Pavel Tupitsyn created IGNITE-12415:
---
Summary: .NET: Thin client does not connect to old server nodes
Key: IGNITE-12415
URL: https://issues.apache.org/jira/browse/IGNITE-12415
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.8
Exception when trying to connect .NET Thin Client from current master
(https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20191203) to the 2.7.6
server node:
{code}
Unhandled exception. Apache.Ignite.Core.Client.IgniteClientException: Client
handshake failed: 'Unsupported version.'. Client version: 1.6.0. Server
version: 1.2.0
at
Apache.Ignite.Core.Impl.Client.ClientSocket.Handshake(IgniteClientConfiguration
clientConfiguration, ClientProtocolVersion version)
at
Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration
clientConfiguration, EndPoint endPoint, String host, Nullable`1 version,
Action`1 topVerCallback)
at Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.Connect()
at
Apache.Ignite.Core.Impl.Client.ClientFailoverSocket..ctor(IgniteClientConfiguration
config, Marshaller marsh)
at
Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration
clientConfiguration)
at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration
clientConfiguration)
at ConsoleApp2.Program.Main(String[] args) in
/home/pavel/RiderProjects/ConsoleApp2/ConsoleApp2/Program.cs:line 14
[StatusCode=Fail]
{code}
This is caused by buggy version handling logic in Handshake method. Otherwise
we support any older protocol version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12188) Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly if there is more then one cache in cache group
[
https://issues.apache.org/jira/browse/IGNITE-12188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987649#comment-16987649
]
Amelchev Nikita commented on IGNITE-12188:
--
[~alex_pl], I have fixed the metric. Could you take a look, please?
> Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly
> if there is more then one cache in cache group
>
>
> Key: IGNITE-12188
> URL: https://issues.apache.org/jira/browse/IGNITE-12188
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Aleksey Plekhanov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-35, await
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Initial partitions counter is set to a total number of partitions for cache
> group but decremented each time partition processed for each cache.
> Reproducer:
> {code:java}
> @Test
> public void testIndexRebuildMetrics() throws Exception {
> IgniteEx ignite = startGrid(new IgniteConfiguration()
> .setConsistentId("ignite")
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)))
> .setCacheConfiguration(
> new CacheConfiguration Integer>("c1").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class),
> new CacheConfiguration Integer>("c2").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class)
> ));
> ignite.cluster().active(true);
> for (int i = 0; i < 10_000; i++)
> ignite.cache("c1").put(i, i);
> ignite.cluster().active(false);
> File dir = U.resolveWorkDirectory(U.defaultWorkDirectory(),
> DFLT_STORE_DIR, false);
> U.delete(new File(dir, "ignite/cacheGroup-grp/index.bin"));
> ignite.cluster().active(true);
> doSleep(1_000L);
>
> assertTrue(ignite.context().cache().cache("c1").context().group().metrics().getIndexBuildCountPartitionsLeft()
> >= 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-11905) [IEP-35] Monitoring Phase 2
[ https://issues.apache.org/jira/browse/IGNITE-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-11905. -- Resolution: Fixed > [IEP-35] Monitoring Phase 2 > -- > > Key: IGNITE-11905 > URL: https://issues.apache.org/jira/browse/IGNITE-11905 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Blocker > Labels: IEP-35, await, important > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Phase 2 should introduce: > Ability to collect lists of some internal object Ignite manage. > Examples of such objects: > * Caches > * Queries (including continuous queries) > * Services > * Compute tasks > * Distributed Data Structures > * etc... > 1. Fields for each list should be discussed in separate tickets > 2. Metric Exporters (optionally) can support list export. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12393) Striped thread pool queue system view
[
https://issues.apache.org/jira/browse/IGNITE-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987639#comment-16987639
]
Ignite TC Bot commented on IGNITE-12393:
{panel:title=Branch: [pull/7084/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4810150buildTypeId=IgniteTests24Java8_RunAll]
> Striped thread pool queue system view
> -
>
> Key: IGNITE-12393
> URL: https://issues.apache.org/jira/browse/IGNITE-12393
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When in the production environment exist some cluster performance issues
> usually it leads to the large striped executor queue size.
> The number of tasks in the queue can observe by
> {StripedExecutorMXBean#getTotalQueueSize} metric. In the case queue size
> becomes large it's useful to have the ability to know what tasks are waiting
> for execution in the thread pool.
> Especially, for dealing with failover scenarios.
> We should create a system views to expose information about striped executor
> services queue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
