[jira] [Created] (IGNITE-9427) SQL MVCC: old data read after parallel update with autoCommit=false
Stepan Pilschikov created IGNITE-9427:
-
Summary: SQL MVCC: old data read after parallel update with
autoCommit=false
Key: IGNITE-9427
URL: https://issues.apache.org/jira/browse/IGNITE-9427
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.5
Reporter: Stepan Pilschikov
Second user don't seeing first user update right after select before commit
Table:
{code:sql}create table test(id int, field_int int, field_var varchar(50),
primary key (id, field_int)) with "template=replicated,
ATOMICITY=TRANSACTIONAL{code}
With one row of data:
{code:sql}insert into test(id, field_int, field_var) values (1, 1,
'test_1'){code}
With two connections to sqlline
{code}sqlline.sh --autoCommit=false --color=true --outputFormat=csv
--showNestedErrs=true --showWarnings=true --verbose=true -u
jdbc:ignite:thin://127.0.0.1:10800 {code}
for *user_1* and *user_2*
*user_1*:
{code:sql}
begin transaction;
select * from test where id = 1 for update;
{code}
*user_2*:
{code:sql}
update test set field_var = 'updated' where id = 1; - transaction get locked
{code}
*user_1*:
{code:sql}
commit;
select * from test; - 1, 1, 'test_1'
{code}
*user_2*:
{code:sql}
1 row affected
commit;
select * from test; - 1, 1, 'updated'
{code}
*user_1*:
{code:sql}
select * from test; - 1, 1, 'test_1' < should be 'updated'
{code}
if *user_1* do commit then he will be seeing update
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Bots on dev list
I guess, nobody uses it because it's flooded by bots. It may be useful to lookup old threads for people, who are not subscribed to the mailing list from the beginning of time. Denis чт, 30 авг. 2018 г. в 3:39, Dmitriy Setrakyan : > Is anyone in the community using or was using Nabble for the dev list > communication? Personally, I am subscribed to the dev list and use filters > in my email client. > > D. > > On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov > wrote: > > > Guys, > > > > Yep, I use filters on my mail account. But the portal is impossible to > use. > > When you subscribe to the dev list for the first time, you don't have any > > history on your email, > > and the archive is polluted with messages, sent by bots. > > > > Some view on Nabble, that doesn't contain any automatically generated > > messages, would help here. > > > > Denis > > > > ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov : > > > > > Modern mail services allow users to filter messages. You can easily > > filter > > > out bot messages. > > > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > > > > > > > Igniters, > > > > > > > > We have a lot of threads, created by bots on the dev list. > > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, > some > > > > others too, but these are the most active. > > > > > > > > Take a look at this page: > > > > http://apache-ignite-developers.2346864.n4.nabble. > > > > com/Apache-Ignite-Developers-f1i35.html > > > > It's hard to find actual discussions in this mess. I'd like to see > > > > something like what we have on the users list: > > > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > > > > > It doesn't seem necessary to me to mix discussions with this cryptic > > flow > > > > of information. > > > > Can we create a separate mailing list for bots? > > > > > > > > Denis > > > > > > > > > >
[jira] [Created] (IGNITE-9428) MVCC TX: Multiple H2ResultSetIterator closing leads to assertion in MvccProcessor
Roman Kondakov created IGNITE-9428:
--
Summary: MVCC TX: Multiple H2ResultSetIterator closing leads to
assertion in MvccProcessor
Key: IGNITE-9428
URL: https://issues.apache.org/jira/browse/IGNITE-9428
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Reproducer:
{{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
Due to [IGNITE-9256|https://issues.apache.org/jira/browse/IGNITE-9256] patch,
multiple {{H2ResultSetIterator#onClose}} invocation becomes possible. This can
be considered as a {{Closable}} contract violation and should be fixed.
Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
{{onDone()}} call leads to multiple query finished acks sent back to the
{{MvccCoordinator}} which leads to the problems with the query tracking and
assertion errors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4588: IGNITE-9326 Fixed node failure processor invocati...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4588 ---
Re: How to reduce Scan Query execution time?
Reference: org.apache.ignite.internal.processors.platform.client.cache.ClientCacheScanQueryRequest#process On Thu, Aug 30, 2018 at 11:53 AM Vladimir Ozerov wrote: > Hi Dmitriy, > > Why do you thing that results are not fetched to the client at this point? > We respond to the client with first page. > > On Thu, Aug 23, 2018 at 5:22 PM dmitrievanthony > wrote: > >> I checked and it looks like the result is the same (or even worse, I get >> 1150ms with page size 1000, but the reason might be in other changes, >> previous measures I did using 2.6). >> >> >> >> -- >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >> >
Re: How to reduce Scan Query execution time?
Hi Dmitriy, Why do you thing that results are not fetched to the client at this point? We respond to the client with first page. On Thu, Aug 23, 2018 at 5:22 PM dmitrievanthony wrote: > I checked and it looks like the result is the same (or even worse, I get > 1150ms with page size 1000, but the reason might be in other changes, > previous measures I did using 2.6). > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
[GitHub] ignite pull request #4646: IGNITE-9421: fixed model output
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4646 ---
[jira] [Created] (IGNITE-9429) GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky
Alexey Goncharuk created IGNITE-9429: Summary: GridCacheReplicatedDataStructuresFailoverSelfTest#testAtomicSequenceConstantTopologyChange is flaky Key: IGNITE-9429 URL: https://issues.apache.org/jira/browse/IGNITE-9429 Project: Ignite Issue Type: Test Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Bots on dev list
This is somewhat controversial question. Some people has filters, some doesn't. And it s true that at the moment it is hard to find pieces of human communication in tons of automated e-mails (JIRA, GitHub, TC bot). If to put JIRA and GitHub aside (let's do not mix things), personally content of TC bot looks not very good. I doubt that contributors known how to react to it. If we want contributors to take actions on specific problem, we should send emails directly to them, not to everyone. For me good solution looks as follows: 1) Create separate channel for bot messages 2) "To" field should contain this channel and e-mails of specific people Thoughts? On Thu, Aug 30, 2018 at 10:41 AM Denis Mekhanikov wrote: > I guess, nobody uses it because it's flooded by bots. > It may be useful to lookup old threads for people, who are not subscribed > to the mailing list from the beginning of time. > > Denis > > чт, 30 авг. 2018 г. в 3:39, Dmitriy Setrakyan : > > > Is anyone in the community using or was using Nabble for the dev list > > communication? Personally, I am subscribed to the dev list and use > filters > > in my email client. > > > > D. > > > > On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov > > > wrote: > > > > > Guys, > > > > > > Yep, I use filters on my mail account. But the portal is impossible to > > use. > > > When you subscribe to the dev list for the first time, you don't have > any > > > history on your email, > > > and the archive is polluted with messages, sent by bots. > > > > > > Some view on Nabble, that doesn't contain any automatically generated > > > messages, would help here. > > > > > > Denis > > > > > > ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov : > > > > > > > Modern mail services allow users to filter messages. You can easily > > > filter > > > > out bot messages. > > > > > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > > > > > > > > > Igniters, > > > > > > > > > > We have a lot of threads, created by bots on the dev list. > > > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, > > some > > > > > others too, but these are the most active. > > > > > > > > > > Take a look at this page: > > > > > http://apache-ignite-developers.2346864.n4.nabble. > > > > > com/Apache-Ignite-Developers-f1i35.html > > > > > It's hard to find actual discussions in this mess. I'd like to see > > > > > something like what we have on the users list: > > > > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > > > > > > > It doesn't seem necessary to me to mix discussions with this > cryptic > > > flow > > > > > of information. > > > > > Can we create a separate mailing list for bots? > > > > > > > > > > Denis > > > > > > > > > > > > > > >
Re: Bots on dev list
Huge +1 for separate channel for bots and direct notification. On Thu, Aug 30, 2018 at 12:20 PM Vladimir Ozerov wrote: > This is somewhat controversial question. Some people has filters, some > doesn't. And it s true that at the moment it is hard to find pieces of > human communication in tons of automated e-mails (JIRA, GitHub, TC bot). > If to put JIRA and GitHub aside (let's do not mix things), personally > content of TC bot looks not very good. I doubt that contributors known how > to react to it. If we want contributors to take actions on specific > problem, we should send emails directly to them, not to everyone. > > For me good solution looks as follows: > 1) Create separate channel for bot messages > 2) "To" field should contain this channel and e-mails of specific people > > Thoughts? > > On Thu, Aug 30, 2018 at 10:41 AM Denis Mekhanikov > wrote: > > > I guess, nobody uses it because it's flooded by bots. > > It may be useful to lookup old threads for people, who are not subscribed > > to the mailing list from the beginning of time. > > > > Denis > > > > чт, 30 авг. 2018 г. в 3:39, Dmitriy Setrakyan : > > > > > Is anyone in the community using or was using Nabble for the dev list > > > communication? Personally, I am subscribed to the dev list and use > > filters > > > in my email client. > > > > > > D. > > > > > > On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov < > dmekhani...@gmail.com > > > > > > wrote: > > > > > > > Guys, > > > > > > > > Yep, I use filters on my mail account. But the portal is impossible > to > > > use. > > > > When you subscribe to the dev list for the first time, you don't have > > any > > > > history on your email, > > > > and the archive is polluted with messages, sent by bots. > > > > > > > > Some view on Nabble, that doesn't contain any automatically generated > > > > messages, would help here. > > > > > > > > Denis > > > > > > > > ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov : > > > > > > > > > Modern mail services allow users to filter messages. You can > easily > > > > filter > > > > > out bot messages. > > > > > > > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov >: > > > > > > > > > > > Igniters, > > > > > > > > > > > > We have a lot of threads, created by bots on the dev list. > > > > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. > Maybe, > > > some > > > > > > others too, but these are the most active. > > > > > > > > > > > > Take a look at this page: > > > > > > http://apache-ignite-developers.2346864.n4.nabble. > > > > > > com/Apache-Ignite-Developers-f1i35.html > > > > > > It's hard to find actual discussions in this mess. I'd like to > see > > > > > > something like what we have on the users list: > > > > > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > > > > > > > > > It doesn't seem necessary to me to mix discussions with this > > cryptic > > > > flow > > > > > > of information. > > > > > > Can we create a separate mailing list for bots? > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > -- Best regards, Andrey V. Mashenkov
Re: Bots on dev list
Vladimir, your idea is good, but... 1. Who should be mentioned in messages like PR or JIRA ticket creation? As I see, only these messages clutter up the nabble. 2. MTCGA messages should mention the commiter and authors of the "bad" commit. 2. Comments and changes in PR, tickets, and reviews already are sent to the users, who subscribed to them. 2018-08-30 12:19 GMT+03:00 Vladimir Ozerov : > This is somewhat controversial question. Some people has filters, some > doesn't. And it s true that at the moment it is hard to find pieces of > human communication in tons of automated e-mails (JIRA, GitHub, TC bot). > If to put JIRA and GitHub aside (let's do not mix things), personally > content of TC bot looks not very good. I doubt that contributors known how > to react to it. If we want contributors to take actions on specific > problem, we should send emails directly to them, not to everyone. > > For me good solution looks as follows: > 1) Create separate channel for bot messages > 2) "To" field should contain this channel and e-mails of specific people > > Thoughts? > > On Thu, Aug 30, 2018 at 10:41 AM Denis Mekhanikov > wrote: > > > I guess, nobody uses it because it's flooded by bots. > > It may be useful to lookup old threads for people, who are not subscribed > > to the mailing list from the beginning of time. > > > > Denis > > > > чт, 30 авг. 2018 г. в 3:39, Dmitriy Setrakyan : > > > > > Is anyone in the community using or was using Nabble for the dev list > > > communication? Personally, I am subscribed to the dev list and use > > filters > > > in my email client. > > > > > > D. > > > > > > On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov < > dmekhani...@gmail.com > > > > > > wrote: > > > > > > > Guys, > > > > > > > > Yep, I use filters on my mail account. But the portal is impossible > to > > > use. > > > > When you subscribe to the dev list for the first time, you don't have > > any > > > > history on your email, > > > > and the archive is polluted with messages, sent by bots. > > > > > > > > Some view on Nabble, that doesn't contain any automatically generated > > > > messages, would help here. > > > > > > > > Denis > > > > > > > > ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov : > > > > > > > > > Modern mail services allow users to filter messages. You can > easily > > > > filter > > > > > out bot messages. > > > > > > > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov >: > > > > > > > > > > > Igniters, > > > > > > > > > > > > We have a lot of threads, created by bots on the dev list. > > > > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. > Maybe, > > > some > > > > > > others too, but these are the most active. > > > > > > > > > > > > Take a look at this page: > > > > > > http://apache-ignite-developers.2346864.n4.nabble. > > > > > > com/Apache-Ignite-Developers-f1i35.html > > > > > > It's hard to find actual discussions in this mess. I'd like to > see > > > > > > something like what we have on the users list: > > > > > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > > > > > > > > > It doesn't seem necessary to me to mix discussions with this > > cryptic > > > > flow > > > > > > of information. > > > > > > Can we create a separate mailing list for bots? > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > >
Re: Bots on dev list
> 2. MTCGA messages should mention the commiter and authors of the "bad" commit. But this is not always possible. 2018-08-30 13:04 GMT+03:00 Dmitrii Ryabov : > Vladimir, your idea is good, but... > 1. Who should be mentioned in messages like PR or JIRA ticket creation? As > I see, only these messages clutter up the nabble. > 2. MTCGA messages should mention the commiter and authors of the "bad" > commit. > 2. Comments and changes in PR, tickets, and reviews already are sent to > the users, who subscribed to them. > > 2018-08-30 12:19 GMT+03:00 Vladimir Ozerov : > >> This is somewhat controversial question. Some people has filters, some >> doesn't. And it s true that at the moment it is hard to find pieces of >> human communication in tons of automated e-mails (JIRA, GitHub, TC bot). >> If to put JIRA and GitHub aside (let's do not mix things), personally >> content of TC bot looks not very good. I doubt that contributors known how >> to react to it. If we want contributors to take actions on specific >> problem, we should send emails directly to them, not to everyone. >> >> For me good solution looks as follows: >> 1) Create separate channel for bot messages >> 2) "To" field should contain this channel and e-mails of specific people >> >> Thoughts? >> >> On Thu, Aug 30, 2018 at 10:41 AM Denis Mekhanikov >> wrote: >> >> > I guess, nobody uses it because it's flooded by bots. >> > It may be useful to lookup old threads for people, who are not >> subscribed >> > to the mailing list from the beginning of time. >> > >> > Denis >> > >> > чт, 30 авг. 2018 г. в 3:39, Dmitriy Setrakyan : >> > >> > > Is anyone in the community using or was using Nabble for the dev list >> > > communication? Personally, I am subscribed to the dev list and use >> > filters >> > > in my email client. >> > > >> > > D. >> > > >> > > On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov < >> dmekhani...@gmail.com >> > > >> > > wrote: >> > > >> > > > Guys, >> > > > >> > > > Yep, I use filters on my mail account. But the portal is impossible >> to >> > > use. >> > > > When you subscribe to the dev list for the first time, you don't >> have >> > any >> > > > history on your email, >> > > > and the archive is polluted with messages, sent by bots. >> > > > >> > > > Some view on Nabble, that doesn't contain any automatically >> generated >> > > > messages, would help here. >> > > > >> > > > Denis >> > > > >> > > > ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov > >: >> > > > >> > > > > Modern mail services allow users to filter messages. You can >> easily >> > > > filter >> > > > > out bot messages. >> > > > > >> > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov < >> dmekhani...@gmail.com>: >> > > > > >> > > > > > Igniters, >> > > > > > >> > > > > > We have a lot of threads, created by bots on the dev list. >> > > > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. >> Maybe, >> > > some >> > > > > > others too, but these are the most active. >> > > > > > >> > > > > > Take a look at this page: >> > > > > > http://apache-ignite-developers.2346864.n4.nabble. >> > > > > > com/Apache-Ignite-Developers-f1i35.html >> > > > > > It's hard to find actual discussions in this mess. I'd like to >> see >> > > > > > something like what we have on the users list: >> > > > > > http://apache-ignite-users.70518.x6.nabble.com/ >> > > > > > >> > > > > > It doesn't seem necessary to me to mix discussions with this >> > cryptic >> > > > flow >> > > > > > of information. >> > > > > > Can we create a separate mailing list for bots? >> > > > > > >> > > > > > Denis >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
[jira] [Created] (IGNITE-9430) Add ability to override all caches's "rebalanceThrottle" option via JVM node option
ARomantsov created IGNITE-9430: -- Summary: Add ability to override all caches's "rebalanceThrottle" option via JVM node option Key: IGNITE-9430 URL: https://issues.apache.org/jira/browse/IGNITE-9430 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.5 Reporter: ARomantsov Fix For: 2.7 I found ability to set rebalanceThrottle option for any cache , but can we have JVM key for override that parameter for all cache at once -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Bots on dev list
Hi everyone, I think email from the bot is something exceptional. In this case author and committer already ignored test failures. So dev list is the last hope that someone can come and fix the failure. Other emails come from human actions, so I'm happy that so many actions occur in the community. I never name it pollution. Other Apache projects forward every comment in every PR to dev lists. So Ignite notifications are rare. Sincerely Dmitriy Pavlov чт, 30 авг. 2018 г., 13:06 Dmitrii Ryabov : > > 2. MTCGA messages should mention the commiter and authors of the "bad" > commit. > But this is not always possible. > > 2018-08-30 13:04 GMT+03:00 Dmitrii Ryabov : > > > Vladimir, your idea is good, but... > > 1. Who should be mentioned in messages like PR or JIRA ticket creation? > As > > I see, only these messages clutter up the nabble. > > 2. MTCGA messages should mention the commiter and authors of the "bad" > > commit. > > 2. Comments and changes in PR, tickets, and reviews already are sent to > > the users, who subscribed to them. > > > > 2018-08-30 12:19 GMT+03:00 Vladimir Ozerov : > > > >> This is somewhat controversial question. Some people has filters, some > >> doesn't. And it s true that at the moment it is hard to find pieces of > >> human communication in tons of automated e-mails (JIRA, GitHub, TC bot). > >> If to put JIRA and GitHub aside (let's do not mix things), personally > >> content of TC bot looks not very good. I doubt that contributors known > how > >> to react to it. If we want contributors to take actions on specific > >> problem, we should send emails directly to them, not to everyone. > >> > >> For me good solution looks as follows: > >> 1) Create separate channel for bot messages > >> 2) "To" field should contain this channel and e-mails of specific people > >> > >> Thoughts? > >> > >> On Thu, Aug 30, 2018 at 10:41 AM Denis Mekhanikov < > dmekhani...@gmail.com> > >> wrote: > >> > >> > I guess, nobody uses it because it's flooded by bots. > >> > It may be useful to lookup old threads for people, who are not > >> subscribed > >> > to the mailing list from the beginning of time. > >> > > >> > Denis > >> > > >> > чт, 30 авг. 2018 г. в 3:39, Dmitriy Setrakyan >: > >> > > >> > > Is anyone in the community using or was using Nabble for the dev > list > >> > > communication? Personally, I am subscribed to the dev list and use > >> > filters > >> > > in my email client. > >> > > > >> > > D. > >> > > > >> > > On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov < > >> dmekhani...@gmail.com > >> > > > >> > > wrote: > >> > > > >> > > > Guys, > >> > > > > >> > > > Yep, I use filters on my mail account. But the portal is > impossible > >> to > >> > > use. > >> > > > When you subscribe to the dev list for the first time, you don't > >> have > >> > any > >> > > > history on your email, > >> > > > and the archive is polluted with messages, sent by bots. > >> > > > > >> > > > Some view on Nabble, that doesn't contain any automatically > >> generated > >> > > > messages, would help here. > >> > > > > >> > > > Denis > >> > > > > >> > > > ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov < > somefire...@gmail.com > >> >: > >> > > > > >> > > > > Modern mail services allow users to filter messages. You can > >> easily > >> > > > filter > >> > > > > out bot messages. > >> > > > > > >> > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov < > >> dmekhani...@gmail.com>: > >> > > > > > >> > > > > > Igniters, > >> > > > > > > >> > > > > > We have a lot of threads, created by bots on the dev list. > >> > > > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. > >> Maybe, > >> > > some > >> > > > > > others too, but these are the most active. > >> > > > > > > >> > > > > > Take a look at this page: > >> > > > > > http://apache-ignite-developers.2346864.n4.nabble. > >> > > > > > com/Apache-Ignite-Developers-f1i35.html > >> > > > > > It's hard to find actual discussions in this mess. I'd like to > >> see > >> > > > > > something like what we have on the users list: > >> > > > > > http://apache-ignite-users.70518.x6.nabble.com/ > >> > > > > > > >> > > > > > It doesn't seem necessary to me to mix discussions with this > >> > cryptic > >> > > > flow > >> > > > > > of information. > >> > > > > > Can we create a separate mailing list for bots? > >> > > > > > > >> > > > > > Denis > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > > >
[jira] [Created] (IGNITE-9431) Documentation for zk paths used by ZookeeperDiscovery.
Stanilovsky Evgeny created IGNITE-9431: -- Summary: Documentation for zk paths used by ZookeeperDiscovery. Key: IGNITE-9431 URL: https://issues.apache.org/jira/browse/IGNITE-9431 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.6 Reporter: Stanilovsky Evgeny Assignee: Artem Budnikov I found that under /apacheIgnite zk directory, there are also: /jd, /ce, /cp, /ca and some other dirs, from source i found that they take place from : org.apache.ignite.spi.discovery.zk.internal.ZkIgnitePaths. Plz document this paths purpose. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: New PMC member: Dmitriy Pavlov
Dmitry, My congratulations! Thank you for guiding and helping the community members and me, in particular, to follow the Apache Way principles and also for your contribution. On Wed, 29 Aug 2018 at 22:31 Denis Magda wrote: > The Project Management Committee (PMC) for Apache Ignite > has invited Dmitriy Pavlov to become a PMC member and we are pleased > to announce that he has accepted. > > Being a PMC member enables assistance with the management > and to guide the direction of the project. > > Congratulations Dmitriy! Keep contributing to Ignite success the way you do > ;) > > Denis > -- -- Maxim Muzafarov
Re: Binary Client Protocol client hangs in case of OOM on server
BTW, Taras has created the ticket https://issues.apache.org/jira/browse/IGNITE-9379. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Service Grid new design overview
Hi Igniters! I had a private talk about new Service Grid design with: Alexey Goncharuk, Vladimir Ozerov, Denis Mekhanikov, Nikolay Izhikov, Anton Vinogradov and I'd like to share results. Design looks good in general, but we have decided to improve the unified flow of requests processing as follows - when any node received request on deploying, a node should calculate assignments yourself and deploys it if needed, then sends the result to the coordinator instead of waiting for assignments from the coordinator. For this change, we should make our service's assignments function *determined*, that means the function will return the same results for the same arguments at any node. We all agreed with this change because it allows us to reduce messages for handling each request and making the solution more flexible. On Tue, Aug 28, 2018 at 12:26 AM Dmitriy Setrakyan wrote: > > Agree with Val. I think all users would expect that a service is restarted > upon a node or cluster restart. Let's make sure we preserve this behavior. > > D. > > On Fri, Aug 24, 2018 at 4:17 PM, Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Guys, > > > > I believe we should preserve the behavior that we have now. What happens to > > services if we restart a persistent cluster running 2.6? Are services > > recreated or not? If YES, we should make sure the same happens after > > redesign. Would be even better if we preserve compatibility, i.e. allow > > seamless upgrade from older version that uses system cache to newer version > > that uses disco messages for service deployment. If NO, it's much easier > > and we can leave it as is for now. However, eventually would be great to > > have an option to persist services and redeploy them after cluster restart. > > > > -Val > > > > On Fri, Aug 24, 2018 at 2:51 PM Dmitriy Pavlov > > wrote: > > > > > Denis M. & Val please share your vision about this topic. > > > > > > пт, 24 авг. 2018 г. в 15:52, Vyacheslav Daradur : > > > > > > > Nick, Antron, thank you for stepping in. > > > > > > > > AFAIK, Ignite cluster can move its state to a new version of Ignite > > > > using persistence only. > > > > > > > > Since Ignite v.2.3 persistence is configured on a memory region and > > > > system memory region is not persistence, that means the system > > > > (utility) cache will not be recovered on cluster restart. > > > > > > > > Here is a ticket which describes the same issue: > > > > https://issues.apache.org/jira/browse/IGNITE-6629 > > > > > > > > > BTW, Is proposed solution provides the guarantee that services will > > be > > > > > redeployed after each cluster restart since now we're not using the > > > > cache? > > > > > > > > No, only services described in IgniteConfiguration will be deployed at > > > > node startup as well as now. > > > > > > > > Am I wrong in something? > > > > On Thu, Aug 23, 2018 at 5:59 PM Anton Vinogradov > > wrote: > > > > > > > > > > Vyacheslav. > > > > > > > > > > It looks like we able to restart all services on grid startup from > > old > > > > > definitions (inside cache) in case persistence turned on. > > > > > Se no problems to provide such automated migration case. > > > > > Also, we can test it using compatibility framework. > > > > > > > > > > BTW, Is proposed solution provides the guarantee that services will > > be > > > > > redeployed after each cluster restart since now we're not using the > > > > cache? > > > > > > > > > > чт, 23 авг. 2018 г. в 15:21, Nikolay Izhikov : > > > > > > > > > > > Hello, Vyacheslav. > > > > > > > > > > > > Thanks, for sharing your design. > > > > > > > > > > > > > I have a question about services migration from AI 2.6 to a new > > > > solution > > > > > > > > > > > > Can you describe consequences of not having migration solution? > > > > > > What will happen on the user side? > > > > > > > > > > > > > > > > > > В Чт, 23/08/2018 в 14:44 +0300, Vyacheslav Daradur пишет: > > > > > > > Hi, Igniters! > > > > > > > > > > > > > > I’m working on Service Grid redesign tasks and design seems to be > > > > > > finished. > > > > > > > > > > > > > > The main goal of Service Grid redesign is to provide missed > > > > guarantees: > > > > > > > - Synchronous services deployment/undeployment; > > > > > > > - Failover on coordinator change; > > > > > > > - Propagation of deployments errors across the cluster; > > > > > > > - Introduce of a deployment failures policy; > > > > > > > - Prevention of deployments initiators hangs while deployment; > > > > > > > - etc. > > > > > > > > > > > > > > I’d like to ask the community their thoughts about the proposed > > > > design > > > > > > > to be sure that all important things have been considered. > > > > > > > > > > > > > > Also, I have a question about services migration from AI 2.6 to a > > > new > > > > > > > solution. It’s very hard to provide tools for users migration, > > > > because > > > > > > > of significant changes. We don’t use utility cache anymore. > > Should > > > we
[jira] [Created] (IGNITE-9432) Investigate ability to make ScanQuery faster
Anton Dmitriev created IGNITE-9432:
--
Summary: Investigate ability to make ScanQuery faster
Key: IGNITE-9432
URL: https://issues.apache.org/jira/browse/IGNITE-9432
Project: Ignite
Issue Type: Improvement
Components: ml
Affects Versions: 2.7
Reporter: Anton Dmitriev
Fix For: 2.7
When we make ScanQuery via Binary Client Protocol it works very slowly in case
we need to retrieve a big amount of objects (all objects in our case). The most
slower part is a waiting for response from Apache Ignite. This also mentioned
on devlist
[http://apache-ignite-developers.2346864.n4.nabble.com/How-to-reduce-Scan-Query-execution-time-td34212.html].
To reproduce the problem we've prepared a small example:
[slow-scan-query-reproducer|https://github.com/dmitrievanthony/slow-scan-query-reproducer].
In this example we creates a cache with 500 objects 1Mb each (on localhost),
we make ScanQuery with different page sizes and calculate time between the
moment when the request has been sent and the moment when the response is ready
to be receive. The measurements are here:
{{Page size 5 Mb, waiting time 119.85 ± 6.72 ms}}
{{ Page size 10 Mb, waiting time 157.70 ± 15.35 ms}}
{{ Page size 20 Mb, waiting time 204.50 ± 19.18 ms}}
{{ Page size 50 Mb, waiting time 264.70 ± 22.30 ms}}
{{ Page size 100 Mb, waiting time 463.35 ± 17.12 ms}}
{{ Page size 150 Mb, waiting time 672.50 ± 21.98 ms}}
As result we spend ~4ms per every megabyte on _something_. It means that we
will be able to achieve 250Mb/s throughput in best case. It's too slow, isn't
it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: How to reduce Scan Query execution time?
Hi, I prepared an example that reproduces what I'm talking about. Please take a look: https://github.com/dmitrievanthony/slow-scan-query-reproducer/blob/master/src/main/java/Client.java. I calculate time between the has been sent and the result is ready to be received (not fully received). And I use localhost as well. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
MVCC and transactional SQL is merged to master
Igniters, I am glad to announce that we finally merged MVCC and transactional SQL support to master branch. This long journey started more than a year ago with multiple design brainstorm sessions, conducted by Apache Ignite fellows - Semen Boikov, Alexey Goncharuk, Sergi Vladykin. As things had became more clear, we gradually switched to active development phase in November 2017. Since then we implemented new transactional model based on multi-version approach and snapshot isolation, and almost fully reworked SQL engine to support transactions. But this is not the end of the story. In Apache Ignite 2.7 we expect to release transactional SQL as "release candidate". To achieve this we still need to implement a number of things, such as new transactional protocol for key-value API, historical rebalance, continuous queries. Between AI 2.7 and AI 2.8 we will work on several not-yet-supported cache operations, and also will focus on performance and stability. I would like to thank all community members, who worked hard to make MVCC happen: Igor Seliverstov, Alexander Paschenko, Sergey Kalashnikov, igor Sapego, Roman Kondakov, Pavel Kuznetsov, Ivan Pavlukihn, Andrey Mashenkov, and many other contributors who helped us with design, testing and benchmarking. Release notes and documentation will be prepared by AI 2.7 release. Please feel free to ask any questions about the feature here. Vladimir.
Re: How to reduce Scan Query execution time?
I am not sure what is the purpose of measuring receive time of the first byte. Please try to measure time of getting the first page, or the whole result set you are interested in. The main purpose of page size is to better utilize network and decrease number of request responses. If you are interested in getting the very first result ASAP, then it is better to keep page size small. But if the goal is to get all results ASAP, then greater page size will help. After some threshold greater page size will not provide benefits and may even make performance worse. So it is better to experiment with different pages size to find optimal value. On Thu, Aug 30, 2018 at 3:14 PM dmitrievanthony wrote: > Hi, > > I prepared an example that reproduces what I'm talking about. Please take a > look: > > https://github.com/dmitrievanthony/slow-scan-query-reproducer/blob/master/src/main/java/Client.java > . > > I calculate time between the has been sent and the result is ready to be > received (not fully received). And I use localhost as well. > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
Re: MVCC and transactional SQL is merged to master
Great news, Vladimir! Congratulations! --Yakov 2018-08-30 15:15 GMT+03:00 Vladimir Ozerov : > Igniters, > > I am glad to announce that we finally merged MVCC and transactional SQL > support to master branch. > > This long journey started more than a year ago with multiple design > brainstorm sessions, conducted by Apache Ignite fellows - Semen Boikov, > Alexey Goncharuk, Sergi Vladykin. > > As things had became more clear, we gradually switched to active > development phase in November 2017. Since then we implemented new > transactional model based on multi-version approach and snapshot isolation, > and almost fully reworked SQL engine to support transactions. > > But this is not the end of the story. In Apache Ignite 2.7 we expect to > release transactional SQL as "release candidate". To achieve this we still > need to implement a number of things, such as new transactional protocol > for key-value API, historical rebalance, continuous queries. Between AI 2.7 > and AI 2.8 we will work on several not-yet-supported cache operations, and > also will focus on performance and stability. > > I would like to thank all community members, who worked hard to make MVCC > happen: Igor Seliverstov, Alexander Paschenko, Sergey Kalashnikov, igor > Sapego, Roman Kondakov, Pavel Kuznetsov, Ivan Pavlukihn, Andrey Mashenkov, > and many other contributors who helped us with design, testing and > benchmarking. > > Release notes and documentation will be prepared by AI 2.7 release. > > Please feel free to ask any questions about the feature here. > > Vladimir. >
[GitHub] ignite pull request #3220: IGNITE-4191
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3220 ---
[GitHub] ignite pull request #3559: IGNITE-6552 ability to set WAL history size in MB...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3559 ---
Re: Apache Ignite 2.7 release
Hi Igniters! I'm working on the following Service Grid tasks: - IGNITE-8361 Use discovery messages for service deployment - IGNITE-8362 Collect service deployment results asynchronously on coordinator - IGNITE-8363 Handle topology changes during service deployment - IGNITE-8364 Propagate deployed services to joining nodes - IGNITE-8365 Introduce service failure events - IGNITE-3392 Propagate service deployment results from assigned nodes to initiator Let's call them *phase 1* because the should be implemented together (atomically). I do my best to finish phase 1 for including to 2.7 release. But I'm not sure that the solution will be fully completed till the beginning of October. On Wed, Aug 29, 2018 at 7:18 PM Nikolay Izhikov wrote: > > Hell, Yakov > > I'm ok with your proposal. > > * Scope freeze - September 17 - We should have a full list of tickets > for 2.7 here. > * Code freeze - October 01 - We should merge all 2.7 tickets to > master here. > * Vote on RC1 - October 11. > * Vote on release - October 15. > > В Ср, 29/08/2018 в 12:39 +0300, Yakov Zhdanov пишет: > > Nikolay, > > > > I think we should have 2 weeks after code freeze which by the way may > > include RC1 voting stage. This way I would like us to agree that release > > candidate should be sent to vote on Oct, 11th and we can release on Oct, > > 15th. > > > > What do you think? > > > > --Yakov -- Best Regards, Vyacheslav D.
Re: How to reduce Scan Query execution time?
I have already experimented with different page sizes and found out that "downloading" time is relatively small compare to this "waiting" time, so I've decided that this "waiting" is bottleneck and that's why I'm talking about it and measuring it. In case of AWS 10Gbit network allows us to receive page content with throughput ~1.2Gb/s (I've checked it and it's true), but "waiting" step works slower and it's a problem. You suggested to use greater page size for my purpose (maximal throughput, all results), so: Page size: 200Mb Waiting time: 800ms Downloading time: 160ms -- Total time: 960ms Throughput: 200Mb/s -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: How to reduce Scan Query execution time?
BTW, measurements for the example I've been talking above: Page size 5 Mb, waiting time 119.85 ± 6.72 ms Page size 10 Mb, waiting time 157.70 ± 15.35 ms Page size 20 Mb, waiting time 204.50 ± 19.18 ms Page size 50 Mb, waiting time 264.70 ± 22.30 ms Page size 100 Mb, waiting time 463.35 ± 17.12 ms Page size 150 Mb, waiting time 672.50 ± 21.98 ms -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-9433) Refactoring to improve constant usage for file suffixes
Pavel Voronkin created IGNITE-9433: -- Summary: Refactoring to improve constant usage for file suffixes Key: IGNITE-9433 URL: https://issues.apache.org/jira/browse/IGNITE-9433 Project: Ignite Issue Type: Task Reporter: Pavel Voronkin Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Hello ignite team, IGNITE-9433 contribution
Hi Team, I'd like to join to Apache Ignite development. Especially to the ML part. Currently, I work on IGNITE-9433 https://issues.apache.org/jira/browse/IGNITE-9433 My Jira login is voropava Best regards, Pavel
[GitHub] ignite pull request #4651: IGNITE-9433 Extractted zip suffix constant
GitHub user voropava opened a pull request: https://github.com/apache/ignite/pull/4651 IGNITE-9433 Extractted zip suffix constant You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9433 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4651.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4651 commit a7999cb5646716cd662f21c125df9af68558fddf Author: Pavel Voronkin Date: 2018-08-30T13:37:18Z IGNITE-9433 Extractted zip suffix constant ---
[jira] [Created] (IGNITE-9434) Create suites for MVCC tests.
Andrew Mashenkov created IGNITE-9434: Summary: Create suites for MVCC tests. Key: IGNITE-9434 URL: https://issues.apache.org/jira/browse/IGNITE-9434 Project: Ignite Issue Type: Task Components: mvcc Reporter: Andrew Mashenkov Fix For: 2.7 MVCC tests suites should be created on Ignite TeamCity. * org.apache.ignite.testsuites;.MvccQueryTrackerImpl * org.apache.ignite.jdbc.suite.IgniteJdbcDriverMvccTestSuite * org.apache.ignite.testsuites.IgniteCacheMvccTestSuite "MVCC Run All" should be created as well to run mvcc tests only. Mvcc tests should be added to "Run All" as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4651: IGNITE-9433 Extractted zip suffix constant
Github user voropava closed the pull request at: https://github.com/apache/ignite/pull/4651 ---
[GitHub] ignite pull request #4562: IGNITE-9302 Java Thin Clients TC configuration ha...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4562 ---
Re: How to reduce Scan Query execution time?
Anton, I still struggle to understand the problem. Delay in getting the first page is not a problem on its own. But it might be a problem for your use case. My question is - what is the use case and what is your goal? Minimal latency? Maximal throughout? Getting the first result ASAP? Getting all results ASAP? чт, 30 авг. 2018 г. в 15:43, dmitrievanthony : > BTW, measurements for the example I've been talking above: > > Page size 5 Mb, waiting time 119.85 ± 6.72 ms > Page size 10 Mb, waiting time 157.70 ± 15.35 ms > Page size 20 Mb, waiting time 204.50 ± 19.18 ms > Page size 50 Mb, waiting time 264.70 ± 22.30 ms > Page size 100 Mb, waiting time 463.35 ± 17.12 ms > Page size 150 Mb, waiting time 672.50 ± 21.98 ms > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
[GitHub] ignite pull request #4652: IGNITE-9433 Extracted zip suffix constant
GitHub user voropava opened a pull request: https://github.com/apache/ignite/pull/4652 IGNITE-9433 Extracted zip suffix constant You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9433 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4652.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4652 commit 466f485f0c030f542dac5ac34fc10f543d924ec0 Author: Pavel Voronkin Date: 2018-08-30T14:11:38Z IGNITE-9433 Extracted zip suffix constant ---
[jira] [Created] (IGNITE-9435) Document MVCC
Vladimir Ozerov created IGNITE-9435: --- Summary: Document MVCC Key: IGNITE-9435 URL: https://issues.apache.org/jira/browse/IGNITE-9435 Project: Ignite Issue Type: Task Components: documentation, mvcc Reporter: Vladimir Ozerov Fix For: 2.7 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: How to reduce Scan Query execution time?
To be precise it's not only about first page, it's about getting next pages as well. Regarding use case, in my client application I need to iterate over the dataset stored in Apache Ignite as fast as it possible. It means I should provide maximal throughput for simple "read all" operation. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: How to reduce Scan Query execution time?
In this case I would not advise to measure how long does it take to get the first byte. We may set page size to 1 and get that byte very quickly, but it doesn't help you to iterate over all results quickly. Correct measurement here would be to calculate total iteration time. Provided that object size is pretty big, I think optimal page size might be pretty small. At this moment thin client SCAN implementation is really straightforward - just request-response for every page. To get peak throughput it is better to rewrite it to streaming approach, when server constantly pushes data to the client. Also compression may help in your case (trade CPU to network). But this is only ideas which are yet to be implemented in the product. Also you may want to look at "partition" and "filter" parameters of ScanQuery. With partition it is possible to start scanning in several threads. With filter it is possible to pass less data over wire. Vladimir. On Thu, Aug 30, 2018 at 5:40 PM dmitrievanthony wrote: > To be precise it's not only about first page, it's about getting next pages > as well. > > Regarding use case, in my client application I need to iterate over the > dataset stored in Apache Ignite as fast as it possible. It means I should > provide maximal throughput for simple "read all" operation. > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
[GitHub] ignite pull request #4653: Fixed Ignite Kafka Source Connector immediately e...
GitHub user kukushal opened a pull request: https://github.com/apache/ignite/pull/4653 Fixed Ignite Kafka Source Connector immediately existing You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite kafka-source-connector-stops Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4653.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4653 commit ceaf22f264d2da285ceed9b83318263ab49e1011 Author: kukushal Date: 2018-08-30T14:58:21Z Fixed Ignite Kafka Source Connector immediately existing ---
Re: How to reduce Scan Query execution time?
Yes, of course I started with measuring of total iteration time. After that I found that throughput is about 200Mb/s, then I started looking for a bottleneck. Because "downloading" time is less than "waiting" time I conclude that "waiting" step is bottleneck and so that this thread has been started. Regarding your suggestions, yes, streaming approach probably will help us. At the same time, I don't think that compression will help because as I've already told it looks like the bottleneck on Apache Ignite side, not in network transfer itself. I can't use "filter" because I need all data. Regarding the "partition" parameter, do I understand correctly that it means number of cache partition to be fetched? In this case don't understand how it affects "scanning in several threads". -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-9436) Compute task may cause a deadlock on node stop.
Andrew Mashenkov created IGNITE-9436: Summary: Compute task may cause a deadlock on node stop. Key: IGNITE-9436 URL: https://issues.apache.org/jira/browse/IGNITE-9436 Project: Ignite Issue Type: Bug Components: compute Reporter: Andrew Mashenkov Task that is waiting for async compute call result on reduce may lead to deadlock on node stop. This task will hold GridTaskProcessor.readlock and waits for remote call result on future. At that time node stopping thread will try to acquire GridTaskProcessor.writeLock. GridTaskProcessor job message listener will try to acquire GridTaskProcessor.readLock with no success. So, grid can't be stopped as there is a task on fly, but remote call result also can't be delivered to task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4653: Fixed Ignite Kafka Source Connector immediately e...
Github user kukushal closed the pull request at: https://github.com/apache/ignite/pull/4653 ---
[GitHub] ignite pull request #4654: IGNITE-8149: MVCC TX: Size method should use tx s...
GitHub user pavlukhin opened a pull request: https://github.com/apache/ignite/pull/4654 IGNITE-8149: MVCC TX: Size method should use tx snapshot You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8149 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4654.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4654 commit b5ea6e1b5b072995f8e97a19183ebebfbae6cf20 Author: ipavlukhin Date: 2018-08-30T16:00:08Z IGNITE-8149 Cache.size is updated on MVCC transaction commit ---
[GitHub] ignite pull request #4631: Ignite-8149-2-merged-tc
Github user pavlukhin closed the pull request at: https://github.com/apache/ignite/pull/4631 ---
[GitHub] ignite pull request #4622: Ignite-8149-tc
Github user pavlukhin closed the pull request at: https://github.com/apache/ignite/pull/4622 ---
[GitHub] ignite pull request #4606: Ignite 2.4.8 p2
Github user alamar closed the pull request at: https://github.com/apache/ignite/pull/4606 ---
[GitHub] ignite pull request #4612: IGNITE-9237: Random forest optimization
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4612 ---
Re: MVCC and transactional SQL is merged to master
Very nice! Looking forward to seeing this functionality in 2.7 release. On Thu, Aug 30, 2018 at 5:22 AM, Yakov Zhdanov wrote: > Great news, Vladimir! Congratulations! > > --Yakov > > 2018-08-30 15:15 GMT+03:00 Vladimir Ozerov : > > > Igniters, > > > > I am glad to announce that we finally merged MVCC and transactional SQL > > support to master branch. > > > > This long journey started more than a year ago with multiple design > > brainstorm sessions, conducted by Apache Ignite fellows - Semen Boikov, > > Alexey Goncharuk, Sergi Vladykin. > > > > As things had became more clear, we gradually switched to active > > development phase in November 2017. Since then we implemented new > > transactional model based on multi-version approach and snapshot > isolation, > > and almost fully reworked SQL engine to support transactions. > > > > But this is not the end of the story. In Apache Ignite 2.7 we expect to > > release transactional SQL as "release candidate". To achieve this we > still > > need to implement a number of things, such as new transactional protocol > > for key-value API, historical rebalance, continuous queries. Between AI > 2.7 > > and AI 2.8 we will work on several not-yet-supported cache operations, > and > > also will focus on performance and stability. > > > > I would like to thank all community members, who worked hard to make MVCC > > happen: Igor Seliverstov, Alexander Paschenko, Sergey Kalashnikov, igor > > Sapego, Roman Kondakov, Pavel Kuznetsov, Ivan Pavlukihn, Andrey > Mashenkov, > > and many other contributors who helped us with design, testing and > > benchmarking. > > > > Release notes and documentation will be prepared by AI 2.7 release. > > > > Please feel free to ask any questions about the feature here. > > > > Vladimir. > > >
[GitHub] ignite pull request #4655: INGITE-9285 Add MaxAbs scaler
GitHub user dehasi opened a pull request: https://github.com/apache/ignite/pull/4655 INGITE-9285 Add MaxAbs scaler You can merge this pull request into a Git repository by running: $ git pull https://github.com/dehasi/ignite feature/IGNITE-9285-add-abs-max-scaler Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4655.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4655 commit 6d78bb3678e320ebc1cc06be8134056ae6d0fd77 Author: Ravil Galeyev Date: 2018-08-22T09:45:34Z IGNITE-9285: Add Abs Max scaler partition data commit 9b612252fe5ff16179c5230fe170ee61a7df94a0 Author: Ravil Galeyev Date: 2018-08-22T09:57:38Z IGNITE-9285: Add MaxAbsScalerPreprocessor commit c16a7166e97641c0827136c8ffa70a0dd7b554f7 Author: Ravil Galeyev Date: 2018-08-22T09:59:40Z IGNITE-9285: Add package info commit 242a97ccf92c3814a3aa3871c36b7719465d2e18 Author: Ravil Galeyev Date: 2018-08-22T10:27:25Z IGNITE-9285: Add max abs trainer skeleton commit e9bb645337bc737a80101263952ed7e892f6bfa0 Author: dehasi Date: 2018-08-22T10:41:46Z IGNITE-9285: Add test template commit 173a197ecca3f6a52ef30325590c485d703eb0db Author: dehasi Date: 2018-08-22T15:31:04Z IGNITE-9285: Rename trainer commit 4ece7db930fae7f7113b90ea599228617742e261 Author: dehasi Date: 2018-08-22T15:32:10Z IGNITE-9285: Remove unused imports commit 5a0bd64b4204e3a96884ec71752b8351a98e71d2 Author: dehasi Date: 2018-08-23T12:57:53Z IGNITE-9285: Add max abs scaler test commit 4f4eb7fae6ceadebf6dcc54b7ee747e00a6dbf90 Author: dehasi Date: 2018-08-23T13:00:23Z IGNITE-9285: Add max abs trainer test template commit 05ae008f49558661d0dbdb05c6dab8259c80d787 Author: dehasi Date: 2018-08-23T13:05:28Z IGNITE-9285: Implement max abs trainer commit e762382a9dc223aeb5ecc212d1e412e8a2d2cf56 Author: dehasi Date: 2018-08-23T13:50:35Z IGNITE-9285: Add max abs example commit fc822f4a4ce2d8e5a5fdba2c073ba0ac98f2c7cf Author: dehasi Date: 2018-08-24T19:51:23Z IGNITE-9285: Fix javadoc commit a1a80d7fb812f0d67a4a99416fee029e35ff0232 Author: dehasi Date: 2018-08-24T19:53:22Z IGNITE-9285: Fix copypaste commit 118f8aca74c0c4627fb0f0ea33ede94978986067 Author: dehasi Date: 2018-08-24T20:28:41Z IGNITE-9285: Update package info commit 53c0398126adb1bd8ce84abe2415ab660e96e820 Author: dehasi Date: 2018-08-24T20:41:32Z IGNITE-9285: Update test data commit e5df172caf10e8a9eaecba79ebc34395a09ead47 Author: dehasi Date: 2018-08-24T20:42:21Z IGNITE-9285: Remove commented code commit 8c2b57d944c62fea0e532e5e3d3cc5fc97508d5c Author: dehasi Date: 2018-08-29T22:00:12Z Merge branch 'master' of https://github.com/apache/ignite into feature/IGNITE-9285-add-abs-max-scaler commit e9abcd768aaa65c46a8828da5394bc8abbfac0c2 Author: dehasi Date: 2018-08-30T13:28:10Z IGNITE-9285: Fix formatting commit e50c5f64d54877d2ee9a9a009a788926d78b3f5c Author: dehasi Date: 2018-08-30T14:37:53Z Merge branch 'master' of https://github.com/apache/ignite into feature/IGNITE-9285-add-abs-max-scaler ---
Re: Service Grid new design overview
I also hope that we have some batching API to allow deployment of multiple services together, either on grid startup or during the call to "deploy..." API. D. On Thu, Aug 30, 2018 at 5:04 AM, Vyacheslav Daradur wrote: > Hi Igniters! > > I had a private talk about new Service Grid design with: Alexey > Goncharuk, Vladimir Ozerov, Denis Mekhanikov, Nikolay Izhikov, Anton > Vinogradov and I'd like to share results. > > Design looks good in general, but we have decided to improve the > unified flow of requests processing as follows - when any node > received request on deploying, a node should calculate assignments > yourself and deploys it if needed, then sends the result to the > coordinator instead of waiting for assignments from the coordinator. > > For this change, we should make our service's assignments function > *determined*, that means the function will return the same results for > the same arguments at any node. > > We all agreed with this change because it allows us to reduce messages > for handling each request and making the solution more flexible. > > On Tue, Aug 28, 2018 at 12:26 AM Dmitriy Setrakyan > wrote: > > > > Agree with Val. I think all users would expect that a service is > restarted > > upon a node or cluster restart. Let's make sure we preserve this > behavior. > > > > D. > > > > On Fri, Aug 24, 2018 at 4:17 PM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Guys, > > > > > > I believe we should preserve the behavior that we have now. What > happens to > > > services if we restart a persistent cluster running 2.6? Are services > > > recreated or not? If YES, we should make sure the same happens after > > > redesign. Would be even better if we preserve compatibility, i.e. allow > > > seamless upgrade from older version that uses system cache to newer > version > > > that uses disco messages for service deployment. If NO, it's much > easier > > > and we can leave it as is for now. However, eventually would be great > to > > > have an option to persist services and redeploy them after cluster > restart. > > > > > > -Val > > > > > > On Fri, Aug 24, 2018 at 2:51 PM Dmitriy Pavlov > > > wrote: > > > > > > > Denis M. & Val please share your vision about this topic. > > > > > > > > пт, 24 авг. 2018 г. в 15:52, Vyacheslav Daradur >: > > > > > > > > > Nick, Antron, thank you for stepping in. > > > > > > > > > > AFAIK, Ignite cluster can move its state to a new version of Ignite > > > > > using persistence only. > > > > > > > > > > Since Ignite v.2.3 persistence is configured on a memory region and > > > > > system memory region is not persistence, that means the system > > > > > (utility) cache will not be recovered on cluster restart. > > > > > > > > > > Here is a ticket which describes the same issue: > > > > > https://issues.apache.org/jira/browse/IGNITE-6629 > > > > > > > > > > > BTW, Is proposed solution provides the guarantee that services > will > > > be > > > > > > redeployed after each cluster restart since now we're not using > the > > > > > cache? > > > > > > > > > > No, only services described in IgniteConfiguration will be > deployed at > > > > > node startup as well as now. > > > > > > > > > > Am I wrong in something? > > > > > On Thu, Aug 23, 2018 at 5:59 PM Anton Vinogradov > > > wrote: > > > > > > > > > > > > Vyacheslav. > > > > > > > > > > > > It looks like we able to restart all services on grid startup > from > > > old > > > > > > definitions (inside cache) in case persistence turned on. > > > > > > Se no problems to provide such automated migration case. > > > > > > Also, we can test it using compatibility framework. > > > > > > > > > > > > BTW, Is proposed solution provides the guarantee that services > will > > > be > > > > > > redeployed after each cluster restart since now we're not using > the > > > > > cache? > > > > > > > > > > > > чт, 23 авг. 2018 г. в 15:21, Nikolay Izhikov < > nizhi...@apache.org>: > > > > > > > > > > > > > Hello, Vyacheslav. > > > > > > > > > > > > > > Thanks, for sharing your design. > > > > > > > > > > > > > > > I have a question about services migration from AI 2.6 to a > new > > > > > solution > > > > > > > > > > > > > > Can you describe consequences of not having migration solution? > > > > > > > What will happen on the user side? > > > > > > > > > > > > > > > > > > > > > В Чт, 23/08/2018 в 14:44 +0300, Vyacheslav Daradur пишет: > > > > > > > > Hi, Igniters! > > > > > > > > > > > > > > > > I’m working on Service Grid redesign tasks and design seems > to be > > > > > > > finished. > > > > > > > > > > > > > > > > The main goal of Service Grid redesign is to provide missed > > > > > guarantees: > > > > > > > > - Synchronous services deployment/undeployment; > > > > > > > > - Failover on coordinator change; > > > > > > > > - Propagation of deployments errors across the cluster; > > > > > > > > - Introduce of a deployment failures policy; > > > > > > > > - Prevention of deployments initiators hangs while > dep
[jira] [Created] (IGNITE-9437) [ML] Add performance benchmarks
Yury Babak created IGNITE-9437: -- Summary: [ML] Add performance benchmarks Key: IGNITE-9437 URL: https://issues.apache.org/jira/browse/IGNITE-9437 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Assignee: Oleg Ignatenko Fix For: 2.7 We want to have some performance benchmarks for ML algorithms -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Service Grid new design overview
Dmitriy, Yes, as you can see in the first message in this thread, request *DynamicServicesChangeRequestBatchMessage* is a container which is able to transfer several actions for batch operations like deployAll/cancelAll. Also, it will be possible to combine operations for *deploy* and *undeploy* in one message, for example in the case of redeploying by new version etc. On Thu, Aug 30, 2018 at 7:44 PM Dmitriy Setrakyan wrote: > > I also hope that we have some batching API to allow deployment of multiple > services together, either on grid startup or during the call to "deploy..." > API. > > D. > > On Thu, Aug 30, 2018 at 5:04 AM, Vyacheslav Daradur > wrote: > > > Hi Igniters! > > > > I had a private talk about new Service Grid design with: Alexey > > Goncharuk, Vladimir Ozerov, Denis Mekhanikov, Nikolay Izhikov, Anton > > Vinogradov and I'd like to share results. > > > > Design looks good in general, but we have decided to improve the > > unified flow of requests processing as follows - when any node > > received request on deploying, a node should calculate assignments > > yourself and deploys it if needed, then sends the result to the > > coordinator instead of waiting for assignments from the coordinator. > > > > For this change, we should make our service's assignments function > > *determined*, that means the function will return the same results for > > the same arguments at any node. > > > > We all agreed with this change because it allows us to reduce messages > > for handling each request and making the solution more flexible. > > > > On Tue, Aug 28, 2018 at 12:26 AM Dmitriy Setrakyan > > wrote: > > > > > > Agree with Val. I think all users would expect that a service is > > restarted > > > upon a node or cluster restart. Let's make sure we preserve this > > behavior. > > > > > > D. > > > > > > On Fri, Aug 24, 2018 at 4:17 PM, Valentin Kulichenko < > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > Guys, > > > > > > > > I believe we should preserve the behavior that we have now. What > > happens to > > > > services if we restart a persistent cluster running 2.6? Are services > > > > recreated or not? If YES, we should make sure the same happens after > > > > redesign. Would be even better if we preserve compatibility, i.e. allow > > > > seamless upgrade from older version that uses system cache to newer > > version > > > > that uses disco messages for service deployment. If NO, it's much > > easier > > > > and we can leave it as is for now. However, eventually would be great > > to > > > > have an option to persist services and redeploy them after cluster > > restart. > > > > > > > > -Val > > > > > > > > On Fri, Aug 24, 2018 at 2:51 PM Dmitriy Pavlov > > > > wrote: > > > > > > > > > Denis M. & Val please share your vision about this topic. > > > > > > > > > > пт, 24 авг. 2018 г. в 15:52, Vyacheslav Daradur > >: > > > > > > > > > > > Nick, Antron, thank you for stepping in. > > > > > > > > > > > > AFAIK, Ignite cluster can move its state to a new version of Ignite > > > > > > using persistence only. > > > > > > > > > > > > Since Ignite v.2.3 persistence is configured on a memory region and > > > > > > system memory region is not persistence, that means the system > > > > > > (utility) cache will not be recovered on cluster restart. > > > > > > > > > > > > Here is a ticket which describes the same issue: > > > > > > https://issues.apache.org/jira/browse/IGNITE-6629 > > > > > > > > > > > > > BTW, Is proposed solution provides the guarantee that services > > will > > > > be > > > > > > > redeployed after each cluster restart since now we're not using > > the > > > > > > cache? > > > > > > > > > > > > No, only services described in IgniteConfiguration will be > > deployed at > > > > > > node startup as well as now. > > > > > > > > > > > > Am I wrong in something? > > > > > > On Thu, Aug 23, 2018 at 5:59 PM Anton Vinogradov > > > > wrote: > > > > > > > > > > > > > > Vyacheslav. > > > > > > > > > > > > > > It looks like we able to restart all services on grid startup > > from > > > > old > > > > > > > definitions (inside cache) in case persistence turned on. > > > > > > > Se no problems to provide such automated migration case. > > > > > > > Also, we can test it using compatibility framework. > > > > > > > > > > > > > > BTW, Is proposed solution provides the guarantee that services > > will > > > > be > > > > > > > redeployed after each cluster restart since now we're not using > > the > > > > > > cache? > > > > > > > > > > > > > > чт, 23 авг. 2018 г. в 15:21, Nikolay Izhikov < > > nizhi...@apache.org>: > > > > > > > > > > > > > > > Hello, Vyacheslav. > > > > > > > > > > > > > > > > Thanks, for sharing your design. > > > > > > > > > > > > > > > > > I have a question about services migration from AI 2.6 to a > > new > > > > > > solution > > > > > > > > > > > > > > > > Can you describe consequences of not having migration solution? > > > > > > > > What will happen on the user side? > > > > >
[jira] [Created] (IGNITE-9438) StandaloneWalRecordsIterator file descriptors leak
Sergey Antonov created IGNITE-9438:
--
Summary: StandaloneWalRecordsIterator file descriptors leak
Key: IGNITE-9438
URL: https://issues.apache.org/jira/browse/IGNITE-9438
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Sergey Antonov
Fix For: 2.7
In {{StandaloneWalRecordsIterator#initReadHandle()}} method are opens file
descriptor.
{code:java}
FileIO fileIO = fd.isCompressed() ? new UnzipFileIO(fd.file()) :
ioFactory.create(fd.file());
{code}
It not used after attempt to read segment header and it don't closed.
Second time same file descriptor are opens in super method
{{AbstractWalRecordsIterator#initReadHandle()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: New PMC member: Dmitriy Pavlov
Dmitriy, My congratulations! Thank you for your work! On Thu, Aug 30, 2018 at 1:58 PM Maxim Muzafarov wrote: > Dmitry, > > My congratulations! > Thank you for guiding and helping the community members and me, in > particular, > to follow the Apache Way principles and also for your contribution. > > On Wed, 29 Aug 2018 at 22:31 Denis Magda wrote: > > > The Project Management Committee (PMC) for Apache Ignite > > has invited Dmitriy Pavlov to become a PMC member and we are pleased > > to announce that he has accepted. > > > > Being a PMC member enables assistance with the management > > and to guide the direction of the project. > > > > Congratulations Dmitriy! Keep contributing to Ignite success the way you > do > > ;) > > > > Denis > > > -- > -- > Maxim Muzafarov >
Hello Ignite Team, IGNITE-9438 contribution
Hello Team, I'd like to join to Apache Ignite development. Currently, I work on IGNITE-9438 https://issues.apache.org/jira/browse/IGNITE-9438 My Jira login is antonovsergey93 BR, Sergey Antonov -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: New committer: Dmitriy Govorukhin
Dmitriy, Congratulations! Your new role is well deserved, keep going! Best Regards, Ivan Rakov On 30.08.2018 1:20, Dmitriy Setrakyan wrote: Dmitriy, congrats! Looking forward to many contributions to come. On Wed, Aug 29, 2018 at 12:35 PM, Denis Magda wrote: The Project Management Committee (PMC) for Apache Ignite has invited Dmitriy Govorukhin to become a committer and we are pleased to announce that he has accepted. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Congrats, Dmitriy! Look forward to your contributions. -- Denis
[jira] [Created] (IGNITE-9439) Grid hangs after cache start failure.
Andrew Mashenkov created IGNITE-9439: Summary: Grid hangs after cache start failure. Key: IGNITE-9439 URL: https://issues.apache.org/jira/browse/IGNITE-9439 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Andrew Mashenkov Fix For: 2.7 Attachments: failure.txt If cache configuration validation failed on cache start, then seems exchange future rollback cache starting procedure correctly and user get expected exception. But then its starts to initialize broken cache which is unexpected. We should skip broken caches. PFA stacktraces. Steps to reproduce: - Try start cache with *invalid* configuration and ignore catched exception. - Next start cache with *valid* configuration will hangs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Hello Ignite Team, IGNITE-9438 contribution
Welcome Sergey! Added you to JIRA. -- Denis On Thu, Aug 30, 2018 at 10:16 AM antonovsergey93 wrote: > Hello Team, > > I'd like to join to Apache Ignite development. > Currently, I work on IGNITE-9438 > https://issues.apache.org/jira/browse/IGNITE-9438 > > My Jira login is antonovsergey93 > > BR, Sergey Antonov > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
Re: New committer: Dmitriy Govorukhin
Dmitriy, Congratulations, you finally got it :) чт, 30 авг. 2018 г. в 20:25, Ivan Rakov : > Dmitriy, > > Congratulations! Your new role is well deserved, keep going! > > Best Regards, > Ivan Rakov > > On 30.08.2018 1:20, Dmitriy Setrakyan wrote: > > Dmitriy, congrats! Looking forward to many contributions to come. > > > > On Wed, Aug 29, 2018 at 12:35 PM, Denis Magda wrote: > > > >> The Project Management Committee (PMC) for Apache Ignite > >> has invited Dmitriy Govorukhin to become a committer and we are pleased > >> to announce that he has accepted. > >> > >> Being a committer enables easier contribution to the > >> project since there is no need to go via the patch > >> submission process. This should enable better productivity. > >> > >> Congrats, Dmitriy! Look forward to your contributions. > >> > >> -- > >> Denis > >> > >
Re: New PMC member: Dmitriy Pavlov
Dmitriy, Congratulations. This is very nice to see such valuable community member in PMC role. чт, 30 авг. 2018 г. в 20:11, Dmitriy Govorukhin < dmitriy.govoruk...@gmail.com>: > Dmitriy, > > My congratulations! > Thank you for your work! > > On Thu, Aug 30, 2018 at 1:58 PM Maxim Muzafarov > wrote: > > > Dmitry, > > > > My congratulations! > > Thank you for guiding and helping the community members and me, in > > particular, > > to follow the Apache Way principles and also for your contribution. > > > > On Wed, 29 Aug 2018 at 22:31 Denis Magda wrote: > > > > > The Project Management Committee (PMC) for Apache Ignite > > > has invited Dmitriy Pavlov to become a PMC member and we are pleased > > > to announce that he has accepted. > > > > > > Being a PMC member enables assistance with the management > > > and to guide the direction of the project. > > > > > > Congratulations Dmitriy! Keep contributing to Ignite success the way > you > > do > > > ;) > > > > > > Denis > > > > > -- > > -- > > Maxim Muzafarov > > >
[MTCGA]: new failures in builds [1759577] needs to be handled
Hi Ignite Developer, I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed. I hope you can help. *New test failure in master IgniteConfigurationParityTest.TestIgniteConfiguration https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-2475516713290452471&branch=%3Cdefault%3E&tab=testDetails Changes may led to failure were done by - kaa.dev http://ci.ignite.apache.org/viewModification.html?modId=830084&personal=false - gvvinblade http://ci.ignite.apache.org/viewModification.html?modId=830083&personal=false - If your changes can led to this failure(s), please create issue with label MakeTeamCityGreenAgain and assign it to you. -- If you have fix, please set ticket to PA state and write to dev list fix is ready -- For case fix will require some time please mute test and set label Muted_Test to issue - If you know which change caused failure please contact change author directly - If you don't know which change caused failure please send message to dev list to find out Should you have any questions please contact dev@ignite.apache.org Best Regards, MTCGA.Bot Notification generated at Thu Aug 30 23:52:04 MSK 2018
[MTCGA]: new failures in builds [1757777] needs to be handled
Hi Ignite Developer, I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed. I hope you can help. *New test failure in master TcpDiscoveryCloudIpFinderSelfTest.testRackspace https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=3102247230760992596&branch=%3Cdefault%3E&tab=testDetails Changes may led to failure were done by - irakov http://ci.ignite.apache.org/viewModification.html?modId=829932&personal=false - If your changes can led to this failure(s), please create issue with label MakeTeamCityGreenAgain and assign it to you. -- If you have fix, please set ticket to PA state and write to dev list fix is ready -- For case fix will require some time please mute test and set label Muted_Test to issue - If you know which change caused failure please contact change author directly - If you don't know which change caused failure please send message to dev list to find out Should you have any questions please contact dev@ignite.apache.org Best Regards, MTCGA.Bot Notification generated at Fri Aug 31 00:06:59 MSK 2018
[GitHub] ignite pull request #4642: IGNITE-9116 .NET: LINQ: Use CacheConfiguration.Sq...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4642 ---
[MTCGA]: new failures in builds [1759578] needs to be handled
Hi Ignite Developer, I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed. I hope you can help. *New test failure in master IgniteConfigurationParityTest.TestIgniteConfiguration https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7406999233661835096&branch=%3Cdefault%3E&tab=testDetails Changes may led to failure were done by - kaa.dev http://ci.ignite.apache.org/viewModification.html?modId=830084&personal=false - gvvinblade http://ci.ignite.apache.org/viewModification.html?modId=830083&personal=false - If your changes can led to this failure(s), please create issue with label MakeTeamCityGreenAgain and assign it to you. -- If you have fix, please set ticket to PA state and write to dev list fix is ready -- For case fix will require some time please mute test and set label Muted_Test to issue - If you know which change caused failure please contact change author directly - If you don't know which change caused failure please send message to dev list to find out Should you have any questions please contact dev@ignite.apache.org Best Regards, MTCGA.Bot Notification generated at Fri Aug 31 00:22:01 MSK 2018
Re: New PMC member: Dmitriy Pavlov
Dmitriy, Congratulations !!! My best wishes :) Regards, Saikat On Thu, Aug 30, 2018 at 1:20 PM, Pavel Kovalenko wrote: > Dmitriy, > > Congratulations. This is very nice to see such valuable community member in > PMC role. > > чт, 30 авг. 2018 г. в 20:11, Dmitriy Govorukhin < > dmitriy.govoruk...@gmail.com>: > > > Dmitriy, > > > > My congratulations! > > Thank you for your work! > > > > On Thu, Aug 30, 2018 at 1:58 PM Maxim Muzafarov > > wrote: > > > > > Dmitry, > > > > > > My congratulations! > > > Thank you for guiding and helping the community members and me, in > > > particular, > > > to follow the Apache Way principles and also for your contribution. > > > > > > On Wed, 29 Aug 2018 at 22:31 Denis Magda wrote: > > > > > > > The Project Management Committee (PMC) for Apache Ignite > > > > has invited Dmitriy Pavlov to become a PMC member and we are pleased > > > > to announce that he has accepted. > > > > > > > > Being a PMC member enables assistance with the management > > > > and to guide the direction of the project. > > > > > > > > Congratulations Dmitriy! Keep contributing to Ignite success the way > > you > > > do > > > > ;) > > > > > > > > Denis > > > > > > > -- > > > -- > > > Maxim Muzafarov > > > > > >
[MTCGA]: new failures in builds [1759590] needs to be handled
Hi Ignite Developer, I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed. I hope you can help. *Recently contributed test failed in master GridIndexRebuildSelfTest.testMvccEnabled https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=441441622944389751&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master GridIndexRebuildSelfTest.testMvccDisabled https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-806294553921652015&branch=%3Cdefault%3E&tab=testDetails Changes may led to failure were done by - kaa.dev http://ci.ignite.apache.org/viewModification.html?modId=830084&personal=false - gvvinblade http://ci.ignite.apache.org/viewModification.html?modId=830083&personal=false - vsisko http://ci.ignite.apache.org/viewModification.html?modId=830070&personal=false - alexey.goncharuk http://ci.ignite.apache.org/viewModification.html?modId=830062&personal=false - zaleslaw.sin http://ci.ignite.apache.org/viewModification.html?modId=830058&personal=false - alexey.goncharuk http://ci.ignite.apache.org/viewModification.html?modId=830052&personal=false - If your changes can led to this failure(s), please create issue with label MakeTeamCityGreenAgain and assign it to you. -- If you have fix, please set ticket to PA state and write to dev list fix is ready -- For case fix will require some time please mute test and set label Muted_Test to issue - If you know which change caused failure please contact change author directly - If you don't know which change caused failure please send message to dev list to find out Should you have any questions please contact dev@ignite.apache.org Best Regards, MTCGA.Bot Notification generated at Fri Aug 31 02:37:14 MSK 2018
Re: Request for review : IGNITE-3303 Apache Flink Integration - Flink source
Hello, The changes for IGNITE-3303 for IgniteSource is complete. This will help is streaming data from Ignite cluster and process, filter, transform and publish it back to Ignite using IgniteSink or in any other data sink. I was hoping if the changes can be approved I can go ahead merge the changes. Regards, Saikat On Tue, Aug 28, 2018 at 12:56 AM, Saikat Maitra wrote: > Hi Andrew, > > As discussed I have incorporated the changes. Please review and let me > know if any changes required. > > Regards, > Saikat > > On Mon, Aug 27, 2018 at 1:45 AM, Saikat Maitra > wrote: > >> Hi, >> >> I have updated the PR with additional tests. >> >> Please review and share feedback. >> >> This PR is related to IgniteSink but allows to stream data from Ignite. >> >> PR https://github.com/apache/ignite/pull/870/files >> >> Review https://reviews.ignite.apache.org/ignite/review/IGNT-CR-135 >> >> Regards, >> Saikat >> > >
Re: Request for review : IGNITE-3303 Apache Flink Integration - Flink source
Hello Saikat, Hopefully, someone from the community will review the changes in the nearest time. -- Denis On Thu, Aug 30, 2018 at 4:37 PM Saikat Maitra wrote: > Hello, > > The changes for IGNITE-3303 for IgniteSource is complete. This will help is > streaming data from Ignite cluster and process, filter, transform and > publish it back to Ignite using IgniteSink or in any other data sink. > > I was hoping if the changes can be approved I can go ahead merge the > changes. > > > Regards, > Saikat > > > > On Tue, Aug 28, 2018 at 12:56 AM, Saikat Maitra > wrote: > > > Hi Andrew, > > > > As discussed I have incorporated the changes. Please review and let me > > know if any changes required. > > > > Regards, > > Saikat > > > > On Mon, Aug 27, 2018 at 1:45 AM, Saikat Maitra > > wrote: > > > >> Hi, > >> > >> I have updated the PR with additional tests. > >> > >> Please review and share feedback. > >> > >> This PR is related to IgniteSink but allows to stream data from Ignite. > >> > >> PR https://github.com/apache/ignite/pull/870/files > >> > >> Review https://reviews.ignite.apache.org/ignite/review/IGNT-CR-135 > >> > >> Regards, > >> Saikat > >> > > > > >
[MTCGA]: new failures in builds [1759672] needs to be handled
Hi Ignite Developer, I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed. I hope you can help. *Recently contributed test failed in master GridIndexRebuildSelfTest.testMvccEnabled https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=622693901472536027&branch=%3Cdefault%3E&tab=testDetails *Recently contributed test failed in master GridIndexRebuildSelfTest.testMvccDisabled https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-1601215100019546743&branch=%3Cdefault%3E&tab=testDetails Changes may led to failure were done by - kaa.dev http://ci.ignite.apache.org/viewModification.html?modId=830084&personal=false - gvvinblade http://ci.ignite.apache.org/viewModification.html?modId=830083&personal=false - vsisko http://ci.ignite.apache.org/viewModification.html?modId=830070&personal=false - alexey.goncharuk http://ci.ignite.apache.org/viewModification.html?modId=830062&personal=false - zaleslaw.sin http://ci.ignite.apache.org/viewModification.html?modId=830058&personal=false - alexey.goncharuk http://ci.ignite.apache.org/viewModification.html?modId=830052&personal=false - If your changes can led to this failure(s), please create issue with label MakeTeamCityGreenAgain and assign it to you. -- If you have fix, please set ticket to PA state and write to dev list fix is ready -- For case fix will require some time please mute test and set label Muted_Test to issue - If you know which change caused failure please contact change author directly - If you don't know which change caused failure please send message to dev list to find out Should you have any questions please contact dev@ignite.apache.org Best Regards, MTCGA.Bot Notification generated at Fri Aug 31 03:07:04 MSK 2018
Re: Request for review : IGNITE-3303 Apache Flink Integration - Flink source
Thank you, Denis Regards, Saikat On Thu, Aug 30, 2018 at 7:01 PM, Denis Magda wrote: > Hello Saikat, > > Hopefully, someone from the community will review the changes in the > nearest time. > > -- > Denis > > On Thu, Aug 30, 2018 at 4:37 PM Saikat Maitra > wrote: > > > Hello, > > > > The changes for IGNITE-3303 for IgniteSource is complete. This will help > is > > streaming data from Ignite cluster and process, filter, transform and > > publish it back to Ignite using IgniteSink or in any other data sink. > > > > I was hoping if the changes can be approved I can go ahead merge the > > changes. > > > > > > Regards, > > Saikat > > > > > > > > On Tue, Aug 28, 2018 at 12:56 AM, Saikat Maitra > > > wrote: > > > > > Hi Andrew, > > > > > > As discussed I have incorporated the changes. Please review and let me > > > know if any changes required. > > > > > > Regards, > > > Saikat > > > > > > On Mon, Aug 27, 2018 at 1:45 AM, Saikat Maitra < > saikat.mai...@gmail.com> > > > wrote: > > > > > >> Hi, > > >> > > >> I have updated the PR with additional tests. > > >> > > >> Please review and share feedback. > > >> > > >> This PR is related to IgniteSink but allows to stream data from > Ignite. > > >> > > >> PR https://github.com/apache/ignite/pull/870/files > > >> > > >> Review https://reviews.ignite.apache.org/ignite/review/IGNT-CR-135 > > >> > > >> Regards, > > >> Saikat > > >> > > > > > > > > >
[jira] [Created] (IGNITE-9440) control.sh --wal delete do not delete files
Alexand Polyakov created IGNITE-9440: Summary: control.sh --wal delete do not delete files Key: IGNITE-9440 URL: https://issues.apache.org/jira/browse/IGNITE-9440 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Alexand Polyakov Assignee: Alexand Polyakov Do not delete the files by the utility on command "control.sh --wal delete". Remain both checkpoints and wal in the archive. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4656: IGNITE-9440 control.sh --wal delete do not delete...
GitHub user a-polyakov opened a pull request: https://github.com/apache/ignite/pull/4656 IGNITE-9440 control.sh --wal delete do not delete files Do not delete the files by the utility on command "control.sh --wal delete". Remain both checkpoints and wal in the archive. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-9440 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4656.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4656 commit d7e976b1247c2efc0c35b8fb679130acf5602dfd Author: a-polyakov Date: 2018-08-31T02:18:42Z IGNITE-9440 control.sh --wal delete do not delete files Signed-off-by: a-polyakov ---
Re: New PMC member: Dmitriy Pavlov
Dmitriy, congrats! It is really great news! On Fri, Aug 31, 2018, 02:30 Saikat Maitra wrote: > Dmitriy, > > Congratulations !!! > > My best wishes :) > > Regards, > Saikat > > > > On Thu, Aug 30, 2018 at 1:20 PM, Pavel Kovalenko > wrote: > > > Dmitriy, > > > > Congratulations. This is very nice to see such valuable community member > in > > PMC role. > > > > чт, 30 авг. 2018 г. в 20:11, Dmitriy Govorukhin < > > dmitriy.govoruk...@gmail.com>: > > > > > Dmitriy, > > > > > > My congratulations! > > > Thank you for your work! > > > > > > On Thu, Aug 30, 2018 at 1:58 PM Maxim Muzafarov > > > wrote: > > > > > > > Dmitry, > > > > > > > > My congratulations! > > > > Thank you for guiding and helping the community members and me, in > > > > particular, > > > > to follow the Apache Way principles and also for your contribution. > > > > > > > > On Wed, 29 Aug 2018 at 22:31 Denis Magda wrote: > > > > > > > > > The Project Management Committee (PMC) for Apache Ignite > > > > > has invited Dmitriy Pavlov to become a PMC member and we are > pleased > > > > > to announce that he has accepted. > > > > > > > > > > Being a PMC member enables assistance with the management > > > > > and to guide the direction of the project. > > > > > > > > > > Congratulations Dmitriy! Keep contributing to Ignite success the > way > > > you > > > > do > > > > > ;) > > > > > > > > > > Denis > > > > > > > > > -- > > > > -- > > > > Maxim Muzafarov > > > > > > > > > >
