Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Denis, I've checked the permissions now I can make changes. > I'm encouraging you to work with Kseniya's technical editors Thank you, we have already started working together. On Thu, 18 Mar 2021 at 03:00, Denis Magda wrote: > > Maxim, > > I had to grant you admin access in the blogging settings. No you should be > able to create an article and invite other members (log in with your apache > ID): https://blogs.apache.org/roller-ui/authoring/members!save.rol > > Like the blog. (if you haven't done this yet, I'm encouraging you to work > with Kseniya's technical editors who can suggest style and flow-related > changes). > > - > Denis > > > On Wed, Mar 17, 2021 at 12:44 PM Maxim Muzafarov wrote: > > > Denis, > > > > I'm getting the following error while trying to create a new Weblog > > > Sorry, the blog administrator has disabled creation of new blogs. > > > > By the way, Nikita, Denis > > > > Can you review my blog post, please? > > > > https://github.com/Mmuzaf/mmuzaf.github.io/blob/main/_post/Release_Newsletter_210.md > > > > > > On Wed, 17 Mar 2021 at 19:32, Denis Magda wrote: > > > > > > Maxim, > > > > > > Check one more time. The infra instruction that you shared says a > > contributor needs to be in the Admin group in JIRA to get write access to > > the blog. I've added you to the Admin group. > > > - > > > Denis > > > > > > > > > > > > On Wed, Mar 17, 2021 at 12:00 PM Maxim Muzafarov > > wrote: > > >> > > >> Denis, > > >> > > >> > > >> I'd like to create a post on the blogs.apache.org news feed with the > > >> 2.10 release news. Do I need additional privileges to do this? > > >> > > >> According to the wiki page [1] after login with my credentials, I > > >> should see the `add post` button, however, I can't find it on the main > > >> page. Am I missing something? > > >> > > >> > > >> > > >> [1] https://infra.apache.org/project-blogs > > >> [2] https://blogs.apache.org/ignite/ > > >> > > >> On Wed, 17 Mar 2021 at 13:43, Pavel Tupitsyn > > wrote: > > >> > > > >> > Maxim, > > >> > > > >> > I've prepared a blog post about Ignite.NET changes [1], > > >> > please link it in the main post. > > >> > > > >> > [1] https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.10/ > > >> > > > >> > On Tue, Mar 16, 2021 at 5:15 PM Maxim Muzafarov > > wrote: > > >> > > > >> > > Denis, > > >> > > > > >> > > > > >> > > Thank you. I'll prepare a blog post notes for the major 2.10 > > features. > > >> > > The release hasn't been announced yet, some artefacts still waiting > > to > > >> > > be published. Hope everything will be ready by the end of this week. > > >> > > > > >> > > > > >> > > > Btw, don't we want to arrange a meetup gathering for Virtual or > > >> > > Russian-speaking meetup or both? > > >> > > > > >> > > It depends on our goals. If we want to promote Ignite Summit 2021, > > so > > >> > > the English-speaking meetup makes sense. > > >> > > > > >> > > On Tue, 16 Mar 2021 at 16:00, Denis Magda > > wrote: > > >> > > > > > >> > > > Hi Maxim, > > >> > > > > > >> > > > Ideally, a blog post should be published together with the > > announcement > > >> > > > email. So that the readers can learn more details from the > > article. > > >> > > Anyway, > > >> > > > you can post it later for 2.10 as long as the release is already > > >> > > completed. > > >> > > > > > >> > > > Btw, don't we want to arrange a meetup gathering for Virtual or > > >> > > > Russian-speaking meetup, or both? > > >> > > > > > >> > > > - > > >> > > > Denis > > >> > > > > > >> > > > > > >> > > > On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov < > > mmu...@apache.org> > > >> > > wrote: > > >> > > > > > >> > > > > Folks, > > >> > > > > > > >> > > > > I've done almost all the release steps with publishing accepted > > >> > > changes. > > >> > > > > What should I do with an announcement blog post for > > blogs.apache.org? > > >> > > > > Should it also be prepared prior to an announcement message? > > >> > > > > > > >> > > > > On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov < > > mmu...@apache.org> > > >> > > wrote: > > >> > > > > > > > >> > > > > > Pavel, > > >> > > > > > > > >> > > > > > Thank you! I'll prepare a new rc shortly. > > >> > > > > > > > >> > > > > > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn < > > ptupit...@apache.org> > > >> > > > > wrote: > > >> > > > > > > > > >> > > > > > > Maxim, thanks! > > >> > > > > > > I've cherry-picked IGNITE-14293. > > >> > > > > > > > > >> > > > > > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov < > > >> > > mmu...@apache.org> > > >> > > > > wrote: > > >> > > > > > > > > >> > > > > > > > Pavel, > > >> > > > > > > > > > >> > > > > > > > Sorry, my bad. Entangled in my local branches during > > trying to > > >> > > > > > > > cherry-pick related commits. > > >> > > > > > > > I've reverted this change. > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn < > > >> > > ptupit...@apache.org> > > >> > > > > wrote: > > >> > > > > > > > > > > >> > > > >
Re: Adding metrics of using WAL archive
LGTM. Please, proceed with the merge. > 17 марта 2021 г., в 12:20, ткаленко кирилл написал(а): > > Hi Nikolay! Can you do an additional review or can we merge? > > 15.03.2021, 08:48, "ткаленко кирилл" : >> Hi Nikolay! Can you do an additional review or can we merge? >> >> 05.03.2021, 16:33, "Nikolay Izhikov" : >>> Yes, definitely. >>> 5 марта 2021 г., в 16:31, ткаленко кирилл написал(а): Hi Nikolay, can you do a review? 02.03.2021, 18:59, "Nikolay Izhikov" : > +1 For this. > >>2 марта 2021 г., в 18:32, ткаленко кирилл >> написал(а): >> >>Hi, Nikolay! >> >>I thought about your proposal and offer the following two metrics: >> >>1)The number of bytes logged to the WAL; >>2)The number of compressed bytes in the WAL. >> >>Monotonically increasing long. >> >>WDYT?
Re: [DISCUSSION] IEP-69 The evolutionary release process
Maxim, Folks, hi. The approach looks reasonable to me, +1 As an additional user notification, we might use even/odd number strategy. User could be sure that even (as an example) major release doesn’t break backward compatibility. Crucial API changes might be collected only in odd releases. Moreover, odd majors might be omitted at all in case of absence of compatibility breach. 16.03.2021 21:05, Maxim Muzafarov пишет: Folks, Thanks to everyone for participating in the call. Here is the list of points we've agreed on and the list of actions which should be discussed in more details. = AGREED = == Versioning == grand.major.bugfix[-rc_number] The 'grand' version is fixed while both Ignite architectures (current version 2.x and 3.x) are in a state of active development/maintained or until otherwise is discussed further. This means: - the master branch of the ignite repository [2] always release under the '2.x.x' version - the main branch of the ignite-3 repository [1] always release under the '3.x.x' version The 'major' versions for each architecture may contain breaking backwards compatibility changes compared to the previous one if the following criteria are met: - users should be warned about breaking release changes (the ways of notification should be additionally discussed and agreed upon) - the deprecation rules may be applied for the current 'major' release (the ways of deprecation must be additionally discussed and agreed upon) - current @deprecated already have enough time live and some of them can be removed using common sense The 'bugfix' version is used for emergency releases and can't contain any breaking backwards compatibility changes. == Commitments == Any commitment to support previous releases (e.g. 1 year, 1 quarter) have no sense to the open-source Ignite community in the case of observed backward compatibility violations, however, in any of such cases, an emergency release can be performed according to the accepted release procedure. = DISCUSSION & SUGGESTIONS = == Deprecation rules == The API deprecation rules must be discussed and agreed upon in more details. The list of options we have: - deprecate and remove API allowed in the next release - deprecate and remove API allowed through the one release - deprecation may contain comments - the release version then the API will be changed - deprecation may contain comments - the date from which the API changes allowed I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which adds the `forRemoval` and `since` optional elements to the deprecated annotation and I think we can use a similar approach here with some additions. For instance, if the last released version is 2.10 my suggestions would be the following: - [case: change API as quickly as possible] mark some API as deprecated, set 'since' version 2.12, change it in the 2.12 release major version. - [case: deprecate API without intention to change] mark API as deprecated without 'since' options, change it without notifications since 2.13 releases and so on. == User notification rules == Uses must be well-notified about the planned backward compatibility violations. The options we have: - the notification thought the source code with well-described JavaDocs - add labels to the JIRA issue if some deprecations occur in the related patch - add deprecation and backward compatibility paragraph to the RELEASE_NOTES - add a page to the Apache Ignite website with a backwards compatibility description between the closest versions All of the above must be done. == Experimental and unstable APIs == The options we have: - only the new API can be marked as unstable and/or experimental - such APIs can be changed without any notifications Please, share your thoughts. [1] https://github.com/apache/ignite-3 [2] https://github.com/apache/ignite [3] https://openjdk.java.net/jeps/277 On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov wrote: Folks, let me add my 50 cents. I don't see major issues with this IEP, for now. And I really looking forward to talking about it. I can't get what causes misunderstanding. The only thing that concerns me here is that IEP requires the community to support solutions for 1 year, 1 quarter, etc. Apache community is not a commercial company that provides support of any kind, and I would be reluctant to add these or similar statements to any public documents. At any point in time, the community and PMC can vote and introduce any major feature breaking compatibility. We tend to avoid such actions to keep users best interest. But it is not a commitment. Sincerely чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov : Val, I'm sorry if anything from what I've said sounded disrespectful. All of you are examples for me to follow :-) Have you checked the `motivation` [1] topic on the IEP-69 page? Should I add more details to it prior to the call? I want to make Ignite better and also think that the current 2.x version with all the advan
Re: IEP-70: Async Continuation Executor
Denis,
For a reproducer, please see CacheAsyncContinuationExecutorTest.java in the
linked PoC [1]
[1]
https://github.com/apache/ignite/pull/8870/files#diff-c788c12013622093df07d8f628a6e8c5fb0c15007f0787f2d459dbb3e377fc5aR54
On Thu, Mar 18, 2021 at 1:58 AM Raymond Wilson
wrote:
> We implemented the ContinueWith() suggestion from Pavel, and it works well
> so far in testing, though we do not have data to support if there is or is
> not a performance penalty in our use case..
>
> To lend another vote to the 'Don't do continuations on the striped thread
> pool' line of thinking: Deadlocking is an issue as is starvation. In some
> ways starvation is more insidious because by the time things stop working
> the cause and effect distance may be large.
>
> I appreciate the documentation does make statements about not performing
> cache operations in a continuation due to deadlock possibilities, but that
> statement does not reveal why this is an issue. It is less a case of a
> async cache operation being followed by some other cache operation (an
> immediate issue), and more a general case of the continuation of
> application logic using a striped pool thread in a way that might mean that
> thread is never given back - it's now just a piece of the application
> infrastructure until some other application activity schedules away from
> that thread (eg: by ContinueWith or some other async operation in the
> application code that releases the thread). To be fair, beyond structures
> like ContinueWith(), it is not obvious how that continuation thread should
> be handed back. This will be the same behaviour for dedicated continuation
> pools, but with far less risk in the absence of ContinueWith() constructs.
>
> In the .Net world this is becoming more of an issue as fewer .Net use cases
> outside of UI bother with synchronization contexts by default.
>
> Raymond.
>
>
> On Thu, Mar 18, 2021 at 9:56 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Hi Denis,
> >
> > I think Pavel's main point is that behavior is unpredictable. For
> example,
> > AFAIK, putAsync can be executed in the main thread instead of the striped
> > pool thread if the operation is local. The listener can also be executed
> in
> > the main thread - this happens if the future is completed prior to
> listener
> > invocation (this is actually quite possible in the unit test environment
> > causing the test to pass). Finally, I'm pretty sure there are many cases
> > when a deadlock does not occur right away, but instead it will reveal
> > itself under high load due to thread starvation. The latter type of
> issues
> > is the most dangerous because they are often reproduced only in
> production.
> > Finally, there are performance considerations as well - cache operations
> > and listeners share the same fixed-sized pool which can have negative
> > effects.
> >
> > I'm OK with the change. Although, it might be better to introduce a new
> > fixed-sized pool instead of ForkJoinPool for listeners, simply because
> this
> > is the approach taken throughout the project. But this is up to a debate.
> >
> > -Val
> >
> > On Wed, Mar 17, 2021 at 11:31 AM Denis Garus
> wrote:
> >
> > > Pavel,
> > > I tried this:
> > >
> > > @Test
> > > public void test() throws Exception {
> > > IgniteCache cache =
> > > startGrid().getOrCreateCache("test_cache");
> > >
> > > cache.putAsync(1, "one").listen(f -> cache.replace(1, "two"));
> > >
> > > assertEquals("two", cache.get(1));
> > > }
> > >
> > > and this test is green.
> > > I believe that an user can make listener that leads to deadlock, but
> > > the example in the IEP does not reflect this.
> > >
> > >
> > >
> > > ср, 17 мар. 2021 г. в 17:36, Вячеслав Коптилин <
> slava.kopti...@gmail.com
> > >:
> > >
> > > > Hi Pavel,
> > > >
> > > > > Not a good excuse really. We have a usability problem, you have to
> > > admit
> > > > it.
> > > > Fair enough. I agree that this is a usability issue, but I have
> doubts
> > > that
> > > > the proposed approach to overcome it is the best one.
> > > >
> > > > > Documentation won't help - no one is going to read the Javadoc for
> a
> > > > trivial method like putAsync
> > > > That is sad... However, I don't think that this is a strong argument
> > > here.
> > > >
> > > > This is just my opinion. Let's see what other community members have
> to
> > > > say.
> > > >
> > > > Thanks,
> > > > S.
> > > >
> > > >
> > > > ср, 17 мар. 2021 г. в 17:01, Pavel Tupitsyn :
> > > >
> > > > > > the user should use the right API
> > > > >
> > > > > Not a good excuse really. We have a usability problem, you have to
> > > admit
> > > > > it.
> > > > > "The brakes did not work on your car - too bad, you should have
> known
> > > > that
> > > > > on Sundays only your left foot is allowed on the pedal"
> > > > >
> > > > > This particular use case is too intricate.
> > > > > Even when you know about that, it is difficult to decide what can
> run
> > > on
> > > > > the stri
[MTCGA]: new failures in builds [5920892] 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. *New test failure in master IgniteUtilsSelfTest.testDetectPeerDeployAwareInfiniteRecursion https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3041458559966726731&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - atri sharma https://ci.ignite.apache.org/viewModification.html?modId=919705 - 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 12:55:19 18-03-2021
[jira] [Created] (IGNITE-14336) SQL. Calcite: can't find a column during the query if it was added via alter table
Fedor Malchikov created IGNITE-14336:
-
Summary: SQL. Calcite: can't find a column during the query if it
was added via alter table
Key: IGNITE-14336
URL: https://issues.apache.org/jira/browse/IGNITE-14336
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Fedor Malchikov
{code:java}
52/627 CREATE TABLE t1 ( id INT NOT NULL, tinyint_col1 TINYINT, PRIMARY
KEY (id) ) ;
No rows affected (0.377 seconds)
53/627 ALTER TABLE t1 ADD COLUMN new_col1 BOOLEAN;
No rows affected (0.037 seconds)
54/627 # DATA LOADING FOR t1
55/627 INSERT INTO t1 (id,tinyint_col1) VALUES
(2,0),(3,-1),(4,1),(5,-128),(-6,NULL),(7,-127),(8,126),(9,9),(10,10),(-11,NULL),(12,12),(13,13),(14,14),(15,15),(-16,NULL),(17,17),(18,18),(19,19),(20,20),(-21,NULL),(22,22),(23,23),(24,24),(25,25),(-26,NULL),(27,27),(28,28),(29,29),(30,30),(-31,NULL),(32,32),(33,33),(34,34),(35,35),(-36,NULL),(37,37),(38,38),(39,39),(40,40),(-41,NULL),(42,42),(43,43),(44,44),(45,45),(-46,NULL),(47,47),(48,48),(49,49),(50,50),(-51,NULL),(52,52),(53,53),(54,54),(55,55),(-56,NULL),(57,57),(58,58),(59,59),(60,60),(-61,NULL),(62,62),(63,63),(64,64),(65,65),(-66,NULL),(67,67),(68,68),(69,69),(70,70),(-71,NULL),(72,72),(73,73),(74,74),(75,75),(-76,NULL),(77,77),(78,78),(79,79),(80,80),(-81,NULL),(82,82),(83,83),(84,84),(85,85),(-86,NULL),(87,87),(88,88),(89,89),(90,90),(-91,NULL),(92,92),(93,93),(94,94),(95,95),(-96,NULL),(97,97),(98,98),(99,99),(100,100),(-101,NULL),(102,102),(103,103),(104,104),(105,105),(-106,NULL),(107,107),(108,108),(109,109),(110,110),(-111,NULL),(112,112),(113,113),(114,114),(115,115),(-116,NULL),(117,117),(118,118),(119,119),(120,120),(-121,NULL),(122,122),(123,123),(124,124),(125,125),(-126,NULL),(127,127),(128,-1),(129,2),(130,3),(-131,NULL),(132,5),(133,-6),(134,7),(135,8),(-136,NULL),(137,10),(138,-11),(139,12),(140,13),(-141,NULL),(142,15),(143,-16),(144,17),(145,18),(-146,NULL),(147,20),(148,-21),(149,22),(150,23),(-151,NULL);
150 rows affected (0.481 seconds)
56/627 ALTER TABLE t1 ADD COLUMN new_col2 BOOLEAN;
No rows affected (0.013 seconds)
57/627 SELECT new_col1, new_col2 FROM t1 ORDER BY id;
Error: Failed to plan query. (state=5,code=1)java.sql.SQLException: Failed
to plan query.at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:234)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
at sqlline.Commands.execute(Commands.java:823)at
sqlline.Commands.sql(Commands.java:733)at
sqlline.SqlLine.dispatch(SqlLine.java:795)at
sqlline.SqlLine.runCommands(SqlLine.java:1706)at
sqlline.Commands.run(Commands.java:1317)at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)at
sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:791)at
sqlline.SqlLine.initArgs(SqlLine.java:595)at
sqlline.SqlLine.begin(SqlLine.java:643)at
sqlline.SqlLine.start(SqlLine.java:373)at
sqlline.SqlLine.main(SqlLine.java:265)
{code}
Error in logs:
{code:java}
[03:59:26,337][INFO][client-connector-#172][CalciteQueryProcessor] Going to
execute new query with Calcite: sql=SELECT new_col1, new_col2 FROM t1 ORDER BY
id
[03:59:26,605][SEVERE][client-connector-#172][JdbcRequestHandler] Failed to
execute SQL query [reqId=5, req=JdbcQueryExecuteRequest [schemaName=PUBLIC,
pageSize=1024, maxRows=0, sqlQry=SELECT new_col1, new_col2 FROM t1 ORDER BY id,
args=Object[] [], stmtType=ANY_STATEMENT_TYPE, autoCommit=true,
partResReq=false, explicitTimeout=false, super=JdbcRequest [type=2, reqId=5]]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
plan query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:522)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:379)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:249)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.querySqlFields(JdbcRequestHandler.java:790)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcReques
[ANNOUNCE] Apache Ignite 2.10.0 Released
The Apache Ignite Community is pleased to announce the release of Apache Ignite 2.10.0. Apache Ignite® is an in-memory computing platform for transactional, analytical, and streaming workloads delivering in-memory speeds at a petabyte scale. https://ignite.apache.org The Apache Ignite community has made a lot of changes in the 2.10.0 release, hopefully, this blog post will help you to know about some valuable improvements: https://blogs.apache.org/ignite/entry/apache-ignite-2-10-thin For the full list of changes, you can refer to the RELEASE_NOTES list which is trying to catalogue the most significant improvements for this version of the platform. https://ignite.apache.org/releases/2.10.0/release_notes.html Download the latest Ignite version from here: https://ignite.apache.org/download.cgi Please let us know if you encounter any problems: https://ignite.apache.org/community/resources.html#ask Regards, Maxim Muzafarov on behalf of the Apache Ignite community.
[jira] [Created] (IGNITE-14337) Increase default failure detection timeout to 2 seconds
Anton Vinogradov created IGNITE-14337: - Summary: Increase default failure detection timeout to 2 seconds Key: IGNITE-14337 URL: https://issues.apache.org/jira/browse/IGNITE-14337 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov This should fix nightly build failures because of VM's freezes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14338) Unable to use same class with @QuerySqlField for multiple times for field.
André Schäfer created IGNITE-14338:
--
Summary: Unable to use same class with @QuerySqlField for multiple
times for field.
Key: IGNITE-14338
URL: https://issues.apache.org/jira/browse/IGNITE-14338
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1, 2.10, 2.9
Reporter: André Schäfer
Potential Regression of IGNITE-13216 ?
When a Class with @QuerySqlField annotated fields is used for fields of the
parent entity multiple time, this results in a pseudo conflict.
e.g.
{code:java}
class Address { // nested
@QuerySqlField
String street;
}
class Person { // parent
@QuerySqlField
String name;
@QuerySqlField
Address contact; // first usage
@QuerySqlField
Address billing; // second usage
}
{code}
Leads to an Exception like
{code:java}
javax.cache.CacheException: Property with name 'street' already exists for
value: QueryEntity [key=String, value=Address]{code}
Most likely this is caused by the change in
{{QueryEntityTypeDescriptor:172}}
from {{String propName = prop.fullName();}}
to {{String propName = prop.name();}}
to be able to perform a check with the annotations name value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14339) Class with @QuerySqlField annotated fields cannot be used for multiple fields of an aggregate
André Schäfer created IGNITE-14339:
--
Summary: Class with @QuerySqlField annotated fields cannot be used
for multiple fields of an aggregate
Key: IGNITE-14339
URL: https://issues.apache.org/jira/browse/IGNITE-14339
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1, 2.10, 2.9
Reporter: André Schäfer
Potential Regression of IGNITE-13216 ?
If a class that has fields annotated with @QuerySqlField (without name
attribute) and should be used for multiple fields of a parent class, this
results in a pseudo conflict and throws an exception.
e.g.
{code}
class Person { // parent
@QuerySqlField
Address contact; // first usage
@QuerySqlField
Address billing; // second usage
}
class Address { // nested
@QuerySqlField
String street;
}
{code}
leads to an exception like
{code}
javax.cache.CacheException: Property with name 'street' already exists for
value: QueryEntity [key=String, value=Person]
{code}
This is cause by a change in \{{QueryEntityTypeDescriptor:172}}:
from \{{String propName = prop.fullName();}}
to \{{String propName = prop.name();}}
most likely to be able to use it for some hangling logic for the value
attribute of the annotation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14340) Class with @QuerySqlField fields cannot be used multiple times in an aggregate
André Schäfer created IGNITE-14340:
--
Summary: Class with @QuerySqlField fields cannot be used multiple
times in an aggregate
Key: IGNITE-14340
URL: https://issues.apache.org/jira/browse/IGNITE-14340
Project: Ignite
Issue Type: Bug
Reporter: André Schäfer
Potential Regression of IGNITE-13216 ?
If a class that has fields annotated with @QuerySqlField (without name
attribute) and should be used for multiple fields of a parent class, this
results in a pseudo conflict and throws an exception.
e.g.
{code}
class Person { // parent
@QuerySqlField
Address contact; // first usage
@QuerySqlField
Address billing; // second usage
}
class Address { // nested
@QuerySqlField
String street;
}
{code}
leads to an exception like
{code}
javax.cache.CacheException: Property with name 'street' already exists for
value: QueryEntity [key=String, value=Person]
{code}
This is cause by a change in {{QueryEntityTypeDescriptor:172}}:
from {{String propName = prop.fullName();}}
to {{String propName = prop.name();}}
most likely to be able to use it for some hangling logic for the value
attribute of the annotation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [ANNOUNCE] Apache Ignite 2.10.0 Released
Hello! I thought that we are a distributed database for a few releases? Probably this announcement template needs adjustment. Regards, -- Ilya Kasnacheev чт, 18 мар. 2021 г. в 13:31, Maxim Muzafarov : > The Apache Ignite Community is pleased to announce the release of > Apache Ignite 2.10.0. > > Apache Ignite® is an in-memory computing platform for transactional, > analytical, and streaming workloads delivering in-memory speeds at > a petabyte scale. > https://ignite.apache.org > > The Apache Ignite community has made a lot of changes in the 2.10.0 > release, hopefully, this blog post will help you to know about some > valuable improvements: > https://blogs.apache.org/ignite/entry/apache-ignite-2-10-thin > > For the full list of changes, you can refer to the RELEASE_NOTES list > which is trying to catalogue the most significant improvements for > this version of the platform. > https://ignite.apache.org/releases/2.10.0/release_notes.html > > Download the latest Ignite version from here: > https://ignite.apache.org/download.cgi > > Please let us know if you encounter any problems: > https://ignite.apache.org/community/resources.html#ask > > > Regards, > Maxim Muzafarov on behalf of the Apache Ignite community. >
Re: [ANNOUNCE] Apache Ignite 2.10.0 Released
Excellent, thanks Maxim for driving the release! As for the product definition (in-memory platform vs. distributed database), just copy the positioning we use on the landing page (Distributed Database For High-Performance Computing With In-Memory Speed) - Denis On Thu, Mar 18, 2021 at 6:31 AM Maxim Muzafarov wrote: > The Apache Ignite Community is pleased to announce the release of > Apache Ignite 2.10.0. > > Apache Ignite® is an in-memory computing platform for transactional, > analytical, and streaming workloads delivering in-memory speeds at > a petabyte scale. > https://ignite.apache.org > > The Apache Ignite community has made a lot of changes in the 2.10.0 > release, hopefully, this blog post will help you to know about some > valuable improvements: > https://blogs.apache.org/ignite/entry/apache-ignite-2-10-thin > > For the full list of changes, you can refer to the RELEASE_NOTES list > which is trying to catalogue the most significant improvements for > this version of the platform. > https://ignite.apache.org/releases/2.10.0/release_notes.html > > Download the latest Ignite version from here: > https://ignite.apache.org/download.cgi > > Please let us know if you encounter any problems: > https://ignite.apache.org/community/resources.html#ask > > > Regards, > Maxim Muzafarov on behalf of the Apache Ignite community. >
Re: How to Contribute 2021
Hello! I took the liberty renaming the new version to https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute The old version is still available in the meantime as https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+OLD The next step would probably be splitting committer information to a separate page. Is there anybody who wants to take it? We can also file a ticket to overhaul CONTRIBUTING.md if somebody is willing to do that. Regards, -- Ilya Kasnacheev чт, 18 мар. 2021 г. в 09:37, Ivan Pavlukhin : > In my mind CONTRIBUTING.md is a nice and quite common starting point > for contributors. Other projects use it as well [1], [2]. Also GitHub > treats it somehow specially, I recall it suggested me to make familiar > with CONTRIBUTING.md of some repo. > > [1] https://github.com/hazelcast/hazelcast/blob/master/CONTRIBUTING.md > [2] https://github.com/apache/cassandra/blob/trunk/CONTRIBUTING.md > > 2021-03-18 0:32 GMT+03:00, Maxim Muzafarov : > > Kseniya, > > > > From my point of view he contribute.html and CONTRIBUTING.md should be > > the same with the reference to the wiki page How_to_Contribute_2021 > > describing all the additional details and common issues with the first > > contributions. > > > > I also think it would be better to create special dedicated pages for > > committers and contributors. I don't get the idea why we can't do this > > keeping the same data as they were on the original How_to_Contribute > > page. > > > > On Tue, 16 Mar 2021 at 13:18, Kseniya Romanova > > wrote: > >> > >> So we do have 3 sources for how to contribute: > >> > >> 1. https://ignite.apache.org/community/contribute.html > >> 2. https://github.com/apache/ignite/blob/master/CONTRIBUTING.md > >> 3. > >> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021 > >> > >> Seems that wiki is more technical, right? But is there any reason for 2 > >> different versions for GitHub and the website? > >> > >> вт, 16 мар. 2021 г. в 13:11, Ilya Kasnacheev >: > >> > >> > Hello again! > >> > > >> > Based on the feedback, I have removed ASCII art from the git section, > >> > making it shorter and clearer. > >> > > >> > Regards, > >> > -- > >> > Ilya Kasnacheev > >> > > >> > > >> > вт, 16 мар. 2021 г. в 11:47, Ilya Kasnacheev > >> > : > >> > > >> > > Hello, Pavel! > >> > > > >> > > At the very minimum, a newcomer should be able to run tests on TC or > >> > MTCGA. > >> > > > >> > > Explaining that process takes most of the contribution guide. > >> > > > >> > > Even if somebody is ready to run those tests for a newcomer once or > >> > > twice > >> > > (already a long shot, it's hard to even get a simple review), they > >> > > have > >> > no > >> > > opportunity to learn except for this guide. They really don't have > >> > anybody > >> > > to ask. > >> > > > >> > > As I have said, I can't create two documents at the same time so if > >> > > we > >> > > need a separate one for committers, it may only be written after the > >> > fact, > >> > > and we can't remove essential information in the meantime. > >> > > > >> > > Regards, > >> > > -- > >> > > Ilya Kasnacheev > >> > > > >> > > > >> > > пн, 15 мар. 2021 г. в 18:26, Pavel Tupitsyn : > >> > > > >> > >> Ilya, > >> > >> > >> > >> Thanks for the effort! > >> > >> > >> > >> I think this guide should be much shorter and simple. > >> > >> Right now it is intimidating for newcomers. > >> > >> > >> > >> What they need is basically > >> > >> * Register in Jira, pick a ticket, assign, put In Progress > >> > >> * Create a fork, implement > >> > >> * Create a PR > >> > >> * Ask for review > >> > >> > >> > >> Maybe we should have a separate, detailed guide for Committers, > >> > >> and a simple one for Contributors? > >> > >> > >> > >> On Mon, Mar 15, 2021 at 6:19 PM Ilya Kasnacheev < > >> > >> ilya.kasnach...@gmail.com> > >> > >> wrote: > >> > >> > >> > >> > Hello! > >> > >> > > >> > >> > Please see inline. > >> > >> > > >> > >> > пн, 15 мар. 2021 г. в 18:06, Maxim Muzafarov >: > >> > >> > > >> > >> > > Hello, > >> > >> > > > >> > >> > > > >> > >> > > > Ignite employs both Review-Then-Commit processes. > >> > >> > > > >> > >> > > The Commit-Then-Review (CTR) removed? > >> > >> > > > >> > >> > I don't see any applications of CTR during the few last years. > >> > Streamers > >> > >> > were supposed to be CTR but Saikat Maitra still asked for the > >> > >> > review > >> > of > >> > >> > streamers-related commits. > >> > >> > > >> > >> > > Information for committers > >> > >> > > > >> > >> > > Do we need this on a page for newcomers? I'd like to mention > >> > >> > > that > >> > some > >> > >> > > of the committers still use the commit script, however, I think > >> > >> > > it > >> > >> > > will be better to configure the GitHub interaction. > >> > >> > > > >> > >> > I don't think there's a separate page for committers. If there > is, > >> > >> please > >> > >> > point me to it, and we can remove the section. I don't think we > >> > >> > should >
[jira] [Created] (IGNITE-14341) Significant performance drop when entries expiring concurrently
Aleksey Plekhanov created IGNITE-14341:
--
Summary: Significant performance drop when entries expiring
concurrently
Key: IGNITE-14341
URL: https://issues.apache.org/jira/browse/IGNITE-14341
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Currently, there is a significant performance drop when expired entries
concurrently evicted by threads that perform some actions with cache (see
attached reproducer):
{noformat}
Benchmark Mode Cnt Score Error Units
JmhCacheExpireBenchmark.putWithExpire thrpt3 100,132 ± 21,025 ops/ms
JmhCacheExpireBenchmark.putWithoutExpire thrpt3 2133,122 ± 559,694
ops/ms{noformat}
Root cause: pending entries tree (offheap BPlusTree) is used to track expired
entries, after each cache operation (and by timeout thread) there is an attempt
to evict some amount of expired entries. these entries looked up from the start
of the pending entries tree and there is a contention on the first leaf page of
that tree.
All threads waiting for the same page lock:
{noformat}
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
org.apache.ignite.internal.util.OffheapReadWriteLock.waitAcquireWriteLock(OffheapReadWriteLock.java:503)
at
org.apache.ignite.internal.util.OffheapReadWriteLock.writeLock(OffheapReadWriteLock.java:244)
at
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.writeLock(PageMemoryNoStoreImpl.java:528)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock(PageHandler.java:422)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:350)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:325)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$13200(BPlusTree.java:100)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:4588)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:4567)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.tryRemoveFromLeaf(BPlusTree.java:5196)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.access$6800(BPlusTree.java:4209)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2189)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2165)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2165)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:2076)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1905)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expireInternal(IgniteCacheOffheapManagerImpl.java:1426)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1375)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:246)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:882){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14342) Extend Tuple interface with ordered field access.
Andrey Mashenkov created IGNITE-14342: - Summary: Extend Tuple interface with ordered field access. Key: IGNITE-14342 URL: https://issues.apache.org/jira/browse/IGNITE-14342 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov Let's extend Tuple interface by adding methods for indexed column access (like JDBC resultset has). It may need to expose more information about Tuple structure, such as * column name -> column index * all columns in the tuple This may be useful for SQL\JDBC drivers and bulk operation where Tuples can have the same structure and column order. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[DISCUSSION] Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
Hello, Igniters. As of now, there are two independent APIs related to security: 1. IgniteSecurity - handle node/client authentication and authorize all operations. 2. IgniteAuthenticationProcessor - handle authentication of thin clients only. The main purpose of creating the IgniteAuthenticationProcessor was to bring default security implementation in Ignite (see [1]) because IgniteSecurity has always had a single implementation that delegates authorization and authentication operation to an external security plugin. But two different APIs that are related to the same leads to security checks duplication in code. As of now, it's possible to configure both security approaches at the same time, and that is confusing for the user. E.g., the user can provide a security plugin and execute ALTER / DROP / CREATE commands successfully. In this case, mentioned commands will do nothing because they only work with the authentication processor I propose to merge the two mentioned above security APIs into one based on the IgniteSecurity interface. For this it is proposed: 1. Remove an IgniteAuthenticationProcessor that is now treated as an independent processor. 2. Move the logic of IgniteAuthenticationProcessor into the implementation of the security plugin that will be used if authentication is enabled via configuration. 3. 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. 4. Remove the AuthorizationContext completely as IgniteSecurity provides an API for storing and managing the security contexts. 5. 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:    public void createUser(String login, UserOptions opts) throws IgniteCheckedException   �    public void alterUser(String login, UserOptions opts) throws IgniteCheckedException       �    public void dropUser(String login) throws IgniteCheckedException 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 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. 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 authentication is disabled. WDYT? Ticket - https://issues.apache.org/jira/browse/IGNITE-14335 Draft PR - https://github.com/apache/ignite/pull/8892 [1] - http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-td26058.html Regards, Mikhail.
Re: Access to Ignite Confluence
Hello! I have granted you full edit rights on our Confluence space. TWIMC I have validated with Nikita that it's his actual email address. Regards, -- Ilya Kasnacheev вт, 16 мар. 2021 г. в 22:28, Никита Сафонов : > Hi everyone, > > Could you please grant me the necessary rights to comment on the confluence > articles? > > My full name: Nikita Safonov > Email: vlasovpavel2...@gmail.com > > Thank you! > > Regards, > Nikita >
[jira] [Created] (IGNITE-14343) .NET: Allow arbitrary MemberInit projections in LINQ
Pavel Tupitsyn created IGNITE-14343:
---
Summary: .NET: Allow arbitrary MemberInit projections in LINQ
Key: IGNITE-14343
URL: https://issues.apache.org/jira/browse/IGNITE-14343
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.11
Ignite LINQ provider allows anonymous type projections:
{code}
query.Select(emp => new {Id = emp.Key, Name = emp.Value.Name});
{code}
However, it does not work with a custom class:
{code}
query.Select(emp => new Foo {Id = emp.Key, Name = emp.Value.Name});
{code}
throws exception:
{code}
System.NotSupportedException : The expression 'new Foo() {Id = [x].Key}' (type:
System.Linq.Expressions.MemberInitExpression) is not supported.
{code}
Add VisitMemberInit overload to CacheQueryExpressionVisitor to support this
scenario.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14344) Json mapper must be shared between different http responses in ignite-rest
Kirill Gusakov created IGNITE-14344: --- Summary: Json mapper must be shared between different http responses in ignite-rest Key: IGNITE-14344 URL: https://issues.apache.org/jira/browse/IGNITE-14344 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14345) There is a spelling error in the debug information
xin.ch...@intotech.com.cn created IGNITE-14345: -- Summary: There is a spelling error in the debug information Key: IGNITE-14345 URL: https://issues.apache.org/jira/browse/IGNITE-14345 Project: Ignite Issue Type: Improvement Reporter: xin.ch...@intotech.com.cn Attachments: Snipaste_2021-03-19_10-13-23.png This code is in the org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(String).I think it should be TCP, not TPC. !Snipaste_2021-03-19_10-13-23.png|width=677,height=203! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [5921007] 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. *New test failure in master-nightly IgniteUtilsSelfTest.testDetectPeerDeployAwareInfiniteRecursion https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3059424454524523197&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - atri sharma https://ci.ignite.apache.org/viewModification.html?modId=919705 - 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 05:25:22 19-03-2021
[jira] [Created] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
Atri Sharma created IGNITE-14346: Summary: Implement Azure Blob Storage Based IP Finder Key: IGNITE-14346 URL: https://issues.apache.org/jira/browse/IGNITE-14346 Project: Ignite Issue Type: Improvement Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Azure Cloud IP Finder
Thanks Denis. I have raised a PR for the same: https://github.com/apache/ignite/pull/8897 Regards, Atri On Wed, Mar 10, 2021 at 1:21 AM Denis Magda wrote: > > Atri, > > Let's discuss the subj together with the community. Ignite already supports > AWS [1] and GCE [2] IP Finders out of the box, but the Azure one is still > missing. I can confirm that the demand exists, and rather frequently, I see > developers asking for an Azure-native IP finder for Ignite. > > Atri, could you please research how to implement the IP finder and suggest > a solution in this discussion thread? See how it was done for AWS and GCE, > we might go the same route or use a more contemporary and easy-to-configure > approach for Azure. > > [1] > https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#amazon-s3-ip-finder > [2] > https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery > > - > Denis -- Regards, Atri Apache Concerted
[jira] [Created] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
Atri Sharma created IGNITE-14347: Summary: Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage Key: IGNITE-14347 URL: https://issues.apache.org/jira/browse/IGNITE-14347 Project: Ignite Issue Type: Improvement Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
