[jira] [Created] (IGNITE-14177) Query parallelism ignores "NULLS LAST" in "order by" clause
Ilya Kazakov created IGNITE-14177: - Summary: Query parallelism ignores "NULLS LAST" in "order by" clause Key: IGNITE-14177 URL: https://issues.apache.org/jira/browse/IGNITE-14177 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.9.1 Reporter: Ilya Kazakov Attachments: NullsLastWithParallels.java If set QueryParallelism to some value >=2, then "NULLS LAST" is ignored in "order by clause". e.g. SELECT * FROM ORDER BY ASC NULLS LAST A small reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14176) Pk and Affinity key indexes are not considered for planning.
Stanilovsky Evgeny created IGNITE-14176: --- Summary: Pk and Affinity key indexes are not considered for planning. Key: IGNITE-14176 URL: https://issues.apache.org/jira/browse/IGNITE-14176 Project: Ignite Issue Type: Improvement Components: sql Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny pk and affinity key indexes are not taken into account in planning phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14175) Update metric for loaded keys through rebalance once at the demand message
Kirill Tkalenko created IGNITE-14175:
Summary: Update metric for loaded keys through rebalance once at
the demand message
Key: IGNITE-14175
URL: https://issues.apache.org/jira/browse/IGNITE-14175
Project: Ignite
Issue Type: Improvement
Components: cache
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
Fix For: 2.11
We are consuming more than half of all rebalance time to updating metrics, even
if the statistic does not enable in the cache.
The problem is here:
{code:java}
//TODO: IGNITE-11330: Update metrics for touched cache only.
for (GridCacheContext ctx : grp.caches()) {
if (ctx.statisticsEnabled())
ctx.cache().metrics0().onRebalanceKeyReceived();
}
{code}
It needs to update once for one demand message and only if the statistic
enabled on the cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[MTCGA]: new failures in builds [5871876] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *Test with high flaky rate in master IgniteCachePutRetryAtomicSelfTest.testInvoke https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7568819892486826780=%3Cdefault%3E=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 04:44:48 15-02-2021
[jira] [Created] (IGNITE-14174) Python thin: returns the time value + the client's time zone, instead of the time value from the database.
Igor Sapego created IGNITE-14174:
Summary: Python thin: returns the time value + the client's time
zone, instead of the time value from the database.
Key: IGNITE-14174
URL: https://issues.apache.org/jira/browse/IGNITE-14174
Project: Ignite
Issue Type: Bug
Reporter: Igor Sapego
The server is located in Europe, the client is in the Moscow time zone:
{code:python}
from pyignite import Client
from datetime import datetime
c = Client(username='', password='', use_ssl=False)
c.connect('35.158.109.154', 10800)
c.sql('create table test(key int primary key, date datetime)')
current_time = datetime.now()
c.sql(f"insert into test (key, date) VALUES (1, '{current_time}')")
for row in c.sql('SELECT date FROM test'):
print(current_time, row[0][0])
c.close()
{code}
output:
{code:python}
2021-01-20 12:28:44.850381 2021-01-20 15:28:44.85
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[MTCGA]: new failures in builds [5869167] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Test with high flaky rate in master DataStreamProcessorPersistenceBinarySelfTest.testTryFlush https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=9122992512313573972=%3Cdefault%3E=testDetails Changes may lead to failure were done by - vladislav pyatkov https://ci.ignite.apache.org/viewModification.html?modId=916716 - vladislav pyatkov https://ci.ignite.apache.org/viewModification.html?modId=916707 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 13:29:48 14-02-2021
Re: .NET naming convention + RegisterSameJavaType mode
Hello, Pavel. Thanks, for the feedback > We can create a derived class so that existing _registerSameJavaType logic > works. For now, BinaryBasicNameMapper#GetTypeName is not virtual. So we can’t override it. And if we make GetTypeName virtual then any user can make extension of BinaryBasicNameMapper and use it. I thought we want to avoid this. Anyway, I’m OK with the built-in extension of BinaryBasicNameMapper. Will do those changes. > 13 февр. 2021 г., в 13:07, Pavel Tupitsyn написал(а): > > Nikolay, > > 1) What about the org./com. prefix that is present in all Java package names, > e.g: > Java: org.apache.ignite.foo.Bar > .NET: Apache.Ignite.Foo.Bar > > I think we should handle this too. > > 2) Can we create a separate name mapper instead of adding a property to the > existing one? > We can create a derived class so that existing _registerSameJavaType logic > works. > > On Fri, Feb 12, 2021 at 7:33 PM Nikolay Izhikov wrote: > Hello, Igniters. > > Currently, BasicBinaryNameMapper[isSimpleName=false] assumes that type names > equals both in Java and .Net. > > • Java type - ru.company.Model > • .Net type - ‘ru.company.Model` > > However, .net naming conventions [1] differs from java [2] > So, if a user follows both conventions then names will be > > • Java type - ru.company.Model > • .Net type - 'Ru.Company.Model` > > User can implement this behaviour in custom name mapper, but custom name > mapper will disable RegisterSameJavaType mode. > > To solve this issue I prepared a PR[3] and ticked [4]. > PR introduces new BasicBinaryNameMapper#ForceJavaNamingConventions flag that > enables mapping from .Net style to the java naming style. > > WDYT? > > [1] > https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces > [2] > https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html > [3] https://github.com/apache/ignite/pull/8795 > [4] https://issues.apache.org/jira/browse/IGNITE-14169 >
Re: Adding metrics of using WAL archive
Hello, Kirill Your conclusions still not clear for me. > It is not possible for us to estimate how much space a user will need in the > archive so as not to overflow it under its load > We take the maximum 44 and multiply it by a > DataStorageConfiguration#getWalSegmentSize Why you take a single day (24h) for a standard period? Is there any rationale behind this? 1. We have `walAutoArchiveAfterInactivity` property. So WAL segment can have a size less than the maximum. 2. For CDC feature I want to introduce «WAL force rollover timeout» to make data available for a consumer in a guaranteed period [1]. Why does the user want to estimate those numbers in the first place? Are we talking about some kind of capacity planning? If yes, then maybe it will be better to have a metric for a count of bytes written in the WAL? With it, we will have an exact number of space we need for WAL. How user should estimate capacity for a page memory and indexes? [1] https://issues.apache.org/jira/browse/IGNITE-13582 > 14 февр. 2021 г., в 09:48, ткаленко кирилл написал(а): > > Hi, Nikolay! > > The user will be able to take the getLastArchivedSegmentIndex every day and > remember it and do it, say, for several days. > > For example, when starting the application, the getLastArchivedSegmentIndex > is 0, then at the end of the first day the value will be 30 at the end of the > second 55 and at the end of the third 99. > It turns out that 30 segments were used for the first day, 25 for the second > and 44 for the third. We take the maximum 44 and multiply it by a > DataStorageConfiguration#getWalSegmentSize, and we get the possible maximum > that the archive overflow was the least likely. If the user uses compression, > then it can be subtracted from the result (result * > getMaxSizeCompressedArchivedSegment). > > 13.02.2021, 10:47, "Nikolay Izhikov" : >> Hello, Kirill. >> >>> It is not possible for us to estimate how much space a user will need in >>> the archive so as not to overflow it under its load >> >> It still not clear for me why do we need those metrics. >> Can you please, write down specific scenario - how user will use these >> metrics to estimate required WAL volume? >> >>> 12 февр. 2021 г., в 19:35, ткаленко кирилл >>> написал(а): >>> >>> Hi, Nikolay! >>> >>> It is not possible for us to estimate how much space a user will need in >>> the archive so as not to overflow it under its load. And the proposed >>> metrics will allow you to make a rough estimate. >>> >>> 12.02.2021, 17:23, "Nikolay Izhikov" : Hello, Kirill. Can you, please, clarify - What question about WAL user have in mind? And what answers he(or she) gets with these new metrics? > 12 февр. 2021 г., в 14:26, ткаленко кирилл > написал(а): > > Hi everyone! > At the moment, I have not found an opportunity to estimate how many WAL > segments fall into the archive, say per day. > So I created a ticket > https://issues.apache.org/jira/browse/IGNITE-14170 to add a couple of new > metrics.
