[jira] [Commented] (IGNITE-15012) Adapting historical rebalance to segment release
[
https://issues.apache.org/jira/browse/IGNITE-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371821#comment-17371821
]
Ignite TC Bot commented on IGNITE-15012:
{panel:title=Branch: [pull/9206/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9206/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 4{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=6066793]]
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testReleaseDuringRebalanceIterator -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testImmediateReleaseSegment - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testNoReserveHistoryForPreloading -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testReleaseBeforeRebalanceIterator -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testReleaseBeforeReleaseHistoryForPreloading
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testReleaseSegmentAfterSearchAndReserveCheckpoints
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testReleaseBeforeReleaseHistoryForExchange
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
ReleaseSegmentOnHistoricalRebalance.testNoReserveSegment - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6066820buildTypeId=IgniteTests24Java8_RunAll]
> Adapting historical rebalance to segment release
>
>
> Key: IGNITE-15012
> URL: https://issues.apache.org/jira/browse/IGNITE-15012
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It is necessary to adapt the historical rebalance to the release of WAL
> segments after their reservation. Since IGNITE-14952 will be automatically
> released when the maximum is reached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15008) ignite.reentrantLock deadlock at thread shutdown
[ https://issues.apache.org/jira/browse/IGNITE-15008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371818#comment-17371818 ] Stanilovsky Evgeny commented on IGNITE-15008: - hi, plz append thread dumps ? > ignite.reentrantLock deadlock at thread shutdown > > > Key: IGNITE-15008 > URL: https://issues.apache.org/jira/browse/IGNITE-15008 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.10, 2.9.1 >Reporter: icode >Priority: Blocker > > I use `ignite.reentrantLock(lockName, true, true, true)` for single work, but > it deadlock at ExecutorService *shutdownNow*, `unlock` api will throw error > say this thead is interrupted, and can not close this lock. > Please remove interrupted thread check or unlock it at interrupt this thread. > Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Korol updated IGNITE-14569: Ignite Flags: (was: Docs Required,Release Notes Required) > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Assignee: Ilya Korol >Priority: Minor > Labels: newbie > Fix For: 2.11 > > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries: > [https://ignite.apache.org/docs/latest/monitoring-metrics/system-views]. > It needs a system views for data structures. In general, each data structure > system view must have the same fields as the method arguments that creates > the data structure. > For example system view for *latches* should have such fields: > name - name of the latch > initialCnt - count when latch was created (if this data is available) > cnt - current latch count > autoDel - does the latch automatically delete when its count reaches zero. > *Queue system view:* > name - name of the queue > capacity - capacity of the queue > size - current size of the queue > > *Set system view:* > name - name of the set > size - current size of the set > > *Atomics system view:* > name - name of the atomic > initVal - initial value of the atomic > currentVal - current value of the atomic > type - SEQUENCE | LONG | REFERENCE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371767#comment-17371767 ] Ilya Korol edited comment on IGNITE-14569 at 6/30/21, 1:57 AM: --- Hi, [~agidaspov] Since this ticket is a duplicate of IGNITE-14368 i assume that we can leave this one without release notes. was (Author: korol): Hi, Alexey. Since this ticket is a duplicate of IGNITE-14368 i assume that we can leave this one without release notes. > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Assignee: Ilya Korol >Priority: Minor > Labels: newbie > Fix For: 2.11 > > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries: > [https://ignite.apache.org/docs/latest/monitoring-metrics/system-views]. > It needs a system views for data structures. In general, each data structure > system view must have the same fields as the method arguments that creates > the data structure. > For example system view for *latches* should have such fields: > name - name of the latch > initialCnt - count when latch was created (if this data is available) > cnt - current latch count > autoDel - does the latch automatically delete when its count reaches zero. > *Queue system view:* > name - name of the queue > capacity - capacity of the queue > size - current size of the queue > > *Set system view:* > name - name of the set > size - current size of the set > > *Atomics system view:* > name - name of the atomic > initVal - initial value of the atomic > currentVal - current value of the atomic > type - SEQUENCE | LONG | REFERENCE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371767#comment-17371767 ] Ilya Korol commented on IGNITE-14569: - Hi, Alexey. Since this ticket is a duplicate of IGNITE-14368 i assume that we can leave this one without release notes. > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Assignee: Ilya Korol >Priority: Minor > Labels: newbie > Fix For: 2.11 > > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries: > [https://ignite.apache.org/docs/latest/monitoring-metrics/system-views]. > It needs a system views for data structures. In general, each data structure > system view must have the same fields as the method arguments that creates > the data structure. > For example system view for *latches* should have such fields: > name - name of the latch > initialCnt - count when latch was created (if this data is available) > cnt - current latch count > autoDel - does the latch automatically delete when its count reaches zero. > *Queue system view:* > name - name of the queue > capacity - capacity of the queue > size - current size of the queue > > *Set system view:* > name - name of the set > size - current size of the set > > *Atomics system view:* > name - name of the atomic > initVal - initial value of the atomic > currentVal - current value of the atomic > type - SEQUENCE | LONG | REFERENCE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-14335:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
Release Note: Added support of alter/drop/create user SQL commands for
security plugins.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from
> other managers intact, just skip these calls if the
> IgniteAuthenticationProcessor is not being used for security.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14257) Add copy constructor to ClientCacheConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-14257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14257: Ignite Flags: (was: Docs Required,Release Notes Required) > Add copy constructor to ClientCacheConfiguration > - > > Key: IGNITE-14257 > URL: https://issues.apache.org/jira/browse/IGNITE-14257 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > It's proposed to add copy constructor to ClientCacheConfiguration class. > This will make it possible to conveniently create a configuration based on > the provided template. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
[
https://issues.apache.org/jira/browse/IGNITE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-14376:
Ignite Flags: (was: Docs Required,Release Notes Required)
> JmxMetricExporter fails to export discovery metrics
> ---
>
> Key: IGNITE-14376
> URL: https://issues.apache.org/jira/browse/IGNITE-14376
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Error:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.lambda$getMBeanInfo$0(MetricRegistryMBean.java:105)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getMBeanInfo(MetricRegistryMBean.java:85)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getAttribute(MetricRegistryMBean.java:58)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy32.getMBeanInfo(Unknown Source)
> at
> org.apache.ignite.internal.metric.JmxExporterSpiTest.test(JmxExporterSpiTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2391)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(jmxSpi);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid();
> DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
> mBean.getMBeanInfo();
> }
> {code}
> The main reason: JMX exporter assumes that each metric must starts with the
> name of the registry it belongs to (see MetricRegistryMBean#getMBeanInfo),
> but discovery metrics do not obey this naming convection (see
> TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371686#comment-17371686
]
Alexey Gidaspov commented on IGNITE-12508:
--
Hello [~atri],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Rakov
>Assignee: Atri Sharma
>Priority: Major
> Labels: newbie
> Fix For: 2.11
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-12852: - Fix Version/s: (was: 2.11) 2.12 > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.12 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371681#comment-17371681 ] Alexey Gidaspov commented on IGNITE-13169: -- Hello [~sdanilov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 1h > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13029) Support Spring Data repositories initialization with Spring Boot auto-starter
[
https://issues.apache.org/jira/browse/IGNITE-13029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371683#comment-17371683
]
Alexey Gidaspov commented on IGNITE-13029:
--
Hello [~stalkxt],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Support Spring Data repositories initialization with Spring Boot auto-starter
> -
>
> Key: IGNITE-13029
> URL: https://issues.apache.org/jira/browse/IGNITE-13029
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Sergey Dorozhkin
>Priority: Major
> Labels: newbie
> Fix For: 2.11
>
>
> It's required to use {{@EnableIgniteRepositories}} annotation and follow this
> procedure to enable Ignite Spring Data repositories:
> https://apacheignite-mix.readme.io/docs/spring-data#spring-data-and-apache-ignite-configuration
> Support the Spring Data repositories enablement via the Spring Boot
> auto-starter if Spring Boot is used by a project:
> https://apacheignite-mix.readme.io/docs/spring-boot
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13689) Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371680#comment-17371680 ] Alexey Gidaspov commented on IGNITE-13689: -- Hello [~a-polyakov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Extend test coverage [IGNITE-11512] Add counter left partition for index > rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-13689 > URL: https://issues.apache.org/jira/browse/IGNITE-13689 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Labels: test > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > New test: > Partial rebuild > # Start cluster, load data with indexes > # Kill single node, create new index, start node. > # Make sure that index rebuild count is in range of total new index size and > 0 and decreasing > # Wait until rebuild finished, assert that no index errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13725) Add snapshot check command
[
https://issues.apache.org/jira/browse/IGNITE-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371679#comment-17371679
]
Alexey Gidaspov commented on IGNITE-13725:
--
Hello [~mmuzaf],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Add snapshot check command
> --
>
> Key: IGNITE-13725
> URL: https://issues.apache.org/jira/browse/IGNITE-13725
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.11
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> The user must be able to validate a created snapshot should be validated on
> its consistency the same way as the {{idle_verify}} procedure does.
> It is necessary to introduce a new {{SnapshotMetadata}} structure to save the
> additional snapshot meta information. The verify procedure must collect all
> snapshot metadata parts and check for its completeness and consistency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13767) Remove Python PHP and Node.js thin clients from main repository
[ https://issues.apache.org/jira/browse/IGNITE-13767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371678#comment-17371678 ] Alexey Gidaspov commented on IGNITE-13767: -- Hello [~isapego], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Remove Python PHP and Node.js thin clients from main repository > --- > > Key: IGNITE-13767 > URL: https://issues.apache.org/jira/browse/IGNITE-13767 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to remove the following directories, as we now have separate repos for > Python, Node.js and PHP thin clients: > modules/platforms/python > modules/platforms/nodejs > modules/platforms/php > > Also, need to check all the places in code where those directories are > referenced. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13792) Reconnecting clients trigger failure handler
[
https://issues.apache.org/jira/browse/IGNITE-13792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371677#comment-17371677
]
Alexey Gidaspov commented on IGNITE-13792:
--
Hello [~v.pyatkov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Reconnecting clients trigger failure handler
>
>
> Key: IGNITE-13792
> URL: https://issues.apache.org/jira/browse/IGNITE-13792
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9
>Reporter: Pavel Vinokurov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Attachments: UnstableClients.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> Dec 01, 2020 9:38:29 PM java.util.logging.LogManager$RootLogger log
> SEVERE: JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Affinity for topology version is not
> initialized [locNode=b50635ff-0324-431b-bc34-00a6cd36c9e3,
> grp=ignite-sys-cache, topVer=AffinityTopologyVersion [topVer=570,
> minorTopVer=0], head=AffinityTopologyVersion [topVer=569, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=551, minorTopVer=0],
> AffinityTopologyVersion [topVer=552, minorTopVer=0], AffinityTopologyVersion
> [topVer=553, minorTopVer=0], AffinityTopologyVersion [topVer=554,
> minorTopVer=0], AffinityTopologyVersion [topVer=555, minorTopVer=0],
> AffinityTopologyVersion [topVer=556, minorTopVer=0], AffinityTopologyVersion
> [topVer=557, minorTopVer=0], AffinityTopologyVersion [topVer=558,
> minorTopVer=0], AffinityTopologyVersion [topVer=559, minorTopVer=0],
> AffinityTopologyVersion [topVer=560, minorTopVer=0], AffinityTopologyVersion
> [topVer=561, minorTopVer=0], AffinityTopologyVersion [topVer=562,
> minorTopVer=0], AffinityTopologyVersion [topVer=563, minorTopVer=0],
> AffinityTopologyVersion [topVer=564, minorTopVer=0], AffinityTopologyVersion
> [topVer=565, minorTopVer=0], AffinityTopologyVersion [topVer=566,
> minorTopVer=0], AffinityTopologyVersion [topVer=567, minorTopVer=0],
> AffinityTopologyVersion [topVer=568, minorTopVer=0], AffinityTopologyVersion
> [topVer=569, minorTopVer=0]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13805) Add support for cache group restore from a snapshot on the same topology
[ https://issues.apache.org/jira/browse/IGNITE-13805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371676#comment-17371676 ] Alexey Gidaspov commented on IGNITE-13805: -- Hello [~xtern], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add support for cache group restore from a snapshot on the same topology > > > Key: IGNITE-13805 > URL: https://issues.apache.org/jira/browse/IGNITE-13805 > Project: Ignite > Issue Type: New Feature >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43, important > Fix For: 2.11 > > Time Spent: 12h 50m > Remaining Estimate: 0h > > Ignite 2.9 introduces a new feature to take [consistent cluster > snapshot|https://ignite.apache.org/docs/latest/persistence/snapshots]. > However, there is currently no way for the user to restore a separate cache > group from such a snapshot. > As a first step, we must provide the ability (CLI command and public API) to > restore the separate cache group(s) without considering the current partition > distribution and rely on rebalancing to achieve the ideal distribution. > This process consists of the following steps: > # Make sure that all partitions of the cache group are available in the > cluster and that there are no conflicts in the saved cache configurations. > # Make sure the target cache group does not exist (user must manually > destroy the cache before restoring).. > # Move the cache data files locally on each node with the cache data > snapshots. > # Merge the binary metadata from the snapshot on each node. > # Dynamically start the restored cache group. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13818) Add extended logging topology for node left/join a grid
[ https://issues.apache.org/jira/browse/IGNITE-13818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371675#comment-17371675 ] Alexey Gidaspov commented on IGNITE-13818: -- Hello [~makedonskaya], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add extended logging topology for node left/join a grid > --- > > Key: IGNITE-13818 > URL: https://issues.apache.org/jira/browse/IGNITE-13818 > Project: Ignite > Issue Type: Improvement >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > At start of the node write topology - the number of server and client nodes, > I would like to expand the list of nodes (information about each node: order, > id, host, ip), this will help in the case when the logs are only from one > node, and when there are logs from all nodes it will speed up the search for > coordinator or find the problem node id which was in the transaction -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13873) Milti-cell transaction changes may be not visible (during some time) after the Cellular switch [Sync-free switch]
[
https://issues.apache.org/jira/browse/IGNITE-13873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371672#comment-17371672
]
Alexey Gidaspov commented on IGNITE-13873:
--
Hello [~av],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Milti-cell transaction changes may be not visible (during some time) after
> the Cellular switch [Sync-free switch]
> -
>
> Key: IGNITE-13873
> URL: https://issues.apache.org/jira/browse/IGNITE-13873
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: iep-45
> Fix For: 2.11
>
> Attachments: master (as 2.9) vs improved (as dev) .png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Transactions over some cells may be recovered after the stale data read.
> For example:
> We have 2 cells, the first contains partitions for k1, second for k2.
> Tx with put(k1,v1) and put(k2,v2) started and prepared.
> Then node from the first cell, which is the primary for k1, failed.
> Currently, the second cell (with key2) may finish the cellular switch before
> tx recovered and stale data read is possible.
> Primaries from the {{tx.transactionNodes()}} should be taken into account
> instead of the current logic that awaits for all transactions located on
> nodes who are backups to the failed primary.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371670#comment-17371670
]
Alexey Gidaspov commented on IGNITE-13949:
--
Hello [~YAMolochkov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> --
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14134) Snapshot check command must cacluate primary and backup partition hashes
[ https://issues.apache.org/jira/browse/IGNITE-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371668#comment-17371668 ] Alexey Gidaspov commented on IGNITE-14134: -- Hello [~mmuzaf], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Snapshot check command must cacluate primary and backup partition hashes > > > Key: IGNITE-14134 > URL: https://issues.apache.org/jira/browse/IGNITE-14134 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 5.5h > Remaining Estimate: 0h > > The snapshot verify procedure must calculate primary and backup partition > hashes. > The procedure should read each K-V pairs from each partition and calculate a > resulted checksum. This collection of checksums must be compared between > primary and backup partition to ensue the same data stored in each partition > copy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14141) Remove unnecessary storage configuration from PageStore
[
https://issues.apache.org/jira/browse/IGNITE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371667#comment-17371667
]
Alexey Gidaspov commented on IGNITE-14141:
--
Hello [~mmuzaf],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Remove unnecessary storage configuration from PageStore
> ---
>
> Key: IGNITE-14141
> URL: https://issues.apache.org/jira/browse/IGNITE-14141
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DataStorageConfiguration}} is used only for getting the {{pageSize}} in
> the {{FilePageStore}} implementation and can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371664#comment-17371664
]
Alexey Gidaspov commented on IGNITE-14214:
--
Hello [~NSAmelchev],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14191) Add command to control.(sh|bin) to manage performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-14191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371665#comment-17371665
]
Alexey Gidaspov commented on IGNITE-14191:
--
Hello [~NSAmelchev],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Add command to control.(sh|bin) to manage performance statistics
>
>
> Key: IGNITE-14191
> URL: https://issues.apache.org/jira/browse/IGNITE-14191
> Project: Ignite
> Issue Type: New Feature
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add command to control.(sh|bin) to manage performance statistics:
> {noformat}
> --performance-statistics [start|stop|status]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14424) Cache group re-encryption does not start after cluster secondary activation.
[
https://issues.apache.org/jira/browse/IGNITE-14424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371666#comment-17371666
]
Pavel Pereslegin commented on IGNITE-14424:
---
[~agidaspov], I think it was added by mistake, removed it, thanks for pointing
this out.
> Cache group re-encryption does not start after cluster secondary activation.
>
>
> Key: IGNITE-14424
> URL: https://issues.apache.org/jira/browse/IGNITE-14424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Cache group re-encryption does not start after cluster secondary activation.
> Reproducer
> {code:java}
> @Test
> public void testDeactivation() throws Exception {
> pageScanRate = 2;
> checkpointFreq = 10;
> T2 nodes = startTestGrids(true);
> IgniteEx node0 = nodes.get1();
> IgniteEx node1 = nodes.get2();
> createEncryptedCache(node0, node1, cacheName(), null);
> loadData(100_000);
>
> node0.encryption().changeCacheGroupKey(Collections.singleton(cacheName())).get();
>
> assertTrue(isReencryptionInProgress(Collections.singleton(cacheName(;
> node0.cluster().state(ClusterState.INACTIVE);
>
> assertFalse(isReencryptionInProgress(Collections.singleton(cacheName(;
>
> node0.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
>
> node1.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
> node0.cluster().state(ClusterState.ACTIVE);
> checkGroupKey(CU.cacheId(cacheName()), INITIAL_KEY_ID + 1,
> MAX_AWAIT_MILLIS); // failing here
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14424) Cache group re-encryption does not start after cluster secondary activation.
[
https://issues.apache.org/jira/browse/IGNITE-14424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-14424:
--
Ignite Flags: (was: Release Notes Required)
> Cache group re-encryption does not start after cluster secondary activation.
>
>
> Key: IGNITE-14424
> URL: https://issues.apache.org/jira/browse/IGNITE-14424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Cache group re-encryption does not start after cluster secondary activation.
> Reproducer
> {code:java}
> @Test
> public void testDeactivation() throws Exception {
> pageScanRate = 2;
> checkpointFreq = 10;
> T2 nodes = startTestGrids(true);
> IgniteEx node0 = nodes.get1();
> IgniteEx node1 = nodes.get2();
> createEncryptedCache(node0, node1, cacheName(), null);
> loadData(100_000);
>
> node0.encryption().changeCacheGroupKey(Collections.singleton(cacheName())).get();
>
> assertTrue(isReencryptionInProgress(Collections.singleton(cacheName(;
> node0.cluster().state(ClusterState.INACTIVE);
>
> assertFalse(isReencryptionInProgress(Collections.singleton(cacheName(;
>
> node0.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
>
> node1.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
> node0.cluster().state(ClusterState.ACTIVE);
> checkGroupKey(CU.cacheId(cacheName()), INITIAL_KEY_ID + 1,
> MAX_AWAIT_MILLIS); // failing here
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14241) IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive broken
[
https://issues.apache.org/jira/browse/IGNITE-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371662#comment-17371662
]
Alexey Gidaspov commented on IGNITE-14241:
--
Hello [~nizhikov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive
> broken
> -
>
> Key: IGNITE-14241
> URL: https://issues.apache.org/jira/browse/IGNITE-14241
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After 2ed8e7c641f8b57986cd50dca55ff4e5026c9fc3
> {{IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive}}
> is broken.
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-67455213630528885=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14221) SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
[
https://issues.apache.org/jira/browse/IGNITE-14221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371663#comment-17371663
]
Alexey Gidaspov commented on IGNITE-14221:
--
Hello [~nizhikov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
>
>
> Key: IGNITE-14221
> URL: https://issues.apache.org/jira/browse/IGNITE-14221
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 7.5h
> Remaining Estimate: 0h
>
> Currently, SQL constants not hidden if
> {{IGNITE_TO_STRING_INCLUDE_SENSITIVE=false}}.
> This can lead to security incidents when some applications don't use SQL
> parameters and send constant in query body.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14248) Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock properly
[
https://issues.apache.org/jira/browse/IGNITE-14248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371661#comment-17371661
]
Alexey Gidaspov commented on IGNITE-14248:
--
Hello [~Vladimir Pligin],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock
> properly
> ---
>
> Key: IGNITE-14248
> URL: https://issues.apache.org/jira/browse/IGNITE-14248
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Vladimir Pligin
>Assignee: Vladimir Pligin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If an exception (or even Error) is thrown inside of the method then the node
> turns into some unrecoverable state. Here's an example.
> # an exchange is about to finish, it's time to invalidate partition
> reservations.
> # exchange thread delegates it to a thread in the management pool
> # management pool tries to allocate a new thread (maybe it's idle and
> therefore empty)
> # for example ulimit is reached, the error is
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> # It's being logged, no further action is taken
> # partitions are reserved forever
> Message:
>
> {code:java}
> 2021-02-25 05:52:03.242 [exchange-worker-#182] ERROR
> o.a.i.i.p.q.h.t.PartitionReservationManager - Unexpected exception on start
> reservations cleanup
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> at java.base/java.lang.Thread.start0(Native Method)
> at java.base/java.lang.Thread.start(Thread.java:803)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1343)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.runLocal(GridClosureProcessor.java:847)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.PartitionReservationManager.onDoneAfterTopologyUnlock(PartitionReservationManager.java:323)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2617)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1064)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3375)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3194)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> Code of PartitionReservationManager.onDoneAfterTopologyUnlock:
> {code:java}
> @Override public void onDoneAfterTopologyUnlock(final
> GridDhtPartitionsExchangeFuture fut) {
> try {
> // Must not do anything at the exchange thread. Dispatch to the
> management thread pool.
> ctx.closure().runLocal(() -> {
> AffinityTopologyVersion topVer =
> ctx.cache().context().exchange()
>
> .lastAffinityChangedTopologyVersion(fut.topologyVersion());
> reservations.forEach((key, r) -> {
> if (r != REPLICATED_RESERVABLE &&
> !F.eq(key.topologyVersion(), topVer)) {
> assert r instanceof GridDhtPartitionsReservation;
>((GridDhtPartitionsReservation)r).invalidate();
> }
> });
> },
> GridIoPolicy.MANAGEMENT_POOL);
> }
> catch (Throwable e) {
> log.error("Unexpected exception on start reservations cleanup",
> e);
> }
> }
> {code}
>
>
> My vision is that there are two basic approaches:
> * to kill the node (it's already non-functional at this point), seems to be
> a FH job.
> * try to recover somehow (to be honest it's not clear how
[jira] [Commented] (IGNITE-14255) Added the ability to rotate collecting performance statistics
[ https://issues.apache.org/jira/browse/IGNITE-14255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371659#comment-17371659 ] Alexey Gidaspov commented on IGNITE-14255: -- Hello [~RyzhovSV], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Added the ability to rotate collecting performance statistics > - > > Key: IGNITE-14255 > URL: https://issues.apache.org/jira/browse/IGNITE-14255 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Add the ability to rotate the performance statistics file using the > control.sh and JMX. > collection of performance statistics will continue to be written to the next > file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14257) Add copy constructor to ClientCacheConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-14257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371658#comment-17371658 ] Alexey Gidaspov commented on IGNITE-14257: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add copy constructor to ClientCacheConfiguration > - > > Key: IGNITE-14257 > URL: https://issues.apache.org/jira/browse/IGNITE-14257 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > It's proposed to add copy constructor to ClientCacheConfiguration class. > This will make it possible to conveniently create a configuration based on > the provided template. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14267) Cluster snapshot must support encrypted caches
[ https://issues.apache.org/jira/browse/IGNITE-14267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14267: - Fix Version/s: (was: 2.11) 2.12 > Cluster snapshot must support encrypted caches > -- > > Key: IGNITE-14267 > URL: https://issues.apache.org/jira/browse/IGNITE-14267 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > > Currently, the snapshot procedure doesn't support taking a cluster snapshot > for caches with enabled encryption. We should support such a feature, so the > user will be able to create and restore for such snapshots. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371656#comment-17371656
]
Alexey Gidaspov commented on IGNITE-14331:
--
Hello [~slava.koptilin],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371655#comment-17371655
]
Alexey Gidaspov commented on IGNITE-14335:
--
Hello [~PetrovMikhail],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from
> other managers intact, just skip these calls if the
> IgniteAuthenticationProcessor is not being used for security.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14368) System view for DataStructures
[ https://issues.apache.org/jira/browse/IGNITE-14368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371653#comment-17371653 ] Alexey Gidaspov commented on IGNITE-14368: -- Hello [~nizhikov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > System view for DataStructures > -- > > Key: IGNITE-14368 > URL: https://issues.apache.org/jira/browse/IGNITE-14368 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently, there is no way for the user to know what DataStructures exist in > Ignite. > We should provide a system view for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14377) Enchance log of node ping failure.
[ https://issues.apache.org/jira/browse/IGNITE-14377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371650#comment-17371650 ] Alexey Gidaspov commented on IGNITE-14377: -- Hello [~vladsz83], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Enchance log of node ping failure. > -- > > Key: IGNITE-14377 > URL: https://issues.apache.org/jira/browse/IGNITE-14377 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Log of unsuccessful ping during the joining is insufficient. No failure > reason is logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14378) Remove delay from node ping.
[ https://issues.apache.org/jira/browse/IGNITE-14378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371649#comment-17371649 ] Alexey Gidaspov commented on IGNITE-14378: -- Hello [~vladsz83], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Remove delay from node ping. > > > Key: IGNITE-14378 > URL: https://issues.apache.org/jira/browse/IGNITE-14378 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove U.sleep(200) from the node ping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14428) Formalize the names of the metrics included in the metric registry.
[ https://issues.apache.org/jira/browse/IGNITE-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14428: Release Note: IO discovery metric names were changed to start with the metric registry name. > Formalize the names of the metrics included in the metric registry. > > > Key: IGNITE-14428 > URL: https://issues.apache.org/jira/browse/IGNITE-14428 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 3.5h > Remaining Estimate: 0h > > It's needed to refactor metric names to obey the global rule - all of them > must start with name of the registry they belongs to. And add corresponding > assertion. > The purpose of this change is to make all metrics that belongs to one > MetricRegistry have the name that obeys mentioned above rule regardless how > they were registered. It helps to use a consistent approach to work with all > metrics. > The following metric names will be changed to obey this rule: > JoinedNodes -> io.discovery.JoinedNodes > LeftNodes -> io.discovery.LeftNodes > FailedNodes -> io.discovery.FailedNodes > PendingMessagesRegistered -> io.discovery.PendingMessagesRegistered > CommunicationErrors -> io.discovery.CommunicationErrors > CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
[
https://issues.apache.org/jira/browse/IGNITE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371651#comment-17371651
]
Alexey Gidaspov commented on IGNITE-14376:
--
Hello [~PetrovMikhail],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> JmxMetricExporter fails to export discovery metrics
> ---
>
> Key: IGNITE-14376
> URL: https://issues.apache.org/jira/browse/IGNITE-14376
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Error:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.lambda$getMBeanInfo$0(MetricRegistryMBean.java:105)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getMBeanInfo(MetricRegistryMBean.java:85)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getAttribute(MetricRegistryMBean.java:58)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy32.getMBeanInfo(Unknown Source)
> at
> org.apache.ignite.internal.metric.JmxExporterSpiTest.test(JmxExporterSpiTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2391)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(jmxSpi);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid();
> DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
> mBean.getMBeanInfo();
> }
> {code}
> The main reason: JMX exporter assumes that each metric must starts with the
> name of the registry it belongs to (see MetricRegistryMBean#getMBeanInfo),
> but discovery metrics do not obey this naming convection (see
> TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14385) Add checkpoint information to the performance statistics.
[ https://issues.apache.org/jira/browse/IGNITE-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371648#comment-17371648 ] Alexey Gidaspov commented on IGNITE-14385: -- Hello [~RyzhovSV], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add checkpoint information to the performance statistics. > - > > Key: IGNITE-14385 > URL: https://issues.apache.org/jira/browse/IGNITE-14385 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add start/end time and other parameters of checkpoint to performance > statistics. > Add information about throttling if necessary -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
[
https://issues.apache.org/jira/browse/IGNITE-14394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371647#comment-17371647
]
Alexey Gidaspov commented on IGNITE-14394:
--
Hello [~slava.koptilin],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Baseline auto-adjustment does not happen when 2+ nodes join the cluster
> ---
>
> Key: IGNITE-14394
> URL: https://issues.apache.org/jira/browse/IGNITE-14394
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the case of baseline topology autoadjustment is enabled and a few server
> nodes join the cluster the autoadjustment may not be triggered.
> Steps to reproduce:
> 1. start ignite cluster and enable baseline autoadjustment
> 2. start 2+ server nodes (in order to reproduce the issue, the corresponding
> exchange should be merged)
> 3. wait for baseline autoadjustment
> *RESOLUTION*
> The root cause of the issue relates to merging exchanges. Let's consider the
> following scenario:
> 1. 2 new nodes join the cluster
> 2. the first step triggers a call
> BaselineTopologyUpdater#triggerBaselineUpdate twice and creates the following
> baseline data objects:
> data1 - target topology version - X
> data2 - target topology version - X+1. This data object invalidates the
> previous one (data1)
> 3. in the case the exchanges are merged and the first data (data1)
> binds/listens to real {{GridDhtPartitionsExchangeFuture}} instead of
> affinityReadyFuture, see
> {{GridCachePartitionExchangeManager#affinityReadyFuture}} (data2 listens to
> affinityReadyFuture(X+1)), the implementation schedules data2 in the first
> place, and after that, it replaces data2 with data1 which is already
> invalidated at this point.
> The fix is quite obvious - we should not schedule baseline data instances
> that are related to "invalidated" target topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14658) [IEP-35] SSL metrics
[ https://issues.apache.org/jira/browse/IGNITE-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14658: Release Note: Added SSL connection metrics. > [IEP-35] SSL metrics > > > Key: IGNITE-14658 > URL: https://issues.apache.org/jira/browse/IGNITE-14658 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The following SSL metrics required: > * Count of SSL sessions. > * Count of rejected SSL sessions. > * Handshake time metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14424) Cache group re-encryption does not start after cluster secondary activation.
[
https://issues.apache.org/jira/browse/IGNITE-14424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371646#comment-17371646
]
Alexey Gidaspov commented on IGNITE-14424:
--
Hello [~xtern],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Cache group re-encryption does not start after cluster secondary activation.
>
>
> Key: IGNITE-14424
> URL: https://issues.apache.org/jira/browse/IGNITE-14424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Cache group re-encryption does not start after cluster secondary activation.
> Reproducer
> {code:java}
> @Test
> public void testDeactivation() throws Exception {
> pageScanRate = 2;
> checkpointFreq = 10;
> T2 nodes = startTestGrids(true);
> IgniteEx node0 = nodes.get1();
> IgniteEx node1 = nodes.get2();
> createEncryptedCache(node0, node1, cacheName(), null);
> loadData(100_000);
>
> node0.encryption().changeCacheGroupKey(Collections.singleton(cacheName())).get();
>
> assertTrue(isReencryptionInProgress(Collections.singleton(cacheName(;
> node0.cluster().state(ClusterState.INACTIVE);
>
> assertFalse(isReencryptionInProgress(Collections.singleton(cacheName(;
>
> node0.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
>
> node1.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
> node0.cluster().state(ClusterState.ACTIVE);
> checkGroupKey(CU.cacheId(cacheName()), INITIAL_KEY_ID + 1,
> MAX_AWAIT_MILLIS); // failing here
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14428) Formalize the names of the metrics included in the metric registry.
[ https://issues.apache.org/jira/browse/IGNITE-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371644#comment-17371644 ] Alexey Gidaspov commented on IGNITE-14428: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Formalize the names of the metrics included in the metric registry. > > > Key: IGNITE-14428 > URL: https://issues.apache.org/jira/browse/IGNITE-14428 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 3.5h > Remaining Estimate: 0h > > It's needed to refactor metric names to obey the global rule - all of them > must start with name of the registry they belongs to. And add corresponding > assertion. > The purpose of this change is to make all metrics that belongs to one > MetricRegistry have the name that obeys mentioned above rule regardless how > they were registered. It helps to use a consistent approach to work with all > metrics. > The following metric names will be changed to obey this rule: > JoinedNodes -> io.discovery.JoinedNodes > LeftNodes -> io.discovery.LeftNodes > FailedNodes -> io.discovery.FailedNodes > PendingMessagesRegistered -> io.discovery.PendingMessagesRegistered > CommunicationErrors -> io.discovery.CommunicationErrors > CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14461) Track down those who initiated a query
[
https://issues.apache.org/jira/browse/IGNITE-14461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371642#comment-17371642
]
Alexey Gidaspov commented on IGNITE-14461:
--
Hello [~tledkov-gridgain],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Track down those who initiated a query
> --
>
> Key: IGNITE-14461
> URL: https://issues.apache.org/jira/browse/IGNITE-14461
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We need to know and track who initiated a query. It could be useful for an IT
> guy to be able to find an application and ask the developers to change the
> code. It could be as part of {{LOCAL_SQL_RUNNING_QUERIES}} system view or may
> be better to have separate view which could be joined with running queries
> view.
> For first glance it should be :
> # ip, port, host name, user for thin clients.
> # for thick client - nodeId, clientId, ip, host name,
> # task name for compute
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14448) Failure to connect to node leads to hanging connection future if paired connections are used
[
https://issues.apache.org/jira/browse/IGNITE-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371643#comment-17371643
]
Alexey Gidaspov commented on IGNITE-14448:
--
Hello [~sdanilov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Failure to connect to node leads to hanging connection future if paired
> connections are used
>
>
> Key: IGNITE-14448
> URL: https://issues.apache.org/jira/browse/IGNITE-14448
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.10
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> if ((CommunicationSpi)spi instanceof TcpCommunicationSpi)
> getTcpCommunicationSpi().setConnectionRequestor(invConnHandler);
>if (connRequestor != null) {
> ...
>if (isPairedConnection(node, tcpCommSpi))
>throw new IgniteSpiException("Inverse connection protocol
> doesn't support paired connections");{code}
> Turns out this exception is not handled property and connection future is
> never done. Then, striped pool threads wait forever on reserveClient() and
> cluster grinds to halt.This happens in versions which have
> communication-via-discovery and when usePairedConnections=true.
> {code:java}
> [12:06:18,110][SEVERE][sys-stripe-0-#1][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=54ddcf8b-3e41-4efe-bb9d-8a0369e7b893, consistentId=54ddcf8b-3e4
> 1-4efe-bb9d-8a0369e7b893, addrs=ArrayList [127.0.0.1, 172.22.229.21],
> sockAddrs=HashSet [/127.0.0.1:0,
> ip-172-22-229-21.ec2.internal/172.22.229.21:0], discPort=0, order=47,
> intOrder=47, lastExchangeTime=1603983940522, loc=false,
> ver=8.7.25#20200910-sha1:b580d9fd, isClient=true], msg=GridIoMessage [plc=2,
> topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=f
> alse, msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=24,
> val=23576, hasValBytes=true], val=com.dream11.ignite.model.GetRoundSummaryRes
> [idHash=69226443, hash=580815760,roundId=23576, dataSource=MYSQL,
> sparkJobStatus=COMPLETED], prevVal=null,
> super=GridDhtAtomicAbstractUpdateRequest [onRes=false, nearNodeId=null,
> nearFutId=0, flags=near]], connIdx=-1]]
> class org.apache.ignite.spi.IgniteSpiException: Inverse connection protocol
> doesn't support paired connections
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$TcpCommunicationInverseConnectionHandler.request(GridIoManager.java:3564)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.handleUnreachableNodeException(ConnectionClientPool.java:365)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.reserveClient(ConnectionClientPool.java:256)
>
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1132)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1083)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1814)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1930)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.sendDhtRequests(GridDhtAtomicAbstractUpdateFuture
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14471) JDBCv2: query cursors leak when node to execute queries is specified
[ https://issues.apache.org/jira/browse/IGNITE-14471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371641#comment-17371641 ] Alexey Gidaspov commented on IGNITE-14471: -- Hello [~tledkov-gridgain], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > JDBCv2: query cursors leak when node to execute queries is specified > > > Key: IGNITE-14471 > URL: https://issues.apache.org/jira/browse/IGNITE-14471 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 40m > Remaining Estimate: 0h > > Query cursors leak when node to execute queries is specified. > In this case the query tasks are executed on the remote node instead of > client node launched by the JDBC v2 client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371640#comment-17371640 ] Alexey Gidaspov commented on IGNITE-14569: -- Hello [~Korol], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Assignee: Ilya Korol >Priority: Minor > Labels: newbie > Fix For: 2.11 > > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries: > [https://ignite.apache.org/docs/latest/monitoring-metrics/system-views]. > It needs a system views for data structures. In general, each data structure > system view must have the same fields as the method arguments that creates > the data structure. > For example system view for *latches* should have such fields: > name - name of the latch > initialCnt - count when latch was created (if this data is available) > cnt - current latch count > autoDel - does the latch automatically delete when its count reaches zero. > *Queue system view:* > name - name of the queue > capacity - capacity of the queue > size - current size of the queue > > *Set system view:* > name - name of the set > size - current size of the set > > *Atomics system view:* > name - name of the atomic > initVal - initial value of the atomic > currentVal - current value of the atomic > type - SEQUENCE | LONG | REFERENCE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14572) Include metastorage into snapshot
[ https://issues.apache.org/jira/browse/IGNITE-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371639#comment-17371639 ] Alexey Gidaspov commented on IGNITE-14572: -- Hello [~mmuzaf], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Include metastorage into snapshot > - > > Key: IGNITE-14572 > URL: https://issues.apache.org/jira/browse/IGNITE-14572 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 10h 40m > Remaining Estimate: 0h > > Currently, only cache and cache groups with CacheType.USER included into a > snapshot. We must also include into snapshot the metastorage data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14658) [IEP-35] SSL metrics
[ https://issues.apache.org/jira/browse/IGNITE-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371637#comment-17371637 ] Alexey Gidaspov commented on IGNITE-14658: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > [IEP-35] SSL metrics > > > Key: IGNITE-14658 > URL: https://issues.apache.org/jira/browse/IGNITE-14658 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The following SSL metrics required: > * Count of SSL sessions. > * Count of rejected SSL sessions. > * Handshake time metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371638#comment-17371638 ] Alexey Gidaspov commented on IGNITE-14575: -- Hello [~sdanilov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 1h > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15027) Node fails to start with IndexOutOfBoundsException if metastorage nodes do not exist
Valentin Kulichenko created IGNITE-15027:
Summary: Node fails to start with IndexOutOfBoundsException if
metastorage nodes do not exist
Key: IGNITE-15027
URL: https://issues.apache.org/jira/browse/IGNITE-15027
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha2
Reporter: Valentin Kulichenko
Fix For: 3.0.0-alpha3
If a node is started with this config...
{code}
{
"node": {
"metastorageNodes": [
"node-0", "node-1", "node-2"
]
},
"network": {
"port": 3344,
"netClusterNodes": [
"localhost:3344"
]
}
}
{code}
but with a name that is not present in {{metastorageNodes}}...
{code}
IgnitionManager.start("other-name",
Files.readString(Path.of("config/ignite-config.json")))
{code}
it fails with {{IndexOutOfBoundsException}}:
{noformat}
INFO: Started replication server [node=ClusterNode
[id=4640f6cd-f2c2-4fcf-9261-560b55190894, name=example-node,
host=192.168.2.190, port=3344]]
Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of
bounds for length 0
at
java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at
java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:373)
at java.base/java.util.ArrayList.get(ArrayList.java:426)
at org.apache.ignite.internal.raft.Loza.startRaftGroup(Loza.java:76)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.(MetaStorageManager.java:133)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:145)
at org.apache.ignite.app.IgnitionManager.start(IgnitionManager.java:45)
at
org.apache.ignite.example.table.TableExample.main(TableExample.java:29)
{noformat}
Should instead fail with a meaningful error message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14571) Add RELEASE.md file to project.
[ https://issues.apache.org/jira/browse/IGNITE-14571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko resolved IGNITE-14571. -- Resolution: Fixed > Add RELEASE.md file to project. > --- > > Key: IGNITE-14571 > URL: https://issues.apache.org/jira/browse/IGNITE-14571 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Valentin Kulichenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Let's describe release process and all action need to be taken for releasing > Ignite into RELEASE.md file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
[
https://issues.apache.org/jira/browse/IGNITE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371533#comment-17371533
]
Mikhail Petrov commented on IGNITE-14376:
-
[~dpavlov] This issue is fixed by
https://issues.apache.org/jira/browse/IGNITE-14428 as mentioned in the ticket.
> JmxMetricExporter fails to export discovery metrics
> ---
>
> Key: IGNITE-14376
> URL: https://issues.apache.org/jira/browse/IGNITE-14376
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Error:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.lambda$getMBeanInfo$0(MetricRegistryMBean.java:105)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getMBeanInfo(MetricRegistryMBean.java:85)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getAttribute(MetricRegistryMBean.java:58)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy32.getMBeanInfo(Unknown Source)
> at
> org.apache.ignite.internal.metric.JmxExporterSpiTest.test(JmxExporterSpiTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2391)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(jmxSpi);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid();
> DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
> mBean.getMBeanInfo();
> }
> {code}
> The main reason: JMX exporter assumes that each metric must starts with the
> name of the registry it belongs to (see MetricRegistryMBean#getMBeanInfo),
> but discovery metrics do not obey this naming convection (see
> TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
[
https://issues.apache.org/jira/browse/IGNITE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371531#comment-17371531
]
Dmitry Pavlov edited comment on IGNITE-14376 at 6/29/21, 5:10 PM:
--
Folks, I can't find any commit at master for that issue fix.
How the PR was closed? Who committed code fix to master?
I suggest using apply_pull_request.sh or GitHub integration. Both ways will
provide reference from the PR to master commit automattically. If none of ways
were used here, I suggest adding a reference to master commit manually to the
ticked and to PR
was (Author: dpavlov):
Folks, I can't find any commit at master for that fix.
How the PR was closed? Who committed that fix?
I suggest using apply_pull_request.sh or GitHub integration. Both ways will
provide reference from the PR to master commit. If none of ways were used here,
I suggest adding a reference to master commit manually to the ticked and to PR
> JmxMetricExporter fails to export discovery metrics
> ---
>
> Key: IGNITE-14376
> URL: https://issues.apache.org/jira/browse/IGNITE-14376
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Error:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.lambda$getMBeanInfo$0(MetricRegistryMBean.java:105)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getMBeanInfo(MetricRegistryMBean.java:85)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getAttribute(MetricRegistryMBean.java:58)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy32.getMBeanInfo(Unknown Source)
> at
> org.apache.ignite.internal.metric.JmxExporterSpiTest.test(JmxExporterSpiTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2391)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(jmxSpi);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid();
> DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
> mBean.getMBeanInfo();
> }
> {code}
> The main reason: JMX exporter assumes that each metric must starts with the
> name of the registry it belongs to (see MetricRegistryMBean#getMBeanInfo),
> but discovery metrics do not obey this naming convection (see
> TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
[
https://issues.apache.org/jira/browse/IGNITE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371531#comment-17371531
]
Dmitry Pavlov commented on IGNITE-14376:
Folks, I can't find any commit at master for that fix.
How the PR was closed? Who committed that fix?
I suggest using apply_pull_request.sh or GitHub integration. Both ways will
provide reference from the PR to master commit. If none of ways were used here,
I suggest adding a reference to master commit manually to the ticked and to PR
> JmxMetricExporter fails to export discovery metrics
> ---
>
> Key: IGNITE-14376
> URL: https://issues.apache.org/jira/browse/IGNITE-14376
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Error:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.lambda$getMBeanInfo$0(MetricRegistryMBean.java:105)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getMBeanInfo(MetricRegistryMBean.java:85)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getAttribute(MetricRegistryMBean.java:58)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy32.getMBeanInfo(Unknown Source)
> at
> org.apache.ignite.internal.metric.JmxExporterSpiTest.test(JmxExporterSpiTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2391)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(jmxSpi);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid();
> DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
> mBean.getMBeanInfo();
> }
> {code}
> The main reason: JMX exporter assumes that each metric must starts with the
> name of the registry it belongs to (see MetricRegistryMBean#getMBeanInfo),
> but discovery metrics do not obey this naming convection (see
> TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14594) Calcite integration. UnionPlannerTest is not included to any test suite
[ https://issues.apache.org/jira/browse/IGNITE-14594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-14594: - Assignee: Pavel Pereslegin > Calcite integration. UnionPlannerTest is not included to any test suite > --- > > Key: IGNITE-14594 > URL: https://issues.apache.org/jira/browse/IGNITE-14594 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Pavel Pereslegin >Priority: Minor > Labels: calcite2-required, calcite3-required > > UnionPlannerTest should be included to PlannerTestSuite. > Also, some plan checks should be added to the test, currently it only prints > plan to the output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371337#comment-17371337
]
Andrey Mashenkov edited comment on IGNITE-14591 at 6/29/21, 5:05 PM:
-
[~vveider], would you please to add the Javadoc check task to the TC
was (Author: amashenkov):
[~vveider], would you please add the Javadoc check task to the TC
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15007) Add SystemView for baseline attributes stored in metastorage
[ https://issues.apache.org/jira/browse/IGNITE-15007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-15007: - Fix Version/s: 2.12 > Add SystemView for baseline attributes stored in metastorage > > > Key: IGNITE-15007 > URL: https://issues.apache.org/jira/browse/IGNITE-15007 > Project: Ignite > Issue Type: New Feature >Reporter: Ilya Shishkov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.12 > > Time Spent: 50m > Remaining Estimate: 0h > > The BaselineTopology entry in the Metastorage SystemView [1] does not show a > baseline node attributes. We could add additional system view for the stored > attributes of baseline nodes. > 1. > https://ignite.apache.org/docs/2.10.0/monitoring-metrics/system-views#metastorage -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14722) Document the ability to automatically restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-14722: - Component/s: documentation > Document the ability to automatically restore a cache group from the snapshot. > -- > > Key: IGNITE-14722 > URL: https://issues.apache.org/jira/browse/IGNITE-14722 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Document the ability to automatically restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14722) Document the ability to automatically restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371502#comment-17371502 ] Maxim Muzafarov commented on IGNITE-14722: -- [~xtern] Thank you for the patch. Merged to the master branch and cherry-picked to 2.11 Thank you all for the review. > Document the ability to automatically restore a cache group from the snapshot. > -- > > Key: IGNITE-14722 > URL: https://issues.apache.org/jira/browse/IGNITE-14722 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Document the ability to automatically restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14722) Document the ability to automatically restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-14722: - Fix Version/s: (was: 2.12) 2.11 > Document the ability to automatically restore a cache group from the snapshot. > -- > > Key: IGNITE-14722 > URL: https://issues.apache.org/jira/browse/IGNITE-14722 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Document the ability to automatically restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14801) Add tests for commands to manage metadata
[ https://issues.apache.org/jira/browse/IGNITE-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14801: - Ignite Flags: (was: Docs Required,Release Notes Required) > Add tests for commands to manage metadata > - > > Key: IGNITE-14801 > URL: https://issues.apache.org/jira/browse/IGNITE-14801 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Add tests for commands to manage metadata (see IGNITE-13154). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14722) Document the ability to automatically restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371460#comment-17371460 ] Pavel Pereslegin commented on IGNITE-14722: --- [~mmuzaf], the patch is ready to be merged. > Document the ability to automatically restore a cache group from the snapshot. > -- > > Key: IGNITE-14722 > URL: https://issues.apache.org/jira/browse/IGNITE-14722 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Document the ability to automatically restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15013) Design the transaction protocol for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15013: --- Description: As a result of this task, the transactional protocol design must be proposed. It's ok to have a protocol design to be in some intermediate state, so, not all desired features can be available. was: This is a top level issue for implementing tx support in Ignite 3 As a result of this task, the transactional protocol design must be proposed and a prototype implementation like isolated tx subsystem should be merged to the master. It's ok to have a protocol design to be in some intermediate state, so, not all desired features can be available. > Design the transaction protocol for Ignite 3 > > > Key: IGNITE-15013 > URL: https://issues.apache.org/jira/browse/IGNITE-15013 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 20m > Remaining Estimate: 0h > > As a result of this task, the transactional protocol design must be proposed. > It's ok to have a protocol design to be in some intermediate state, so, not > all desired features can be available. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15013) Design the transaction protocol for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15013: --- Summary: Design the transaction protocol for Ignite 3 (was: Design and prototype the transaction protocol for Ignite 3) > Design the transaction protocol for Ignite 3 > > > Key: IGNITE-15013 > URL: https://issues.apache.org/jira/browse/IGNITE-15013 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 20m > Remaining Estimate: 0h > > This is a top level issue for implementing tx support in Ignite 3 > As a result of this task, the transactional protocol design must be proposed > and a prototype implementation like isolated tx subsystem should be merged to > the master. > It's ok to have a protocol design to be in some intermediate state, so, not > all desired features can be available. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14722) Document the ability to automatically restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371448#comment-17371448 ] Pavel Pereslegin commented on IGNITE-14722: --- [~igusev], thanks for the review! > Document the ability to automatically restore a cache group from the snapshot. > -- > > Key: IGNITE-14722 > URL: https://issues.apache.org/jira/browse/IGNITE-14722 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Document the ability to automatically restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14864) Schema update. Merge multiple converters stages.
[ https://issues.apache.org/jira/browse/IGNITE-14864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-14864: - Assignee: Andrey Mashenkov > Schema update. Merge multiple converters stages. > > > Key: IGNITE-14864 > URL: https://issues.apache.org/jira/browse/IGNITE-14864 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > > Assumed schema was updated a number of times and there are n >1 converters to > apply. > Let's chain converters to apply all at once rather then one-by-one having a > row of intermediate version in between. > Also, opposite changes like "adding column A" then "remove column A" or > "Changing column default" then "remove column A" can be effectively omitted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14722) Document the ability to automatically restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371431#comment-17371431 ] Igor Gusev commented on IGNITE-14722: - Looks goog. I would rather get rid of "In a nutshell", but its not a blocking issue. > Document the ability to automatically restore a cache group from the snapshot. > -- > > Key: IGNITE-14722 > URL: https://issues.apache.org/jira/browse/IGNITE-14722 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > Time Spent: 3h > Remaining Estimate: 0h > > Document the ability to automatically restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14815) Metrics for thin clients
[ https://issues.apache.org/jira/browse/IGNITE-14815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371417#comment-17371417 ] Pavel Tupitsyn commented on IGNITE-14815: - [~isapego] looks good to me in general, please see a few minor comments on GitHub > Metrics for thin clients > > > Key: IGNITE-14815 > URL: https://issues.apache.org/jira/browse/IGNITE-14815 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > At least following metrics are required: > 1. Add "thin clients currently connected" metric. Client comes, +1. Client > leaves, -1. > 2. Add "total thin clients connected" aggregated metric. Just a counter of > thin client connected events, similar to CachePuts in cache metrics. > This is as per > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener#onConnected > / > org.apache.ignite.internal.processors.odbc.ClientListenerNioListener#onDisconnected -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15008) ignite.reentrantLock deadlock at thread shutdown
[ https://issues.apache.org/jira/browse/IGNITE-15008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] icode updated IGNITE-15008: --- Ignite Flags: (was: Docs Required,Release Notes Required) > ignite.reentrantLock deadlock at thread shutdown > > > Key: IGNITE-15008 > URL: https://issues.apache.org/jira/browse/IGNITE-15008 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.10, 2.9.1 >Reporter: icode >Priority: Blocker > > I use `ignite.reentrantLock(lockName, true, true, true)` for single work, but > it deadlock at ExecutorService *shutdownNow*, `unlock` api will throw error > say this thead is interrupted, and can not close this lock. > Please remove interrupted thread check or unlock it at interrupt this thread. > Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15008) ignite.reentrantLock deadlock at thread shutdown
[ https://issues.apache.org/jira/browse/IGNITE-15008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] icode updated IGNITE-15008: --- Component/s: cache Affects Version/s: 2.10 > ignite.reentrantLock deadlock at thread shutdown > > > Key: IGNITE-15008 > URL: https://issues.apache.org/jira/browse/IGNITE-15008 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.10, 2.9.1 >Reporter: icode >Priority: Blocker > > I use `ignite.reentrantLock(lockName, true, true, true)` for single work, but > it deadlock at ExecutorService *shutdownNow*, `unlock` api will throw error > say this thead is interrupted, and can not close this lock. > Please remove interrupted thread check or unlock it at interrupt this thread. > Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14952) Releasing WAL segments when reaching DataStorageConfiguration#maxWalArchiveSize
[ https://issues.apache.org/jira/browse/IGNITE-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-14952: - Release Note: Automatic release of WAL segments when reaching the DataStorageConfiguration#maxWalArchiveSize. > Releasing WAL segments when reaching > DataStorageConfiguration#maxWalArchiveSize > --- > > Key: IGNITE-14952 > URL: https://issues.apache.org/jira/browse/IGNITE-14952 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > When the *DataStorageConfiguration#maxWalArchiveSize* is reached, release the > WAL segments to avoid overflowing the WAL archive. > Do not allow segment reservations to a > *DataStorageConfiguration#minWalArchiveSize*. > Subtask from > [discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Exceeding-the-DataStorageConfiguration-getMaxWalArchiveSize-due-to-historical-rebalance-td52546.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14815) Metrics for thin clients
[
https://issues.apache.org/jira/browse/IGNITE-14815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371393#comment-17371393
]
Ignite TC Bot commented on IGNITE-14815:
{panel:title=Branch: [pull/9182/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6065572]]
{panel}
{panel:title=Branch: [pull/9182/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6065186]]
* {color:#013220}IgniteBasicTestSuite:
ClientListenerMetricsTest.testClientListenerMetricsReject - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
ClientListenerMetricsTest.testClientListenerMetricsRejectGeneral - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
ClientListenerMetricsTest.testClientListenerMetricsAccept - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6065247buildTypeId=IgniteTests24Java8_RunAll]
> Metrics for thin clients
>
>
> Key: IGNITE-14815
> URL: https://issues.apache.org/jira/browse/IGNITE-14815
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At least following metrics are required:
> 1. Add "thin clients currently connected" metric. Client comes, +1. Client
> leaves, -1.
> 2. Add "total thin clients connected" aggregated metric. Just a counter of
> thin client connected events, similar to CachePuts in cache metrics.
> This is as per
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener#onConnected
> /
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener#onDisconnected
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14901) Document SSL metrics.
[ https://issues.apache.org/jira/browse/IGNITE-14901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371390#comment-17371390 ] Nikita Safonov commented on IGNITE-14901: - [~PetrovMikhail] I've left some comments. > Document SSL metrics. > - > > Key: IGNITE-14901 > URL: https://issues.apache.org/jira/browse/IGNITE-14901 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > It is needed to document SSL metrics introduced by > https://issues.apache.org/jira/browse/IGNITE-14658 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15026) Remove storage of physical page ids in a DurableBackgroundCleanupIndexTreeTask
Kirill Tkalenko created IGNITE-15026:
Summary: Remove storage of physical page ids in a
DurableBackgroundCleanupIndexTreeTask
Key: IGNITE-15026
URL: https://issues.apache.org/jira/browse/IGNITE-15026
Project: Ignite
Issue Type: Improvement
Components: persistence, sql
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
Fix For: 2.12
DurableBackgroundCleanupIndexTreeTask does one bad thing - it stores page id
into a logical metastorage record. BUT, there are no guarantees that this page
exists in current checkpoint state on the storage device.
Imagine that someone waits for checkpoint, then before the next checkpoint they
create SQL index, then drop it and end the process with "kill -9". There's a
chance that something like this could happen by accident.
Then page id in DurableBackgroundCleanupIndexTreeTask will either point to a
nonexistent page (trace 1) or to the existing page that has nothing to do with
meta tree (trace 2).
{noformat}
java.lang.ArrayIndexOutOfBoundsException: 4937
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.getStore(FilePageStoreManager.java:1085)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageReadWriteManagerImpl.read(PageReadWriteManagerImpl.java:65)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:510)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:871)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:697)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:686)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:185)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:6061)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.destroyDownPages(BPlusTree.java:2607)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.destroy(BPlusTree.java:2555)
at
org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask.execute(DurableBackgroundCleanupIndexTreeTask.java:231)
at
org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor$1.body(DurableBackgroundTasksProcessor.java:121)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{noformat}
{noformat}
4d11-9351-08a40b89548c
java.lang.IllegalStateException: Failed to get page IO instance (page content
is corrupted)
at
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:84)
at
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:96)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getMetaInfo(H2Tree.java:508)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.(H2Tree.java:240)
at
org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask$H2TreeToDestroy.(DurableBackgroundCleanupIndexTreeTask.java:359)
at
org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask.execute(DurableBackgroundCleanupIndexTreeTask.java:208)
at
org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor$1.body(DurableBackgroundTasksProcessor.java:121)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14828) No fallback to full rebalance after exception on historical
[
https://issues.apache.org/jira/browse/IGNITE-14828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371377#comment-17371377
]
Mirza Aliev commented on IGNITE-14828:
--
Hello [~agidaspov],
I've added release notes, thanks for noticing that.
> No fallback to full rebalance after exception on historical
> ---
>
> Key: IGNITE-14828
> URL: https://issues.apache.org/jira/browse/IGNITE-14828
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have noticed that in some cases when we handle demand message in
> {{GridDhtPartitionSupplier.java}} it is possible for some reasons that
> {code:java}
> iter = grp.offheap().rebalanceIterator(demandMsg.partitions(),
> demandMsg.topologyVersion());
> {code}
> throw an exception. In that case, rebalance should switch to full, but the
> code has a bug and {{remainingParts}} has been filed after rebalance iterator
> has been created
> {code:java}
> for (int i = 0; i < histMap.size(); i++) {
> int p = histMap.partitionAt(i);
> remainingParts.add(p);
> }
> {code}
> That means that we lost partitions that meant to be rebalanced by historical
> rebalance.
> The solution is to create an iterator after {{remainingParts}} filling.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14952) Releasing WAL segments when reaching DataStorageConfiguration#maxWalArchiveSize
[
https://issues.apache.org/jira/browse/IGNITE-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371372#comment-17371372
]
Ignite TC Bot commented on IGNITE-14952:
{panel:title=Branch: [pull/9198/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9198/head] Base: [master] : New Tests
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 1{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=6060843]]
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testReleaseUnreservedSegment - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testNoReleaseSegmentNearMaxWalArchiveSize - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testArchiveSizeForUnlimitedWalArchive - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testArchiveSizeForLimitedWalArchive - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testReleaseSegmentsOnExceedMaxWalArchiveSize - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6060873buildTypeId=IgniteTests24Java8_RunAll]
> Releasing WAL segments when reaching
> DataStorageConfiguration#maxWalArchiveSize
> ---
>
> Key: IGNITE-14952
> URL: https://issues.apache.org/jira/browse/IGNITE-14952
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the *DataStorageConfiguration#maxWalArchiveSize* is reached, release the
> WAL segments to avoid overflowing the WAL archive.
> Do not allow segment reservations to a
> *DataStorageConfiguration#minWalArchiveSize*.
> Subtask from
> [discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Exceeding-the-DataStorageConfiguration-getMaxWalArchiveSize-due-to-historical-rebalance-td52546.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14828) No fallback to full rebalance after exception on historical
[
https://issues.apache.org/jira/browse/IGNITE-14828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-14828:
-
Release Note:
Nodes will now properly fallback to full rebalance if historical rebalance fails
> No fallback to full rebalance after exception on historical
> ---
>
> Key: IGNITE-14828
> URL: https://issues.apache.org/jira/browse/IGNITE-14828
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have noticed that in some cases when we handle demand message in
> {{GridDhtPartitionSupplier.java}} it is possible for some reasons that
> {code:java}
> iter = grp.offheap().rebalanceIterator(demandMsg.partitions(),
> demandMsg.topologyVersion());
> {code}
> throw an exception. In that case, rebalance should switch to full, but the
> code has a bug and {{remainingParts}} has been filed after rebalance iterator
> has been created
> {code:java}
> for (int i = 0; i < histMap.size(); i++) {
> int p = histMap.partitionAt(i);
> remainingParts.add(p);
> }
> {code}
> That means that we lost partitions that meant to be rebalanced by historical
> rebalance.
> The solution is to create an iterator after {{remainingParts}} filling.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14901) Document SSL metrics.
[ https://issues.apache.org/jira/browse/IGNITE-14901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371374#comment-17371374 ] Nikita Safonov commented on IGNITE-14901: - Sure, I'll do this right now and let you know. > Document SSL metrics. > - > > Key: IGNITE-14901 > URL: https://issues.apache.org/jira/browse/IGNITE-14901 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It is needed to document SSL metrics introduced by > https://issues.apache.org/jira/browse/IGNITE-14658 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14801) Add tests for commands to manage metadata
[ https://issues.apache.org/jira/browse/IGNITE-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371348#comment-17371348 ] Alexey Gidaspov commented on IGNITE-14801: -- Hello [~tledkov-gridgain], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add tests for commands to manage metadata > - > > Key: IGNITE-14801 > URL: https://issues.apache.org/jira/browse/IGNITE-14801 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Add tests for commands to manage metadata (see IGNITE-13154). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14821) AssertionError: Historical iterator tries to iterate WAL out of reservation
[
https://issues.apache.org/jira/browse/IGNITE-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371345#comment-17371345
]
Alexey Gidaspov commented on IGNITE-14821:
--
Hello [~v.pyatkov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> AssertionError: Historical iterator tries to iterate WAL out of reservation
> ---
>
> Key: IGNITE-14821
> URL: https://issues.apache.org/jira/browse/IGNITE-14821
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A reason of the issue is incorrect comparison WAL pointer, that leads to
> choose not quite the last pointer for reservation before rebalance. The code
> selected the earliest WAL segment, but not the last pointer in it.
> Assuming assertion error in description:
> {code}Historical iterator tries to iterate WAL out of reservation
> [cache=SYSTEM_CACHEGROUP_LONGKEYS, reservedPointer=FileWALPointer [idx=10,
> fileOff=448674503, len=104925], historicalPointer=FileWALPointer [idx=10,
> fileOff=442844723, len=104925]]{code}
> reservedPointer is chosen incorrect, but corresponds to the valid segment
> {{idx=10}} (the same as in historicalPointer).
> A valid comparison of WAL pointers solves this issue. Segment number and
> segment offset participate in it together (look at the
> FileWalPointer#comapreTo method).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14828) No fallback to full rebalance after exception on historical
[
https://issues.apache.org/jira/browse/IGNITE-14828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371340#comment-17371340
]
Alexey Gidaspov commented on IGNITE-14828:
--
Hello [~maliev],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> No fallback to full rebalance after exception on historical
> ---
>
> Key: IGNITE-14828
> URL: https://issues.apache.org/jira/browse/IGNITE-14828
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have noticed that in some cases when we handle demand message in
> {{GridDhtPartitionSupplier.java}} it is possible for some reasons that
> {code:java}
> iter = grp.offheap().rebalanceIterator(demandMsg.partitions(),
> demandMsg.topologyVersion());
> {code}
> throw an exception. In that case, rebalance should switch to full, but the
> code has a bug and {{remainingParts}} has been filed after rebalance iterator
> has been created
> {code:java}
> for (int i = 0; i < histMap.size(); i++) {
> int p = histMap.partitionAt(i);
> remainingParts.add(p);
> }
> {code}
> That means that we lost partitions that meant to be rebalanced by historical
> rebalance.
> The solution is to create an iterator after {{remainingParts}} filling.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371337#comment-17371337
]
Andrey Mashenkov commented on IGNITE-14591:
---
[~vveider], would you please add the Javadoc check task to the TC
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14901) Document SSL metrics.
[ https://issues.apache.org/jira/browse/IGNITE-14901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371328#comment-17371328 ] Mikhail Petrov commented on IGNITE-14901: - [~nsafonov], [~igusev] Sorry to bother you, do you have the opportunity to review this ticket? > Document SSL metrics. > - > > Key: IGNITE-14901 > URL: https://issues.apache.org/jira/browse/IGNITE-14901 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It is needed to document SSL metrics introduced by > https://issues.apache.org/jira/browse/IGNITE-14658 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13056) Move indexes from the indexing to the core module
[ https://issues.apache.org/jira/browse/IGNITE-13056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-13056: Ignite Flags: (was: Docs Required,Release Notes Required) > Move indexes from the indexing to the core module > - > > Key: IGNITE-13056 > URL: https://issues.apache.org/jira/browse/IGNITE-13056 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-49, calcite > Fix For: 2.11 > > Time Spent: 12h > Remaining Estimate: 0h > > Since Ignite wants to leverage from several SQL engines we need to make work > with index independent from the used SQL engine. > We also should consider moving all machinery related to an index to the core > module to make it available from any module that wants to use it. > Requirements so far: > * Ability to track indexes in several engines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14152) JCache TCK suite runs some Ignite tests.
[ https://issues.apache.org/jira/browse/IGNITE-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14152: Ignite Flags: (was: Docs Required,Release Notes Required) > JCache TCK suite runs some Ignite tests. > > > Key: IGNITE-14152 > URL: https://issues.apache.org/jira/browse/IGNITE-14152 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Blocker > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > There is a wrong configuration of the "jcache-tck" profile. It excludes only > "*Test.java" classes, but by default maven runs also "*Tests.java" classes. > [1] > So, collection IgniteDataIntegrity*Tests* [2] runs for every start of this TC > suite. > Also after IGNITE-130512 the default collection of test expanded, then there > are more tests started to run within the suite and it started to fail by > timeout. > [1] > https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html > [2] > https://ci.ignite.apache.org/viewLog.html?buildId=5857723=IgniteTests24Java8_JCacheTck11=testsInfo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14781) Ignite examples from binary package fail to build due to ClientKubernetesPutGetExample
[
https://issues.apache.org/jira/browse/IGNITE-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-14781:
Ignite Flags: (was: Release Notes Required)
> Ignite examples from binary package fail to build due to
> ClientKubernetesPutGetExample
> --
>
> Key: IGNITE-14781
> URL: https://issues.apache.org/jira/browse/IGNITE-14781
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Affects Versions: 2.10
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Blocker
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.11.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ignite-examples ---
> [INFO]
> [INFO] --- build-helper-maven-plugin:3.2.0:add-source (add-sources) @
> ignite-examples ---
> [INFO] Source directory:
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java
> added.
> [INFO] Source directory:
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java
> added.
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> ignite-examples ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] Copying 14 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 266 source files to
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/target/classes
> [INFO] -
> [WARNING] COMPILATION WARNING :
> [INFO] -
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheAsyncApiExample.java:
> Some input files use or override a deprecated API.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheAsyncApiExample.java:
> Recompile with -Xlint:deprecation for details.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/store/CacheLoadOnlyStoreExample.java:
> Some input files use unchecked or unsafe operations.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/store/CacheLoadOnlyStoreExample.java:
> Recompile with -Xlint:unchecked for details.
> [INFO] 4 warnings
> [INFO] -
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[23,32]
> cannot find symbol
> symbol: class ThinClientKubernetesAddressFinder
> location: package org.apache.ignite.client
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[26,50]
> package org.apache.ignite.kubernetes.configuration does not exist
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[42,9]
> cannot find symbol
> symbol: class KubernetesConnectionConfiguration
> location: class
> org.apache.ignite.examples.client.ClientKubernetesPutGetExample
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[42,54]
> cannot find symbol
> symbol: class KubernetesConnectionConfiguration
> location: class
> org.apache.ignite.examples.client.ClientKubernetesPutGetExample
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[46,36]
> cannot find symbol
> symbol: class ThinClientKubernetesAddressFinder
> location: class
>
[jira] [Updated] (IGNITE-14219) stopAllGrids does not wait for IgniteProcessProxy stop.
[ https://issues.apache.org/jira/browse/IGNITE-14219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14219: Ignite Flags: (was: Docs Required,Release Notes Required) > stopAllGrids does not wait for IgniteProcessProxy stop. > --- > > Key: IGNITE-14219 > URL: https://issues.apache.org/jira/browse/IGNITE-14219 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.11 > > Time Spent: 0.5h > Remaining Estimate: 0h > > stopAllGrids does not wait for subprocess stops. In case of running grids in > subprocess (IgniteProcessProxy). It just wait for "kill -9" command, but it's > performed async. So subprocess with grid may be running for more time and > interfere with other tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14428) Formalize the names of the metrics included in the metric registry.
[ https://issues.apache.org/jira/browse/IGNITE-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14428: Fix Version/s: 2.11 > Formalize the names of the metrics included in the metric registry. > > > Key: IGNITE-14428 > URL: https://issues.apache.org/jira/browse/IGNITE-14428 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 3.5h > Remaining Estimate: 0h > > It's needed to refactor metric names to obey the global rule - all of them > must start with name of the registry they belongs to. And add corresponding > assertion. > The purpose of this change is to make all metrics that belongs to one > MetricRegistry have the name that obeys mentioned above rule regardless how > they were registered. It helps to use a consistent approach to work with all > metrics. > The following metric names will be changed to obey this rule: > JoinedNodes -> io.discovery.JoinedNodes > LeftNodes -> io.discovery.LeftNodes > FailedNodes -> io.discovery.FailedNodes > PendingMessagesRegistered -> io.discovery.PendingMessagesRegistered > CommunicationErrors -> io.discovery.CommunicationErrors > CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
[
https://issues.apache.org/jira/browse/IGNITE-14475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14475:
Ignite Flags: (was: Docs Required,Release Notes Required)
> C++/dotnet query-example select result is various with additional node
> --
>
> Key: IGNITE-14475
> URL: https://issues.apache.org/jira/browse/IGNITE-14475
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Steps:
> Start some additional nodes
> Execute query-example
> Expected output:
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> Jane Smith is working in Other
> John Smith is working in Other
> {noformat}
> Actual (in 80% cases):
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> John Smith is working in Other
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14978) .NET: Build fails on 2.1.808 and other older SDKs
[ https://issues.apache.org/jira/browse/IGNITE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14978: Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: Build fails on 2.1.808 and other older SDKs > - > > Key: IGNITE-14978 > URL: https://issues.apache.org/jira/browse/IGNITE-14978 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.11 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: .NET > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > * Install .NET SDK 2.1.808 > * Build the project with build.ps1 > Build fails due to inspection issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14903) Calcite. Bump calcite version up to 1.27.0.
[ https://issues.apache.org/jira/browse/IGNITE-14903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371317#comment-17371317 ] Taras Ledkov edited comment on IGNITE-14903 at 6/29/21, 12:13 PM: -- Merged to [sql-calcite|https://github.com/apache/ignite/commit/a9de644918bc6e811835d325535abf8765438104] was (Author: tledkov-gridgain): Merged to [sql-calcite-https://github.com/apache/ignite/commit/a9de644918bc6e811835d325535abf8765438104] > Calcite. Bump calcite version up to 1.27.0. > --- > > Key: IGNITE-14903 > URL: https://issues.apache.org/jira/browse/IGNITE-14903 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite, calcite2-required, calcite3-required > Time Spent: 20m > Remaining Estimate: 0h > > Update calcite ver up to 1.27.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14722) Document the ability to automatically restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17370620#comment-17370620 ] Pavel Pereslegin edited comment on IGNITE-14722 at 6/29/21, 11:48 AM: -- [~igusev], thanks, I tried to solve the issues you pointed out, could you please take another look? was (Author: xtern): [~igusev], thanks, I tried to solve the issues you pointed out, could you please take another look? > Document the ability to automatically restore a cache group from the snapshot. > -- > > Key: IGNITE-14722 > URL: https://issues.apache.org/jira/browse/IGNITE-14722 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Document the ability to automatically restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14893) Bug in GridCacheWriteBehindStore Flusher thread lookup
[
https://issues.apache.org/jira/browse/IGNITE-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14893:
-
Description:
There's a bug in GridCacheWriteBehindStore in the flusher method.
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
The logic states there that if flush thread count is not a power of 2, then
perform this math, which is not guaranteed to return a positive number.
{code:java}
idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
{code}
For example, if you pass this string as a key, it returns a negative number:
*accb2e8ea33e4a89b4189463cacc3c4e*
and then throws an array out of bounds exception when looking up the thread.
http://apache-ignite-developers.2346864.n4.nabble.com/IndexOutOfBoundsException-in-GridCacheWriteBehindStore-Flusher-thread-lookup-IGNITE-14893-tp52827.html
was:
There's a bug in GridCacheWriteBehindStore in the flusher method.
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
The logic states there that if flush thread count is not a power of 2, then
perform this math, which is not guaranteed to return a positive number.
{code:java}
idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
{code}
For example, if you pass this string as a key, it returns a negative number:
*accb2e8ea33e4a89b4189463cacc3c4e*
and then throws an array out of bounds exception when looking up the thread.
https://lists.apache.org/list.html?d...@ignite.apache.org
> Bug in GridCacheWriteBehindStore Flusher thread lookup
> --
>
> Key: IGNITE-14893
> URL: https://issues.apache.org/jira/browse/IGNITE-14893
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.5, 2.7.6, 2.9, 2.8.1, 2.10, 2.9.1
>Reporter: Mike W
>Assignee: Ilya Korol
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There's a bug in GridCacheWriteBehindStore in the flusher method.
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
> The logic states there that if flush thread count is not a power of 2, then
> perform this math, which is not guaranteed to return a positive number.
> {code:java}
> idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
> {code}
> For example, if you pass this string as a key, it returns a negative number:
> *accb2e8ea33e4a89b4189463cacc3c4e*
> and then throws an array out of bounds exception when looking up the thread.
> http://apache-ignite-developers.2346864.n4.nabble.com/IndexOutOfBoundsException-in-GridCacheWriteBehindStore-Flusher-thread-lookup-IGNITE-14893-tp52827.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15012) Adapting historical rebalance to segment release
[ https://issues.apache.org/jira/browse/IGNITE-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-15012: - Release Note: Adaptation of the historical rebalance to the release of WAL segments. > Adapting historical rebalance to segment release > > > Key: IGNITE-15012 > URL: https://issues.apache.org/jira/browse/IGNITE-15012 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > It is necessary to adapt the historical rebalance to the release of WAL > segments after their reservation. Since IGNITE-14952 will be automatically > released when the maximum is reached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
[
https://issues.apache.org/jira/browse/IGNITE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14376:
-
Fix Version/s: 2.11
> JmxMetricExporter fails to export discovery metrics
> ---
>
> Key: IGNITE-14376
> URL: https://issues.apache.org/jira/browse/IGNITE-14376
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Error:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.lambda$getMBeanInfo$0(MetricRegistryMBean.java:105)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getMBeanInfo(MetricRegistryMBean.java:85)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getAttribute(MetricRegistryMBean.java:58)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy32.getMBeanInfo(Unknown Source)
> at
> org.apache.ignite.internal.metric.JmxExporterSpiTest.test(JmxExporterSpiTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2391)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(jmxSpi);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid();
> DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
> mBean.getMBeanInfo();
> }
> {code}
> The main reason: JMX exporter assumes that each metric must starts with the
> name of the registry it belongs to (see MetricRegistryMBean#getMBeanInfo),
> but discovery metrics do not obey this naming convection (see
> TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15025) Add Maven check scripts to VCS
Peter Ivanov created IGNITE-15025: - Summary: Add Maven check scripts to VCS Key: IGNITE-15025 URL: https://issues.apache.org/jira/browse/IGNITE-15025 Project: Ignite Issue Type: Improvement Reporter: Peter Ivanov Assignee: Peter Ivanov Currently, only TC has scripts for Maven checks which leads to several problems: # Developers can use them to check code locally # Scripts can be lost with TC in inaccurate configuration operation. It is required to move scripts to Ignite's codebase and call them from TC build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15007) Add SystemView for baseline attributes stored in metastorage
[
https://issues.apache.org/jira/browse/IGNITE-15007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371236#comment-17371236
]
Ignite TC Bot commented on IGNITE-15007:
{panel:title=Branch: [pull/9204/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9204/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6064848]]
* {color:#013220}IgniteCacheTestSuite9:
SystemViewSelfTest.testBaselineNodeAttributes - PASSED{color}
{color:#8b}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6065520]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
SystemViewSelfTest.testBaselineNodeAttributes - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6064885buildTypeId=IgniteTests24Java8_RunAll]
> Add SystemView for baseline attributes stored in metastorage
>
>
> Key: IGNITE-15007
> URL: https://issues.apache.org/jira/browse/IGNITE-15007
> Project: Ignite
> Issue Type: New Feature
>Reporter: Ilya Shishkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The BaselineTopology entry in the Metastorage SystemView [1] does not show a
> baseline node attributes. We could add additional system view for the stored
> attributes of baseline nodes.
> 1.
> https://ignite.apache.org/docs/2.10.0/monitoring-metrics/system-views#metastorage
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14990) Incorrect values of cache, cache group, data region metrics after cluster re-activation
[ https://issues.apache.org/jira/browse/IGNITE-14990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14990: - Fix Version/s: 2.12 > Incorrect values of cache, cache group, data region metrics after cluster > re-activation > --- > > Key: IGNITE-14990 > URL: https://issues.apache.org/jira/browse/IGNITE-14990 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.12 > > Time Spent: 2h > Remaining Estimate: 0h > > Cache, cache group, data region metrics values are incorrect after the > cluster re-activation. > It happens because they are not registered with the new cache* context and > still point to the previous one. Data region metrics are not reset/remove > after deactivation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
