[GitHub] ignite pull request #5419: Measure grid start/stop overhead in tests
GitHub user pavlukhin opened a pull request: https://github.com/apache/ignite/pull/5419 Measure grid start/stop overhead in tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite measure-grid-start-stop-test-overhead Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5419.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 #5419 commit 57de12e5e9b7d683a48ed7efa7f840f8a8d5711c Author: ipavlukhin Date: 2018-11-17T05:19:05Z naively measure grid start/stop overhead in tests ---
Re: Time to remove automated messages from the devlist?
Hi, Can we collect opinions about keeping messages of mentioned types on dev list? From my side (+ means keeping on dev list): TC bot + Jira - GitHub - пт, 16 нояб. 2018 г. в 22:25, Dmitriy Pavlov : > > Importance is hardly definable and it is not possible that importance is > equal for everyone. You can say about other human emails it is not > important if some product area is not interesting for you. So I can only > understand the terms: email needs action/does not need action. > > If some contributor never reacted to JIRA notification he or she may think > it is not important. But even we have a majority of contributors who > ignores JIRA, it does not mean it is a right decision to switch it off. We > don't play in a democracy, hopefully. > > My suggestion now: keep showing an excellent example of human-human > interaction, announces, etc from all Ignite veterans (especially, PMCs), so > newcomers can use the same approach. > > If PRs removal to notifications@ will show a positive tendency in > human-human interaction, I can easily agree with the second step. Only > practice is truth criteria. > > пт, 16 нояб. 2018 г. в 22:08, Vladimir Ozerov : > > > We want important emails to be easily observable. This is the only goal. > > > > пт, 16 нояб. 2018 г. в 21:51, Dmitriy Pavlov : > > > > > I suggest to think in another paradigm, let's not classify emails to be > > > automatically issued or not, lets separate emails to other classes: a > > > needed action from humans or not needed. > > > > > > If you don't have any interest in a change announced by JIRA issue > > created > > > email, you can just skip. If you can help with comments, review, etc, you > > > can become watcher or comment ticket, you can also point to duplicate. > > > > > > In that paradigm, > > > A) PR is perfectly ok to be redirected to notifications@ .- PR creation > > > does not require any action from anyone. > > > B) JIRA - I'm not sure (maybe as a second step, if we will see > > contributors > > > will write about important tickets). And instead we can discuss Open -> > > > Patch available transition, as a reviewer needed. > > > C) TC Bot - I'm sure - should never be redirected. Hopefully, it will not > > > generate any alerts. > > > > > > I hardly understand goal: is our target metric - message count to be as > > > less as possible? (extreme - 0 emails, let's not write here at all, we > > can > > > get 0). Who can explain what do we want from redirection? > > > > > > > > > пт, 16 нояб. 2018 г. в 16:28, Sergi Vladykin : > > > > > > > I also would like to separate all the automated stuff. > > > > > > > > Sergi > > > > > > > > пт, 16 нояб. 2018 г. в 13:58, Павлухин Иван : > > > > > > > > > Oleg, > > > > > > > > > > I join to Dmitriy. I found your summary quite interesting. > > > > > пт, 16 нояб. 2018 г. в 13:12, Dmitriy Pavlov : > > > > > > > > > > > > Oleg, > > > > > > > > > > > > excellent research! It allows me to avoid bothering community > > > > developers > > > > > > once again. > > > > > > > > > > > > Thank you for your efforts and for contributing to this discussion. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 23:14, Denis Magda : > > > > > > > > > > > > > Let's move git notifications to a separate list. As for JIRA, not > > > > sure > > > > > it > > > > > > > bothers me, it took me several minutes to set up all the filters > > to > > > > > spread > > > > > > > the messages out across specific folders. Otherwise, some of us > > > might > > > > > > > ignore subscribing to jira-list and would miss notifications when > > > > their > > > > > > > input is needed. > > > > > > > > > > > > > > -- > > > > > > > Denis > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov < > > > > voze...@gridgain.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > > > I am not referring to some "authoritative ASF member" as a > > guide > > > > for > > > > > us. > > > > > > > We > > > > > > > > are on our own. What I meant is that at some point in time we > > > were > > > > > > > pointed > > > > > > > > to an idea, that tons of automated messages has nothing to do > > > with > > > > > > > healthy > > > > > > > > community. Which seems pretty reasonable to me. > > > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov < > > > > dpav...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > What incubator mentor do you refer to? Incubator member are > > asf > > > > > members > > > > > > > > as > > > > > > > > > well. > > > > > > > > > > > > > > > > > > I was involved at least to 3 discussions at the list started > > > from > > > > > Jira > > > > > > > > > issue created. > > > > > > > > > > > > > > > > > > If others were not involved, it do not convince me its is not > > > > > useful to > > > > > > > > > keep forwarding. > > > > > > > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:23 Vladim
Re: Time to remove automated messages from the devlist?
Importance is hardly definable and it is not possible that importance is equal for everyone. You can say about other human emails it is not important if some product area is not interesting for you. So I can only understand the terms: email needs action/does not need action. If some contributor never reacted to JIRA notification he or she may think it is not important. But even we have a majority of contributors who ignores JIRA, it does not mean it is a right decision to switch it off. We don't play in a democracy, hopefully. My suggestion now: keep showing an excellent example of human-human interaction, announces, etc from all Ignite veterans (especially, PMCs), so newcomers can use the same approach. If PRs removal to notifications@ will show a positive tendency in human-human interaction, I can easily agree with the second step. Only practice is truth criteria. пт, 16 нояб. 2018 г. в 22:08, Vladimir Ozerov : > We want important emails to be easily observable. This is the only goal. > > пт, 16 нояб. 2018 г. в 21:51, Dmitriy Pavlov : > > > I suggest to think in another paradigm, let's not classify emails to be > > automatically issued or not, lets separate emails to other classes: a > > needed action from humans or not needed. > > > > If you don't have any interest in a change announced by JIRA issue > created > > email, you can just skip. If you can help with comments, review, etc, you > > can become watcher or comment ticket, you can also point to duplicate. > > > > In that paradigm, > > A) PR is perfectly ok to be redirected to notifications@ .- PR creation > > does not require any action from anyone. > > B) JIRA - I'm not sure (maybe as a second step, if we will see > contributors > > will write about important tickets). And instead we can discuss Open -> > > Patch available transition, as a reviewer needed. > > C) TC Bot - I'm sure - should never be redirected. Hopefully, it will not > > generate any alerts. > > > > I hardly understand goal: is our target metric - message count to be as > > less as possible? (extreme - 0 emails, let's not write here at all, we > can > > get 0). Who can explain what do we want from redirection? > > > > > > пт, 16 нояб. 2018 г. в 16:28, Sergi Vladykin : > > > > > I also would like to separate all the automated stuff. > > > > > > Sergi > > > > > > пт, 16 нояб. 2018 г. в 13:58, Павлухин Иван : > > > > > > > Oleg, > > > > > > > > I join to Dmitriy. I found your summary quite interesting. > > > > пт, 16 нояб. 2018 г. в 13:12, Dmitriy Pavlov : > > > > > > > > > > Oleg, > > > > > > > > > > excellent research! It allows me to avoid bothering community > > > developers > > > > > once again. > > > > > > > > > > Thank you for your efforts and for contributing to this discussion. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > чт, 15 нояб. 2018 г. в 23:14, Denis Magda : > > > > > > > > > > > Let's move git notifications to a separate list. As for JIRA, not > > > sure > > > > it > > > > > > bothers me, it took me several minutes to set up all the filters > to > > > > spread > > > > > > the messages out across specific folders. Otherwise, some of us > > might > > > > > > ignore subscribing to jira-list and would miss notifications when > > > their > > > > > > input is needed. > > > > > > > > > > > > -- > > > > > > Denis > > > > > > > > > > > > On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov < > > > voze...@gridgain.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > I am not referring to some "authoritative ASF member" as a > guide > > > for > > > > us. > > > > > > We > > > > > > > are on our own. What I meant is that at some point in time we > > were > > > > > > pointed > > > > > > > to an idea, that tons of automated messages has nothing to do > > with > > > > > > healthy > > > > > > > community. Which seems pretty reasonable to me. > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov < > > > dpav...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > What incubator mentor do you refer to? Incubator member are > asf > > > > members > > > > > > > as > > > > > > > > well. > > > > > > > > > > > > > > > > I was involved at least to 3 discussions at the list started > > from > > > > Jira > > > > > > > > issue created. > > > > > > > > > > > > > > > > If others were not involved, it do not convince me its is not > > > > useful to > > > > > > > > keep forwarding. > > > > > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov < > > > voze...@gridgain.com > > > > >: > > > > > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > > > > > What Apache member do you refer to? > > > > > > > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov < > > > dpav...@apache.org > > > > >: > > > > > > > > > > > > > > > > > > > How do you know what to watch if new tickets are not > > > forwarded? > > > > > > > > > > > > > > > > > > > > Again, PRs are ok to remov
[jira] [Created] (IGNITE-10312) Data streamer fails with CCE: o.a.i.i.util.future.GridFinishedFuture cannot be cast to o.a.i.i.p.cache.distributed.dht.GridDhtTopologyFuture
Sergey Kozlov created IGNITE-10312:
--
Summary: Data streamer fails with CCE:
o.a.i.i.util.future.GridFinishedFuture cannot be cast to
o.a.i.i.p.cache.distributed.dht.GridDhtTopologyFuture
Key: IGNITE-10312
URL: https://issues.apache.org/jira/browse/IGNITE-10312
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Sergey Kozlov
Use data streamer by client node fails:
{noformat}
[17:08:50] (err) Failed to execute compound future reducer: GridCompoundFuture
[rdc=null, initFlag=1, lsnrCalls=3, done=true, cancelled=false, err=class
o.a.i.IgniteCheckedException: DataStreamer request failed
[node=6423a8f7-3607-4192-bbf8-13f859e77abd], futs=[true, true, true,
true]]class org.apache.ignite.IgniteCheckedException: DataStreamer request
failed [node=6423a8f7-3607-4192-bbf8-13f859e77abd]
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1894)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassCastException:
org.apache.ignite.internal.util.future.GridFinishedFuture cannot be cast to
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFuture
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2051)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
... 6 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Time to remove automated messages from the devlist?
We want important emails to be easily observable. This is the only goal. пт, 16 нояб. 2018 г. в 21:51, Dmitriy Pavlov : > I suggest to think in another paradigm, let's not classify emails to be > automatically issued or not, lets separate emails to other classes: a > needed action from humans or not needed. > > If you don't have any interest in a change announced by JIRA issue created > email, you can just skip. If you can help with comments, review, etc, you > can become watcher or comment ticket, you can also point to duplicate. > > In that paradigm, > A) PR is perfectly ok to be redirected to notifications@ .- PR creation > does not require any action from anyone. > B) JIRA - I'm not sure (maybe as a second step, if we will see contributors > will write about important tickets). And instead we can discuss Open -> > Patch available transition, as a reviewer needed. > C) TC Bot - I'm sure - should never be redirected. Hopefully, it will not > generate any alerts. > > I hardly understand goal: is our target metric - message count to be as > less as possible? (extreme - 0 emails, let's not write here at all, we can > get 0). Who can explain what do we want from redirection? > > > пт, 16 нояб. 2018 г. в 16:28, Sergi Vladykin : > > > I also would like to separate all the automated stuff. > > > > Sergi > > > > пт, 16 нояб. 2018 г. в 13:58, Павлухин Иван : > > > > > Oleg, > > > > > > I join to Dmitriy. I found your summary quite interesting. > > > пт, 16 нояб. 2018 г. в 13:12, Dmitriy Pavlov : > > > > > > > > Oleg, > > > > > > > > excellent research! It allows me to avoid bothering community > > developers > > > > once again. > > > > > > > > Thank you for your efforts and for contributing to this discussion. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > чт, 15 нояб. 2018 г. в 23:14, Denis Magda : > > > > > > > > > Let's move git notifications to a separate list. As for JIRA, not > > sure > > > it > > > > > bothers me, it took me several minutes to set up all the filters to > > > spread > > > > > the messages out across specific folders. Otherwise, some of us > might > > > > > ignore subscribing to jira-list and would miss notifications when > > their > > > > > input is needed. > > > > > > > > > > -- > > > > > Denis > > > > > > > > > > On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov < > > voze...@gridgain.com > > > > > > > > > wrote: > > > > > > > > > > > Dmitry, > > > > > > > > > > > > I am not referring to some "authoritative ASF member" as a guide > > for > > > us. > > > > > We > > > > > > are on our own. What I meant is that at some point in time we > were > > > > > pointed > > > > > > to an idea, that tons of automated messages has nothing to do > with > > > > > healthy > > > > > > community. Which seems pretty reasonable to me. > > > > > > > > > > > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov < > > dpav...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > What incubator mentor do you refer to? Incubator member are asf > > > members > > > > > > as > > > > > > > well. > > > > > > > > > > > > > > I was involved at least to 3 discussions at the list started > from > > > Jira > > > > > > > issue created. > > > > > > > > > > > > > > If others were not involved, it do not convince me its is not > > > useful to > > > > > > > keep forwarding. > > > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov < > > voze...@gridgain.com > > > >: > > > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > > > What Apache member do you refer to? > > > > > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov < > > dpav...@apache.org > > > >: > > > > > > > > > > > > > > > > > How do you know what to watch if new tickets are not > > forwarded? > > > > > > > > > > > > > > > > > > Again, PRs are ok to remove since it is duplicate to jira, > > but > > > jira > > > > > > > > removal > > > > > > > > > does not make any sense for me. > > > > > > > > > > > > > > > > > > Com dev folks instead suggest to forward all comments and > all > > > > > > activity > > > > > > > > from > > > > > > > > > github to the list. So if Apache member will confirm it is > > not > > > > > useful > > > > > > > to > > > > > > > > > allow dev. list watchers see new issues on the list we can > > > continue > > > > > > > > > discussion. Openness is needed not for veterans but for all > > > > > community > > > > > > > > > members and users who is subscribed to the list. > > > > > > > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn < > > > ptupit...@apache.org>: > > > > > > > > > > > > > > > > > > > Personal emails for _watched_ JIRA tickets are very > useful. > > > > > > > > > > Emails to everyone are not. > > > > > > > > > > > > > > > > > > > > +1 for separate mailing list for all automated emails. > > > > > > > > > > I don't think we can avoid automated emails completely, > but > > > dev > > > > > > list > > > > > > > > > should > > > > > > > > > > be human-only. > > > > > > >
Re: Time to remove automated messages from the devlist?
I suggest to think in another paradigm, let's not classify emails to be automatically issued or not, lets separate emails to other classes: a needed action from humans or not needed. If you don't have any interest in a change announced by JIRA issue created email, you can just skip. If you can help with comments, review, etc, you can become watcher or comment ticket, you can also point to duplicate. In that paradigm, A) PR is perfectly ok to be redirected to notifications@ .- PR creation does not require any action from anyone. B) JIRA - I'm not sure (maybe as a second step, if we will see contributors will write about important tickets). And instead we can discuss Open -> Patch available transition, as a reviewer needed. C) TC Bot - I'm sure - should never be redirected. Hopefully, it will not generate any alerts. I hardly understand goal: is our target metric - message count to be as less as possible? (extreme - 0 emails, let's not write here at all, we can get 0). Who can explain what do we want from redirection? пт, 16 нояб. 2018 г. в 16:28, Sergi Vladykin : > I also would like to separate all the automated stuff. > > Sergi > > пт, 16 нояб. 2018 г. в 13:58, Павлухин Иван : > > > Oleg, > > > > I join to Dmitriy. I found your summary quite interesting. > > пт, 16 нояб. 2018 г. в 13:12, Dmitriy Pavlov : > > > > > > Oleg, > > > > > > excellent research! It allows me to avoid bothering community > developers > > > once again. > > > > > > Thank you for your efforts and for contributing to this discussion. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > чт, 15 нояб. 2018 г. в 23:14, Denis Magda : > > > > > > > Let's move git notifications to a separate list. As for JIRA, not > sure > > it > > > > bothers me, it took me several minutes to set up all the filters to > > spread > > > > the messages out across specific folders. Otherwise, some of us might > > > > ignore subscribing to jira-list and would miss notifications when > their > > > > input is needed. > > > > > > > > -- > > > > Denis > > > > > > > > On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov < > voze...@gridgain.com > > > > > > > wrote: > > > > > > > > > Dmitry, > > > > > > > > > > I am not referring to some "authoritative ASF member" as a guide > for > > us. > > > > We > > > > > are on our own. What I meant is that at some point in time we were > > > > pointed > > > > > to an idea, that tons of automated messages has nothing to do with > > > > healthy > > > > > community. Which seems pretty reasonable to me. > > > > > > > > > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov < > dpav...@apache.org> > > > > > wrote: > > > > > > > > > > > What incubator mentor do you refer to? Incubator member are asf > > members > > > > > as > > > > > > well. > > > > > > > > > > > > I was involved at least to 3 discussions at the list started from > > Jira > > > > > > issue created. > > > > > > > > > > > > If others were not involved, it do not convince me its is not > > useful to > > > > > > keep forwarding. > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov < > voze...@gridgain.com > > >: > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > What Apache member do you refer to? > > > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov < > dpav...@apache.org > > >: > > > > > > > > > > > > > > > How do you know what to watch if new tickets are not > forwarded? > > > > > > > > > > > > > > > > Again, PRs are ok to remove since it is duplicate to jira, > but > > jira > > > > > > > removal > > > > > > > > does not make any sense for me. > > > > > > > > > > > > > > > > Com dev folks instead suggest to forward all comments and all > > > > > activity > > > > > > > from > > > > > > > > github to the list. So if Apache member will confirm it is > not > > > > useful > > > > > > to > > > > > > > > allow dev. list watchers see new issues on the list we can > > continue > > > > > > > > discussion. Openness is needed not for veterans but for all > > > > community > > > > > > > > members and users who is subscribed to the list. > > > > > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn < > > ptupit...@apache.org>: > > > > > > > > > > > > > > > > > Personal emails for _watched_ JIRA tickets are very useful. > > > > > > > > > Emails to everyone are not. > > > > > > > > > > > > > > > > > > +1 for separate mailing list for all automated emails. > > > > > > > > > I don't think we can avoid automated emails completely, but > > dev > > > > > list > > > > > > > > should > > > > > > > > > be human-only. > > > > > > > > > So separate list is the only way. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov < > > > > > > voze...@gridgain.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Completely agree with Denis. Tons of generated messages > and > > > > > > community > > > > > > > > > > health are not relevant. Currently we obviously have too > > much > >
[jira] [Created] (IGNITE-10311) SQL: Create system view with query co-location plans
Vladimir Ozerov created IGNITE-10311:
Summary: SQL: Create system view with query co-location plans
Key: IGNITE-10311
URL: https://issues.apache.org/jira/browse/IGNITE-10311
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
It is very important to understand model of distributed execution for certain
queries for performance tuning. Let's create a syhstem view which will iterate
over cached two-step queries and print their plans in table form.
Approximate structure (very raw):
{code}
CREATE VIEW sql_query_plan (
plan_id, // Unique plan ID (node ID + unique local ID)
sql, // Plain text
sql_hash. // May be more convenient that query_id
flags // Same query with different flags may result in different plans
)
CREATE VIEW sql_query_plan_fragments (
plan_id, // Same plan ID
order, // Together with plan_id it forms PK
action, // What is this - "reduce", "skip reduce", "map", etc. (may be we
will need multiple columns)
sql, // SQL of the fragment (if applicable)
)
{code}
Next user may list cached plans, select interesting, and query plan fragments
view.
We need to analyze other vendors to better understand what to show in views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10310) SQL: Create TABLEs system view with affinity information
Vladimir Ozerov created IGNITE-10310: Summary: SQL: Create TABLEs system view with affinity information Key: IGNITE-10310 URL: https://issues.apache.org/jira/browse/IGNITE-10310 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Lets add a system view with our tables. At the very least it should include: # table name # cache name # schema name # affinity column # affinity key (if IGNITE-10309 is implemented) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10309) SQL: Ability to specifiy affinity function equality during table creation
Vladimir Ozerov created IGNITE-10309:
Summary: SQL: Ability to specifiy affinity function equality
during table creation
Key: IGNITE-10309
URL: https://issues.apache.org/jira/browse/IGNITE-10309
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
Currently users may specify affinity key in {{CREATE TABLE}} command. However,
there are situations when custom affintiy function or custom affinity mapper
are used. In this case we do not know what actual fields are used for affinity
calculation, neither we know if two affinity functions are equal and produce
deterministic results *. In this case we may want to give user ability to
confirm on his own risk that certain caches has the same affinity functions and
are co-located.
To achieve this all we need is to add new string parameter, say,
{{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
function, we may compare their affinity functions keys. If they match, then we
may treat them co-located and extract partitions successfully.
* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
{{FairAffinityFunction}} which depend on cluster history and may produce
different distributions between two caches even if two caches has the same
function parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10308) SQL: Pass partition pruning models to JDBC thin driver
Vladimir Ozerov created IGNITE-10308: Summary: SQL: Pass partition pruning models to JDBC thin driver Key: IGNITE-10308 URL: https://issues.apache.org/jira/browse/IGNITE-10308 Project: Ignite Issue Type: Task Components: jdbc, sql Reporter: Vladimir Ozerov Fix For: 2.8 Once partitions are extracted from original query (IGNITE-10305), it might be useful for thin clients: they could apply arguments locally and try to guess the best node where to send the request. Example: when there is only one partition, then it makes sense to send the request directly to that node, so that only one hop is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10307) SQL: Extract partition info from JOINs
Vladimir Ozerov created IGNITE-10307:
Summary: SQL: Extract partition info from JOINs
Key: IGNITE-10307
URL: https://issues.apache.org/jira/browse/IGNITE-10307
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
Currently we do not extract partitions when JOINs are involved. Let's implement
it. We may start with relatively simple rules:
# No subqueries
# No GROUP BY
Then walk through JOINed tables and extract partitions from AND clauses.
There are some tricky things to consider:
# Resulting model (tree) must be craefted carefully so that we can reuse it
later in thin clients for efficient co-location.
# Resulting model may affect how we group tables during push-down phase.
Probably this would be huuuge thing, so may be it is better to implement it in
separate ticket
# When JOIN is performed partition info might be "transferred" between tables.
E.g.:
{code}
a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
{code}
In this case if tables are co-located (we may infer it automatically in some
cases), then {{a.id=:1}} partition rule can be "transferred" to
{{b.affinity_id=:1}}.
Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10306) SQL: Transform subqueries to JOINs when possible
Vladimir Ozerov created IGNITE-10306: Summary: SQL: Transform subqueries to JOINs when possible Key: IGNITE-10306 URL: https://issues.apache.org/jira/browse/IGNITE-10306 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently subqueries are mostly not analyzed in any way. This makes our distributed execution plan more complex to analyze and execute. Moreover, we cannot extract partition information from such queries efficiently. We need to apply the simplest "JOIN conversion" optimization on early query analysis phase and try to transform our AST from subquery to join. This should be done before partition extraction, pushdowns and splitter. See [1] for more information. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
Vladimir Ozerov created IGNITE-10305:
Summary: SQL: Optimize query execution if it targets only one or
none partitions
Key: IGNITE-10305
URL: https://issues.apache.org/jira/browse/IGNITE-10305
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
This is a part of "Partition Pruning" IEP [1].
Currently we try to extract partitions from map queries and route requests
accordingly. Several problems with this approach:
1) Individual map queries may target the same partition, but we never know
that, so we may want to setup a merge table when it is not really needed.
2) Sometimes query may reduce to no partitions. In this case we should not
execute anything at all and simply return empty result set.
3) If the whole query targets only one partition, we may skip the whole
splitter phase!
I propose to do the following:
# Try to extract partition from "original" query.
# If we see that exactly one partition is involved, then original query is a
map query, and reduce should be performed in "skip merge table" mode
# If we see that there are no partitions because query is invalid (e.g. {{id =
1 AND id = 2}}), then stop and return no results. This decision should be
cached in two-step plan.
# If we see that there are some partitions, then we should apply arguments and
see the result. If result set is empty - return, but do not cache empty result
set decision, as it may change for another set of arguments.
# If none of above hold, then do pushdowns and split, and analyze partitions of
individual map queries. For those of them where partition set is empty, we
should return empty result set without executing anything.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10304) SQL: Encapsulate H2 query execution into ConnectionManager
Vladimir Ozerov created IGNITE-10304:
Summary: SQL: Encapsulate H2 query execution into ConnectionManager
Key: IGNITE-10304
URL: https://issues.apache.org/jira/browse/IGNITE-10304
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
This ticket should be done after IGNITE-10299. Currently {{ConnectionManager}}
exposes cached H2 connections to the outside. Sometimes these connections are
used in safe manner and {{ConnectionManager.onSqlException}} is called to
recycle bad connection. But most of the time this is not the case, what may
lead to unexpected behavior.
Let's try to hide all statement execution logic inside {{ConnectionManager}} to
avoid this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #5418: IGNITE-10303
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5418 IGNITE-10303 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10303 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5418.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 #5418 commit e6f47f8b032f6d18287b285fa153a18f8b018cc0 Author: devozerov Date: 2018-11-16T15:32:09Z Moved code. Dirty, but should work. commit 19829ebb28c9f3eb9de23f1ee67fe054ad32a622 Author: devozerov Date: 2018-11-16T15:50:18Z Cleanup (1). commit ab8502435b1670bd230a9befe92ac852ac131f8d Author: devozerov Date: 2018-11-16T16:19:12Z WIP. commit c06f23a4d23a383b97b91f66302752713541c777 Author: devozerov Date: 2018-11-16T16:29:09Z WIP. commit fa5218f51e971b3b48eba682c110ac15abcbcd3f Author: devozerov Date: 2018-11-16T16:33:30Z WIP (worked before this commit). commit 7a7c038619842390269f06a9511fc85278806f5f Author: devozerov Date: 2018-11-16T16:38:17Z Merged close routine. commit 5b7ae7b56d52a101b3369791c13ee43dab0b2bec Author: devozerov Date: 2018-11-16T16:47:37Z Dangerous: fixed schema change. commit 35f475cbf6c7de42767b5f950f52229f9a8f37e7 Author: devozerov Date: 2018-11-16T16:56:18Z connectionForSchema -> connectionForThread commit 2ae9003ad937b343588b30be31ee7dc835e2b60b Author: devozerov Date: 2018-11-16T17:07:08Z Almost done. commit ffddfd3a04925e3c8709ce2ff35596e0725b3ae2 Author: devozerov Date: 2018-11-16T17:08:39Z Done. commit c1e7acc9c48de6f08bcbe2e5ff8252395300947d Author: devozerov Date: 2018-11-16T17:11:55Z Rename. ---
[jira] [Created] (IGNITE-10303) SQL: Move connection management logic into separate class
Vladimir Ozerov created IGNITE-10303:
Summary: SQL: Move connection management logic into separate class
Key: IGNITE-10303
URL: https://issues.apache.org/jira/browse/IGNITE-10303
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
Currently {{IgniteH2Indexing}} class is a mix of various mixed abstractions.
One of them is connection management. Let's abstract it out.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] dspavlov opened a new pull request #73: Partial pr data display
dspavlov opened a new pull request #73: Partial pr data display URL: https://github.com/apache/ignite-teamcity-bot/pull/73 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] ignite pull request #5417: IGNITE-4003
GitHub user ilantukh opened a pull request: https://github.com/apache/ignite/pull/5417 IGNITE-4003 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4003-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5417.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 #5417 commit 7d3aae218f69ef3959026463e97b4f6f2a836cf1 Author: Ilya Lantukh Date: 2018-11-16T15:39:56Z IGNITE-4003 : WIP. commit c9667fbaf47f37cdffa48bb1c78eafb3550e4c55 Author: Ilya Lantukh Date: 2018-11-16T16:17:43Z IGNITE-4003 : Fixed recovery descriptor initialization. ---
[GitHub] ignite pull request #5332: IGNITE-10156 Fixed converting DynamicCacheDescrip...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5332 ---
[GitHub] ignite pull request #5413: IGNITE-10295 Added info logging for long connecti...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5413 ---
[GitHub] ignite pull request #3200: Ignite 6341 & IGNITE-7017 & IGNITE-7175 & IGNITE-...
Github user dspavlov closed the pull request at: https://github.com/apache/ignite/pull/3200 ---
[jira] [Created] (IGNITE-10302) MVCC: Update backups asynchronously
Roman Kondakov created IGNITE-10302: --- Summary: MVCC: Update backups asynchronously Key: IGNITE-10302 URL: https://issues.apache.org/jira/browse/IGNITE-10302 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Roman Kondakov Currently we update backups synchronously. It means we should wait all backup nodes apply transaction updates and send back acknowledgment for each statement before proceed. Actually, we do not have to wait until backups processed their updates. Instead we can update primary node, then "fire-and-forget" update to backups and continue handling next transaction statements. This approach eliminates waiting 2 extra network hops for each statement (sending update to backup and receiving ack back). Points to consider: * Backup should transit to "prepare" phase only when all updates were applied. * "Small" transactions can send updated values in prepare message. * "Big" transaction can stream batched updates to backups asynchronously. In this case we need to provide some backpressure implementation to prevent backup choke. * This optimization is applicable only for partitioned caches. This is because replicated caches may read data from backups and they should see their own updates -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5416: IGNITE-10172 System flag introduced to disable di...
GitHub user alex-plekhanov opened a pull request: https://github.com/apache/ignite/pull/5416 IGNITE-10172 System flag introduced to disable discovery cache metrics updates You can merge this pull request into a Git repository by running: $ git pull https://github.com/alex-plekhanov/ignite ignite-10172 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5416.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 #5416 commit 9fc84a2cb82286c2d73c4d905aab5e82a0d9604f Author: Aleksey Plekhanov Date: 2018-11-08T12:25:25Z IGNITE-10172 System property to disable discovery cache metrics update commit ea9a3992eade1f24c53ce541a22a7090c0519475 Author: Aleksey Plekhanov Date: 2018-11-16T15:04:29Z IGNITE-10172 Unit test ---
[GitHub] ignite pull request #5415: IGNITE-10234: Inference workflow for ML
GitHub user dmitrievanthony opened a pull request: https://github.com/apache/ignite/pull/5415 IGNITE-10234: Inference workflow for ML You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10234 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5415.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 #5415 commit d9ea1918ec13533aaec70a0c3e36febecb426e27 Author: dmitrievanthony Date: 2018-11-16T14:59:49Z IGNITE-10234: First version of inference workflow implementation. ---
Re: Apache Ignite 2.7. Last Mile
Ok, I'll check the issue. пт, 16 нояб. 2018 г. в 17:52, Alexey Goncharuk : > > Igniters, > > I've just found that S.toString() implementation is broken in ignite-2.7 and > master [1]. It leads to a message > Wrapper [p=Parent [a=0]Child [b=0, super=]] > being formed instead of > Wrapper [p=Child [b=0, super=Parent [a=0]]] > for classes with inheritance that use S.toString(SomeClass.class, this, > super.toString()) embedded to some other object. > > Dmitrii Ryabov, I've reverted two commits related to IGNITE-602 and > IGNITE-9209 tickets locally and it fixes the issue. Can you take a look at > the issue? > > I think this regression essentially makes our logs unreadable in some cases > and I would like to get it fixed in ignite-2.7 or revert both commits from > the release. > > [1] https://issues.apache.org/jira/browse/IGNITE-10301 > > пт, 9 нояб. 2018 г. в 09:22, Nikolay Izhikov : >> >> Hello, Igniters. >> >> We still have 5 tickets for 2.7: >> >> IGNITE-10052Andrew Mashenkov Restart node during TX causes vacuum error. >> IGNITE-10170Unassigned .NET: Services.ServicesTestAsync fails >> IGNITE-10196Maxim Pudov Remove kafka-clients-*-test dependency >> IGNITE-10154Andrey Gura Critical worker liveness check >> configuration is non-trivial and inconsistent >> IGNITE-9996 Nikolay Izhikov Investigate possible performance drop in >> FSYNC mode for ignite-2.7 compared to ignite-2.6 >> >> >> В Чт, 08/11/2018 в 14:25 +0300, Nikolay Izhikov пишет: >> > I'm OK with this. >> > >> > чт, 8 нояб. 2018 г., 13:44 Andrey Gura ag...@apache.org: >> > > Long, long way to release :) >> > > >> > > Guys, we have a breaking change in Ignite 2.7 so we must add >> > > IGNITE-10154 [1] fix to the release. >> > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-10154 >> > > On Tue, Nov 6, 2018 at 6:30 PM Igor Sapego wrote: >> > > > >> > > > Guys, >> > > > >> > > > I've found the following issue: [1]. It is quite local (only affects >> > > > Ignite C++ Linux build system) but quite critical too. I think it >> > > > should be included in 2.7. >> > > > >> > > > What do you think? >> > > > >> > > > [1] - https://issues.apache.org/jira/browse/IGNITE-10147 >> > > > >> > > > Best Regards, >> > > > Igor >> > > > >> > > > >> > > > On Tue, Oct 30, 2018 at 4:35 PM Вячеслав Коптилин >> > > > >> > > > wrote: >> > > > >> > > > > Hello Nikolay, Igniters, >> > > > > >> > > > > It seems that we lost the following commit that should be included in >> > > > > 'ignite-2.7' branch >> > > > > (It looks like the change was not accidentally cherry-picked from >> > > > > 'master' >> > > > > to 'ignite-2.7') >> > > > > - >> > > > > >> > > > > https://github.com/apache/ignite/commit/6e0ff06f8e309657a16c94da605348d9c3b804ad >> > > > > >> > > > > The most important part is the change introduced into >> > > > > GridDhtAtomicCache, >> > > > > the fix prevents NullPointerException during cache updates under some >> > > > > circumstances. >> > > > > So, I propose including the fix into ignite-2.7, at least the change >> > > > > of >> > > > > GridDhtAtomicCache. >> > > > > >> > > > > Thanks, >> > > > > Slava. >> > > > > >> > > > > пн, 29 окт. 2018 г. в 11:20, Nikolay Izhikov : >> > > > > >> > > > > > Hello, guys. >> > > > > > >> > > > > > For today we have 11 tickets mapped to 2.7 >> > > > > > >> > > > > > IGNITE-10010 Alexey Goncharuk Node halted if second node was >> > > > > > stopped, >> > > > > then >> > > > > > cache destroyed, then second node returned >> > > > > > IGNITE-10015 Alexey Goncharuk Sporadic JVM crash due to restart >> > > > > > nodes >> > > > > > IGNITE-10013 Unassigned Node restart may lead to NPE in >> > > > > > GridDhtPartitionsExchangeFuture >> > > > > > IGNITE-9928 Igor Seliverstov MVCC TX: Late affinity assignment >> > > > > > support. >> > > > > > IGNITE-9985 Igor Seliverstov MVCC TX: fix backup mappings >> > > > > > IGNITE-10007 Sergey Kozlov Deactivation hangs if an open >> > > > > > transaction >> > > > > exists >> > > > > > IGNITE-10004 Andrew Mashenkov Parse error leads to leave the >> > > > > > transaction >> > > > > > IGNITE-10024 Ivan Pavlukhin MVCC TX: Stackoverflow during >> > > > > > DhtEnlistFuture >> > > > > > mapping >> > > > > > IGNITE-9996 Alexey Goncharuk Investigate possible performance drop >> > > > > > in >> > > > > FSYNC >> > > > > > mode for ignite-2.7 compared to ignite-2.6 >> > > > > > IGNITE-9982 Ivan Pavlukhin SQLLine: can't run with option >> > > > > > --autoCommit=false or true >> > > > > > IGNITE-9828 Roman Kondakov MVCC: Continuous query failover. >> > > > > > >> > > > > > >> > > > > > пт, 26 окт. 2018 г. в 9:59, Vladimir Ozerov : >> > > > > > >> > > > > > > Hi Nikolay, >> > > > > > > >> > > > > > > I do not know. We need to investigate them first. These are all >> > > > > > > regressions, so decision about impact and urgency should be made >> > > > > > separately >> > > > > > > for every ticket. >> > > > > > > >> > > > > > > On Fri, Oct 26, 2018 at
Re: Apache Ignite 2.7. Last Mile
Igniters, I've just found that S.toString() implementation is broken in ignite-2.7 and master [1]. It leads to a message *Wrapper [p=Parent [a=0]Child [b=0, super=]]* being formed instead of *Wrapper [p=Child [b=0, super=Parent [a=0]]]* for classes with inheritance that use S.toString(SomeClass.class, this, super.toString()) embedded to some other object. Dmitrii Ryabov, I've reverted two commits related to IGNITE-602 and IGNITE-9209 tickets locally and it fixes the issue. Can you take a look at the issue? I think this regression essentially makes our logs unreadable in some cases and I would like to get it fixed in ignite-2.7 or revert both commits from the release. [1] https://issues.apache.org/jira/browse/IGNITE-10301 пт, 9 нояб. 2018 г. в 09:22, Nikolay Izhikov : > Hello, Igniters. > > We still have 5 tickets for 2.7: > > IGNITE-10052Andrew Mashenkov Restart node during TX causes vacuum > error. > IGNITE-10170Unassigned .NET: Services.ServicesTestAsync fails > IGNITE-10196Maxim Pudov Remove kafka-clients-*-test dependency > IGNITE-10154Andrey Gura Critical worker liveness check > configuration is non-trivial and inconsistent > IGNITE-9996 Nikolay Izhikov Investigate possible performance drop in > FSYNC mode for ignite-2.7 compared to ignite-2.6 > > > В Чт, 08/11/2018 в 14:25 +0300, Nikolay Izhikov пишет: > > I'm OK with this. > > > > чт, 8 нояб. 2018 г., 13:44 Andrey Gura ag...@apache.org: > > > Long, long way to release :) > > > > > > Guys, we have a breaking change in Ignite 2.7 so we must add > > > IGNITE-10154 [1] fix to the release. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10154 > > > On Tue, Nov 6, 2018 at 6:30 PM Igor Sapego wrote: > > > > > > > > Guys, > > > > > > > > I've found the following issue: [1]. It is quite local (only affects > > > > Ignite C++ Linux build system) but quite critical too. I think it > > > > should be included in 2.7. > > > > > > > > What do you think? > > > > > > > > [1] - https://issues.apache.org/jira/browse/IGNITE-10147 > > > > > > > > Best Regards, > > > > Igor > > > > > > > > > > > > On Tue, Oct 30, 2018 at 4:35 PM Вячеслав Коптилин < > slava.kopti...@gmail.com> > > > > wrote: > > > > > > > > > Hello Nikolay, Igniters, > > > > > > > > > > It seems that we lost the following commit that should be included > in > > > > > 'ignite-2.7' branch > > > > > (It looks like the change was not accidentally cherry-picked from > 'master' > > > > > to 'ignite-2.7') > > > > > - > > > > > > > > > > > https://github.com/apache/ignite/commit/6e0ff06f8e309657a16c94da605348d9c3b804ad > > > > > > > > > > The most important part is the change introduced into > GridDhtAtomicCache, > > > > > the fix prevents NullPointerException during cache updates under > some > > > > > circumstances. > > > > > So, I propose including the fix into ignite-2.7, at least the > change of > > > > > GridDhtAtomicCache. > > > > > > > > > > Thanks, > > > > > Slava. > > > > > > > > > > пн, 29 окт. 2018 г. в 11:20, Nikolay Izhikov >: > > > > > > > > > > > Hello, guys. > > > > > > > > > > > > For today we have 11 tickets mapped to 2.7 > > > > > > > > > > > > IGNITE-10010 Alexey Goncharuk Node halted if second node was > stopped, > > > > > then > > > > > > cache destroyed, then second node returned > > > > > > IGNITE-10015 Alexey Goncharuk Sporadic JVM crash due to restart > nodes > > > > > > IGNITE-10013 Unassigned Node restart may lead to NPE in > > > > > > GridDhtPartitionsExchangeFuture > > > > > > IGNITE-9928 Igor Seliverstov MVCC TX: Late affinity assignment > support. > > > > > > IGNITE-9985 Igor Seliverstov MVCC TX: fix backup mappings > > > > > > IGNITE-10007 Sergey Kozlov Deactivation hangs if an open > transaction > > > > > exists > > > > > > IGNITE-10004 Andrew Mashenkov Parse error leads to leave the > transaction > > > > > > IGNITE-10024 Ivan Pavlukhin MVCC TX: Stackoverflow during > DhtEnlistFuture > > > > > > mapping > > > > > > IGNITE-9996 Alexey Goncharuk Investigate possible performance > drop in > > > > > FSYNC > > > > > > mode for ignite-2.7 compared to ignite-2.6 > > > > > > IGNITE-9982 Ivan Pavlukhin SQLLine: can't run with option > > > > > > --autoCommit=false or true > > > > > > IGNITE-9828 Roman Kondakov MVCC: Continuous query failover. > > > > > > > > > > > > > > > > > > пт, 26 окт. 2018 г. в 9:59, Vladimir Ozerov < > voze...@gridgain.com>: > > > > > > > > > > > > > Hi Nikolay, > > > > > > > > > > > > > > I do not know. We need to investigate them first. These are all > > > > > > > regressions, so decision about impact and urgency should be > made > > > > > > separately > > > > > > > for every ticket. > > > > > > > > > > > > > > On Fri, Oct 26, 2018 at 9:57 AM Nikolay Izhikov < > nizhi...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > Hello, Igniters. > > > > > > > > > > > > > > > > We have *9* tickets mapped to 2.7 today > > > > > > > > > > > > > > > > Vladimir, do you think 1 week delay will be enough to >
[jira] [Created] (IGNITE-10301) GridToStringBuilder is broken for classes with inheritance
Alexey Goncharuk created IGNITE-10301:
-
Summary: GridToStringBuilder is broken for classes with inheritance
Key: IGNITE-10301
URL: https://issues.apache.org/jira/browse/IGNITE-10301
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexey Goncharuk
Fix For: 2.7
Given the following class hierarchy
{code}
/** */
private static class Parent {
/** */
private int a;
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(Parent.class, this);
}
}
/** */
private static class Child extends Parent {
/** */
private int b;
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(Child.class, this, super.toString());
}
}
private static class Wrapper {
/** */
@GridToStringInclude
Parent p = new Child();
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(Wrapper.class, this);
}
}
{code}
the next test fails:
{code}
/**
*/
public void testHierarchy() {
Wrapper w = new Wrapper();
Parent p = w.p;
String wS = w.toString();
String pS = p.toString();
// Expect wS to be "Wrapper [p=" + pS + ']'.
assertEquals("Wrapper [p=" + pS + ']', wS);
}
{code}
{code}
Expected :Wrapper [p=Child [b=0, super=Parent [a=0]]]
Actual :Wrapper [p=Parent [a=0]Child [b=0, super=]]
{code}
This is a regression from IGNITE-602. We need to fix this in 2.7 or revert
IGNITE-602.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10300) control.sh: incorrect error message after three tries on unsuccessful authorization
Pavel Voronkin created IGNITE-10300:
---
Summary: control.sh: incorrect error message after three tries on
unsuccessful authorization
Key: IGNITE-10300
URL: https://issues.apache.org/jira/browse/IGNITE-10300
Project: Ignite
Issue Type: Bug
Reporter: Pavel Voronkin
1. start grid with securirty enabled
2. try to issue control.sh --cache
authentication credentials asked
3. enter incorrect credentials three times
expected: Authentication error printed and logged
actual: Latest topology update failed error printed
{noformat}
IGNITE_HOME=`pwd` bin/control.sh --cache list .
Control utility [ver. 2.5.1-p160#20181113-sha1:5f845ca7]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Authentication error, try connection again.
user:
password:
Authentication error, try connection again.
user:
password:
Authentication error, try connection again.
user:
password:
Authentication error.
Error: Latest topology update failed.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10298) Possible deadlock between restore partition states and checkpoint begin
Pavel Kovalenko created IGNITE-10298:
Summary: Possible deadlock between restore partition states and
checkpoint begin
Key: IGNITE-10298
URL: https://issues.apache.org/jira/browse/IGNITE-10298
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Fix For: 2.8
There is possible deadlock between "restorePartitionStates" phase during caches
starting and currently running checkpointer:
{noformat}
"db-checkpoint-thread-#50" #89 prio=5 os_prio=0 tid=0x1ad57800
nid=0x2b58 waiting on condition [0x7e42e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0xddabfcc8> (a
java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at
org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7515)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1331)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.fullSize(GridCacheOffheapManager.java:1459)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3397)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3009)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2934)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
"exchange-worker-#42" #69 prio=5 os_prio=0 tid=0x1c1cd800 nid=0x259c
waiting on condition [0x249ae000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x80b634a0> (a
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1328)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1212)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.initialUpdateCounter(GridCacheOffheapManager.java:1537)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.onPartitionInitialCounterUpdated(GridCacheOffheapManager.java:633)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2365)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1174)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1119)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:703)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2364)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Possible solution is performing resto
Re: Brainstorm: Make TC Run All faster
Sure, any additional compute power should help. Extracting nightly builds is already started (at least prototyping), as well, as I know. And TC Bot triggers full(nightly) tests set: https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllNightly&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv пт, 16 нояб. 2018 г. в 17:06, Vyacheslav Daradur : > At one of the meetups, Vladimir Ozerov has said that we may specify > and move less risky to be broken tests in separate build plan which > will be executed daily or weekly > > For example tests of compatibility with different JDK versions or > compatibility between Ignite's releases. > > Also, I agree with Denis we should find and remove tests with the same > checks. > > By the way, if someone of the community donates TC agents, can this > help to reduce the time? > > On Thu, Nov 15, 2018 at 5:38 PM Yakov Zhdanov wrote: > > > > Denis, you can go even further. E.g. you can start topology once for the > > full set of single threaded full api cache tests. Each test should start > > cache dynamically and run it logic. > > > > As for me, I would think of splitting RunAll to 2 steps - one containing > > basic tests and another with more complex tests. 2nd step should not > start > > (except manually) if 1st step results in any build failure. > > > > --Yakov > > > > -- > Best Regards, Vyacheslav D. >
[GitHub] ignite pull request #5414: IGNITE-10299
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5414 IGNITE-10299 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10299 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5414.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 #5414 commit 68145c6eb0de4e4254a5804deb1b84f9a0a3be41 Author: devozerov Date: 2018-11-16T14:16:11Z DML. commit 0ab81dd184922eabb362a19c80757f67ea7763c3 Author: devozerov Date: 2018-11-16T14:24:54Z SQL. commit 02fe236eb1005ab9b7e0164bff9570c6b8612990 Author: devozerov Date: 2018-11-16T14:28:53Z Renames. commit 5f0dac97ca315aade75171bdd4d60932208106ca Author: devozerov Date: 2018-11-16T14:31:46Z WIP. commit b3ea9113de81a6d97d2a5acdf8881c966d186f3c Author: devozerov Date: 2018-11-16T14:35:48Z Minors. ---
[jira] [Created] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
Vladimir Ozerov created IGNITE-10299: Summary: SQL: Extract SELECT and DML plan caches into single class Key: IGNITE-10299 URL: https://issues.apache.org/jira/browse/IGNITE-10299 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 In future we will need to merge plans for both DML and SELECTs (both local and distributed) into a single entity. This ticket is the first part of this effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5413: IGNITE-10295 Added info logging for long connecti...
GitHub user voropava opened a pull request: https://github.com/apache/ignite/pull/5413 IGNITE-10295 Added info logging for long connection establish methods⦠â¦, removed useless logging of Sending Full Message. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10295 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5413.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 #5413 commit da856f3883c76276eb034cfbea70a7beb85ea8d8 Author: Pavel Voronkin Date: 2018-11-09T12:00:03Z IGNITE-10295 Added info logging for long connection establish methods, removed useless logging of Sending Full Message. ---
[GitHub] ignite pull request #5412: IGNITE-10260: MVCC: GetAndPutIfAbsent operation r...
GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5412 IGNITE-10260: MVCC: GetAndPutIfAbsent operation return no result. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10260 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5412.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 #5412 commit 4053db079dffe1352b3df93e93020c028eff43be Author: Andrey V. Mashenkov Date: 2018-11-16T14:27:56Z IGNITE-10260: Fix getAndPutIfAbsent. ---
Re: Brainstorm: Make TC Run All faster
At one of the meetups, Vladimir Ozerov has said that we may specify and move less risky to be broken tests in separate build plan which will be executed daily or weekly For example tests of compatibility with different JDK versions or compatibility between Ignite's releases. Also, I agree with Denis we should find and remove tests with the same checks. By the way, if someone of the community donates TC agents, can this help to reduce the time? On Thu, Nov 15, 2018 at 5:38 PM Yakov Zhdanov wrote: > > Denis, you can go even further. E.g. you can start topology once for the > full set of single threaded full api cache tests. Each test should start > cache dynamically and run it logic. > > As for me, I would think of splitting RunAll to 2 steps - one containing > basic tests and another with more complex tests. 2nd step should not start > (except manually) if 1st step results in any build failure. > > --Yakov -- Best Regards, Vyacheslav D.
[jira] [Created] (IGNITE-10297) Investigate possibility of restricting API of Upstream transformer
Artem Malykh created IGNITE-10297: - Summary: Investigate possibility of restricting API of Upstream transformer Key: IGNITE-10297 URL: https://issues.apache.org/jira/browse/IGNITE-10297 Project: Ignite Issue Type: Improvement Components: ml Reporter: Artem Malykh Assignee: Artem Malykh Signature of 'transform' method of UpstreamTransformer is Stream -> Stream. For now it is used only for bagging and for that purpose, UpstreamEntry -> Stream would suffice (just use 'flatMap' on upstream), maybe we should change signature to this form. From other hand, we'll cut some possibilities like limiting of upstream. This question needs investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10296) Change API of UpstreamTransformer to make it accept LearningEnvironment.
Artem Malykh created IGNITE-10296: - Summary: Change API of UpstreamTransformer to make it accept LearningEnvironment. Key: IGNITE-10296 URL: https://issues.apache.org/jira/browse/IGNITE-10296 Project: Ignite Issue Type: Improvement Components: ml Reporter: Artem Malykh Assignee: Artem Malykh For now UpstreamTransformer uses Random object as parameter to be able to fix it's behaviour through seeding. This goal should be reached by using random number generator from learning environment (IGNITE-10272). So, UpstreamTransformer should be result of work of UpstreamTransformerBuilder (LearningEnvironment -> UpstreamTransformer) or something like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Time to remove automated messages from the devlist?
I also would like to separate all the automated stuff. Sergi пт, 16 нояб. 2018 г. в 13:58, Павлухин Иван : > Oleg, > > I join to Dmitriy. I found your summary quite interesting. > пт, 16 нояб. 2018 г. в 13:12, Dmitriy Pavlov : > > > > Oleg, > > > > excellent research! It allows me to avoid bothering community developers > > once again. > > > > Thank you for your efforts and for contributing to this discussion. > > > > Sincerely, > > Dmitriy Pavlov > > > > чт, 15 нояб. 2018 г. в 23:14, Denis Magda : > > > > > Let's move git notifications to a separate list. As for JIRA, not sure > it > > > bothers me, it took me several minutes to set up all the filters to > spread > > > the messages out across specific folders. Otherwise, some of us might > > > ignore subscribing to jira-list and would miss notifications when their > > > input is needed. > > > > > > -- > > > Denis > > > > > > On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov > > > > wrote: > > > > > > > Dmitry, > > > > > > > > I am not referring to some "authoritative ASF member" as a guide for > us. > > > We > > > > are on our own. What I meant is that at some point in time we were > > > pointed > > > > to an idea, that tons of automated messages has nothing to do with > > > healthy > > > > community. Which seems pretty reasonable to me. > > > > > > > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov > > > > wrote: > > > > > > > > > What incubator mentor do you refer to? Incubator member are asf > members > > > > as > > > > > well. > > > > > > > > > > I was involved at least to 3 discussions at the list started from > Jira > > > > > issue created. > > > > > > > > > > If others were not involved, it do not convince me its is not > useful to > > > > > keep forwarding. > > > > > > > > > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov >: > > > > > > > > > > > Dmitry, > > > > > > > > > > > > What Apache member do you refer to? > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov >: > > > > > > > > > > > > > How do you know what to watch if new tickets are not forwarded? > > > > > > > > > > > > > > Again, PRs are ok to remove since it is duplicate to jira, but > jira > > > > > > removal > > > > > > > does not make any sense for me. > > > > > > > > > > > > > > Com dev folks instead suggest to forward all comments and all > > > > activity > > > > > > from > > > > > > > github to the list. So if Apache member will confirm it is not > > > useful > > > > > to > > > > > > > allow dev. list watchers see new issues on the list we can > continue > > > > > > > discussion. Openness is needed not for veterans but for all > > > community > > > > > > > members and users who is subscribed to the list. > > > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn < > ptupit...@apache.org>: > > > > > > > > > > > > > > > Personal emails for _watched_ JIRA tickets are very useful. > > > > > > > > Emails to everyone are not. > > > > > > > > > > > > > > > > +1 for separate mailing list for all automated emails. > > > > > > > > I don't think we can avoid automated emails completely, but > dev > > > > list > > > > > > > should > > > > > > > > be human-only. > > > > > > > > So separate list is the only way. > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov < > > > > > voze...@gridgain.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Completely agree with Denis. Tons of generated messages and > > > > > community > > > > > > > > > health are not relevant. Currently we obviously have too > much > > > > > tickets > > > > > > > and > > > > > > > > > too little communications. This is bad. But whether we > > > accumulate > > > > > > > > generated > > > > > > > > > stuff here or in some other place is not important at all, > > > > provided > > > > > > > that > > > > > > > > we > > > > > > > > > can point dev-list readers to JIRA channel. And as far as > > > > generated > > > > > > > > stuff, > > > > > > > > > this was one of very serious concerns of our mentors during > > > > > > incubation > > > > > > > > > phase - too many tickets, too little real communications. > > > > Splitting > > > > > > > > message > > > > > > > > > flows will help us understand where we are. > > > > > > > > > > > > > > > > > > And another very interesting thing is how PMCs treat all > these > > > > > > > messages - > > > > > > > > > they ignore them. When I come with that problem, one PMC > > > proposed > > > > > > > > solution > > > > > > > > > - "just filter them like I do". Then I, another PMC, > answered - > > > > "I > > > > > do > > > > > > > not > > > > > > > > > know how to filter them". Finally, third PMC, who also > filters > > > > > these > > > > > > > > > messages, helped me create proper filter in GMail. > > > > > > > > > > > > > > > > > > Isn't it demonstrative enough that so many PMC, who are > > > expected > > > > to > > > > > > > > > understand project very well and follow a lot of > activities, > > > find > > > >
[GitHub] asfgit closed pull request #69: IGNITE-10243 Chain analysis entry points are get now from preloaded b…
asfgit closed pull request #69: IGNITE-10243 Chain analysis entry points are get now from preloaded b… URL: https://github.com/apache/ignite-teamcity-bot/pull/69 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (IGNITE-10295) Rework Sending Full Message logging.
Pavel Voronkin created IGNITE-10295: --- Summary: Rework Sending Full Message logging. Key: IGNITE-10295 URL: https://issues.apache.org/jira/browse/IGNITE-10295 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5411: IGNITE-8379 Add maven-surefire-plugin support for...
GitHub user daradurvs opened a pull request: https://github.com/apache/ignite/pull/5411 IGNITE-8379 Add maven-surefire-plugin support for PDS Compatibility tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/daradurvs/ignite ignite-8379 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5411.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 #5411 commit fb00b524aebfe4a48dc39ad98d6fb7aa245cf1c1 Author: Vyacheslav Daradur Date: 2018-11-16T13:07:55Z Introduced support precompilled artifacts; refactoring ---
[GitHub] ignite pull request #5410: IGNITE-10197 unexpected IllegalArgumentException ...
GitHub user ibessonov opened a pull request: https://github.com/apache/ignite/pull/5410 IGNITE-10197 unexpected IllegalArgumentException in IgniteDbPutGetAbstractTest#testRandomPutGetRemove You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10197 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5410.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 #5410 commit 5b2aedaf37f0fca7fd3f322bcabb774a7c3e61f4 Author: ibessonov Date: 2018-11-16T12:52:25Z IGNITE-10197 "testRandomPutGetRemove" test method was uncommented. ---
[GitHub] ignite pull request #5399: IGNITE-10273: Fixed retrieval of affinity mapping
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5399 ---
[GitHub] ignite pull request #5409: IGNITE-10263: MVCC: Concurrent cache stop can cau...
GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5409 IGNITE-10263: MVCC: Concurrent cache stop can cause vacuum failure. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10263 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5409.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 #5409 commit eb2033ba67b69565c80edfb26e26ef3ba1825f20 Author: Andrey V. Mashenkov Date: 2018-11-16T10:14:00Z IGNITE-10263: Skip entry belonged to stopped cache. commit 7f671f33a146335a7a77a2f153cd5741fb0eac81 Author: Andrey V. Mashenkov Date: 2018-11-16T10:14:00Z IGNITE-10263: Skip entry belonged to stopped cache. commit 408e9c788fe97e02f1a44bdd68d908fe6423d0b9 Author: Andrey V. Mashenkov Date: 2018-11-16T10:26:19Z Merge remote-tracking branch 'origin/ignite-10263' into ignite-10263 ---
Re: proposed design for thin client SQL management and monitoring (view running queries and kill it)
I fully agree with last sentences and can start to implement this part. Guys, thanks for your productive participate at discussion. пт, 16 нояб. 2018 г. в 2:53, Denis Magda : > Vladimir, > > Thanks, make perfect sense to me. > > > On Thu, Nov 15, 2018 at 12:18 AM Vladimir Ozerov > wrote: > > > Denis, > > > > The idea is that QueryDetailMetrics will be exposed through separate > > "historical" SQL view in addition to current API. So we are on the same > > page here. > > > > As far as query ID I do not see any easy way to operate on a single > integer > > value (even 64bit). This is distributed system - we do not want to have > > coordination between nodes to get query ID. And coordination is the only > > possible way to get sexy "long". Instead, I would propose to form ID from > > node order and query counter within node. This will be (int, long) pair. > > For use convenience we may convert it to a single string, e.g. > > "[node_order].[query_counter]". Then the syntax would be: > > > > KILL QUERY '25.1234'; // Kill query 1234 on node 25 > > KILL QUERY '25.*; // Kill all queries on the node 25 > > > > Makes sense? > > > > Vladimir. > > > > On Wed, Nov 14, 2018 at 1:25 PM Denis Magda wrote: > > > > > Yury, > > > > > > As I understand you mean that the view should contains both running and > > > > finished queries. If be honest for the view I was going to use just > > > queries > > > > running right now. For finished queries I thought about another view > > with > > > > another set of fields which should include I/O related ones. Is it > > works? > > > > > > > > > Got you, so if only running queries are there then your initial > proposal > > > makes total sense. Not sure we need a view of the finished queries. It > > will > > > be possible to analyze them through the updated DetailedMetrics > approach, > > > won't it? > > > > > > For "KILL QUERY node_id query_id" node_id required as part of unique > key > > > > of query and help understand Ignite which node start the distributed > > > query. > > > > Use both parameters will allow cheap generate unique key across all > > > nodes. > > > > Node which started a query can cancel it on all nodes participate > > nodes. > > > > So, to stop any queries initially we need just send the cancel > request > > to > > > > node who started the query. This mechanism is already in Ignite. > > > > > > > > > Can we locate node_id behind the scenes if the user supplies query_id > > only? > > > A query record in the view already contains query_id and node_id and it > > > sounds like an extra work for the user to fill in all the details for > us. > > > Embed node_id into query_id if you'd like to avoid extra network hops > for > > > query_id to node_id mapping. > > > > > > -- > > > Denis > > > > > > On Wed, Nov 14, 2018 at 1:04 AM Юрий > > wrote: > > > > > > > Denis, > > > > > > > > Under the hood 'time' will be as startTime, but for system view I > > planned > > > > use duration which will be simple calculated as now - startTime. So, > > > there > > > > is't a performance issue. > > > > As I understand you mean that the view should contains both running > and > > > > finished queries. If be honest for the view I was going to use just > > > queries > > > > running right now. For finished queries I thought about another view > > with > > > > another set of fields which should include I/O related ones. Is it > > works? > > > > > > > > For "KILL QUERY node_id query_id" node_id required as part of unique > > key > > > > of query and help understand Ignite which node start the distributed > > > query. > > > > Use both parameters will allow cheap generate unique key across all > > > nodes. > > > > Node which started a query can cancel it on all nodes participate > > nodes. > > > > So, to stop any queries initially we need just send the cancel > request > > to > > > > node who started the query. This mechanism is already in Ignite. > > > > > > > > Native SQL APIs will automatically support the futures after > > implementing > > > > for thin clients. So we are good here. > > > > > > > > > > > > > > > > вт, 13 нояб. 2018 г. в 18:52, Denis Magda : > > > > > > > > > Yury, > > > > > > > > > > Please consider the following: > > > > > > > > > >- If we record the duration instead of startTime, then the > former > > > has > > > > to > > > > >be updated frequently - sounds like a performance red flag. > Should > > > we > > > > > store > > > > >startTime and endTime instead? This way a query record will be > > > updated > > > > >twice - when the query is started and terminated. > > > > >- In the IEP you've mentioned I/O related fields that should > help > > to > > > > >grasp why a query runs that slow. Should they be stored in this > > > view? > > > > >- "KILL QUERY query_id" is more than enough. Let's not add > > "node_id" > > > > >unless it's absolutely required. Our queries are distributed and > > > > > executed > > > > >across several nodes that's w
Re: Time to remove automated messages from the devlist?
Oleg, I join to Dmitriy. I found your summary quite interesting. пт, 16 нояб. 2018 г. в 13:12, Dmitriy Pavlov : > > Oleg, > > excellent research! It allows me to avoid bothering community developers > once again. > > Thank you for your efforts and for contributing to this discussion. > > Sincerely, > Dmitriy Pavlov > > чт, 15 нояб. 2018 г. в 23:14, Denis Magda : > > > Let's move git notifications to a separate list. As for JIRA, not sure it > > bothers me, it took me several minutes to set up all the filters to spread > > the messages out across specific folders. Otherwise, some of us might > > ignore subscribing to jira-list and would miss notifications when their > > input is needed. > > > > -- > > Denis > > > > On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov > > wrote: > > > > > Dmitry, > > > > > > I am not referring to some "authoritative ASF member" as a guide for us. > > We > > > are on our own. What I meant is that at some point in time we were > > pointed > > > to an idea, that tons of automated messages has nothing to do with > > healthy > > > community. Which seems pretty reasonable to me. > > > > > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov > > > wrote: > > > > > > > What incubator mentor do you refer to? Incubator member are asf members > > > as > > > > well. > > > > > > > > I was involved at least to 3 discussions at the list started from Jira > > > > issue created. > > > > > > > > If others were not involved, it do not convince me its is not useful to > > > > keep forwarding. > > > > > > > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov : > > > > > > > > > Dmitry, > > > > > > > > > > What Apache member do you refer to? > > > > > > > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov : > > > > > > > > > > > How do you know what to watch if new tickets are not forwarded? > > > > > > > > > > > > Again, PRs are ok to remove since it is duplicate to jira, but jira > > > > > removal > > > > > > does not make any sense for me. > > > > > > > > > > > > Com dev folks instead suggest to forward all comments and all > > > activity > > > > > from > > > > > > github to the list. So if Apache member will confirm it is not > > useful > > > > to > > > > > > allow dev. list watchers see new issues on the list we can continue > > > > > > discussion. Openness is needed not for veterans but for all > > community > > > > > > members and users who is subscribed to the list. > > > > > > > > > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn : > > > > > > > > > > > > > Personal emails for _watched_ JIRA tickets are very useful. > > > > > > > Emails to everyone are not. > > > > > > > > > > > > > > +1 for separate mailing list for all automated emails. > > > > > > > I don't think we can avoid automated emails completely, but dev > > > list > > > > > > should > > > > > > > be human-only. > > > > > > > So separate list is the only way. > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov < > > > > voze...@gridgain.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Completely agree with Denis. Tons of generated messages and > > > > community > > > > > > > > health are not relevant. Currently we obviously have too much > > > > tickets > > > > > > and > > > > > > > > too little communications. This is bad. But whether we > > accumulate > > > > > > > generated > > > > > > > > stuff here or in some other place is not important at all, > > > provided > > > > > > that > > > > > > > we > > > > > > > > can point dev-list readers to JIRA channel. And as far as > > > generated > > > > > > > stuff, > > > > > > > > this was one of very serious concerns of our mentors during > > > > > incubation > > > > > > > > phase - too many tickets, too little real communications. > > > Splitting > > > > > > > message > > > > > > > > flows will help us understand where we are. > > > > > > > > > > > > > > > > And another very interesting thing is how PMCs treat all these > > > > > > messages - > > > > > > > > they ignore them. When I come with that problem, one PMC > > proposed > > > > > > > solution > > > > > > > > - "just filter them like I do". Then I, another PMC, answered - > > > "I > > > > do > > > > > > not > > > > > > > > know how to filter them". Finally, third PMC, who also filters > > > > these > > > > > > > > messages, helped me create proper filter in GMail. > > > > > > > > > > > > > > > > Isn't it demonstrative enough that so many PMC, who are > > expected > > > to > > > > > > > > understand project very well and follow a lot of activities, > > find > > > > it > > > > > > > useful > > > > > > > > to *remove* JIRA emails from their inboxes in order to ... well > > > ... > > > > > > > > understand what is going on. If Ignite veterans do not find > > these > > > > > > > generated > > > > > > > > emails useful, then I do not know who else can benefit from > > them. > > > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov < > > > > > > dmekhani...@gmail.com> > > > >
[GitHub] ignite pull request #5408: IGNITE-10294
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5408 IGNITE-10294 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10294 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5408.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 #5408 commit 97b139ccac96b8e00f2a8ebf70279ff13248d5f5 Author: devozerov Date: 2018-11-16T10:34:28Z Fixed. ---
[jira] [Created] (IGNITE-10294) SQL: subjectId is lost for SqlFieldsQuery event on local node
Vladimir Ozerov created IGNITE-10294:
Summary: SQL: subjectId is lost for SqlFieldsQuery event on local
node
Key: IGNITE-10294
URL: https://issues.apache.org/jira/browse/IGNITE-10294
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
See {{GridQueryProcessor.sendQueryExecutedEvent}} - we pass {{null}} as subject
ID. Need to fix it to local node ID.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Time to remove automated messages from the devlist?
Oleg, excellent research! It allows me to avoid bothering community developers once again. Thank you for your efforts and for contributing to this discussion. Sincerely, Dmitriy Pavlov чт, 15 нояб. 2018 г. в 23:14, Denis Magda : > Let's move git notifications to a separate list. As for JIRA, not sure it > bothers me, it took me several minutes to set up all the filters to spread > the messages out across specific folders. Otherwise, some of us might > ignore subscribing to jira-list and would miss notifications when their > input is needed. > > -- > Denis > > On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov > wrote: > > > Dmitry, > > > > I am not referring to some "authoritative ASF member" as a guide for us. > We > > are on our own. What I meant is that at some point in time we were > pointed > > to an idea, that tons of automated messages has nothing to do with > healthy > > community. Which seems pretty reasonable to me. > > > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov > > wrote: > > > > > What incubator mentor do you refer to? Incubator member are asf members > > as > > > well. > > > > > > I was involved at least to 3 discussions at the list started from Jira > > > issue created. > > > > > > If others were not involved, it do not convince me its is not useful to > > > keep forwarding. > > > > > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov : > > > > > > > Dmitry, > > > > > > > > What Apache member do you refer to? > > > > > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov : > > > > > > > > > How do you know what to watch if new tickets are not forwarded? > > > > > > > > > > Again, PRs are ok to remove since it is duplicate to jira, but jira > > > > removal > > > > > does not make any sense for me. > > > > > > > > > > Com dev folks instead suggest to forward all comments and all > > activity > > > > from > > > > > github to the list. So if Apache member will confirm it is not > useful > > > to > > > > > allow dev. list watchers see new issues on the list we can continue > > > > > discussion. Openness is needed not for veterans but for all > community > > > > > members and users who is subscribed to the list. > > > > > > > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn : > > > > > > > > > > > Personal emails for _watched_ JIRA tickets are very useful. > > > > > > Emails to everyone are not. > > > > > > > > > > > > +1 for separate mailing list for all automated emails. > > > > > > I don't think we can avoid automated emails completely, but dev > > list > > > > > should > > > > > > be human-only. > > > > > > So separate list is the only way. > > > > > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov < > > > voze...@gridgain.com> > > > > > > wrote: > > > > > > > > > > > > > Completely agree with Denis. Tons of generated messages and > > > community > > > > > > > health are not relevant. Currently we obviously have too much > > > tickets > > > > > and > > > > > > > too little communications. This is bad. But whether we > accumulate > > > > > > generated > > > > > > > stuff here or in some other place is not important at all, > > provided > > > > > that > > > > > > we > > > > > > > can point dev-list readers to JIRA channel. And as far as > > generated > > > > > > stuff, > > > > > > > this was one of very serious concerns of our mentors during > > > > incubation > > > > > > > phase - too many tickets, too little real communications. > > Splitting > > > > > > message > > > > > > > flows will help us understand where we are. > > > > > > > > > > > > > > And another very interesting thing is how PMCs treat all these > > > > > messages - > > > > > > > they ignore them. When I come with that problem, one PMC > proposed > > > > > > solution > > > > > > > - "just filter them like I do". Then I, another PMC, answered - > > "I > > > do > > > > > not > > > > > > > know how to filter them". Finally, third PMC, who also filters > > > these > > > > > > > messages, helped me create proper filter in GMail. > > > > > > > > > > > > > > Isn't it demonstrative enough that so many PMC, who are > expected > > to > > > > > > > understand project very well and follow a lot of activities, > find > > > it > > > > > > useful > > > > > > > to *remove* JIRA emails from their inboxes in order to ... well > > ... > > > > > > > understand what is going on. If Ignite veterans do not find > these > > > > > > generated > > > > > > > emails useful, then I do not know who else can benefit from > them. > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov < > > > > > dmekhani...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > > > > > > I do believe Igniters can set up a filter. > > > > > > > > I doesn't mean we should make them do it. > > > > > > > > > > > > > > > > How do JIRA messages help? > > > > > > > > If you want do discuss something – write to dev list. > > > > > > > > If you want a code review – write to dev list. > > > > > >
[GitHub] ignite pull request #5407: Ignite-10217
GitHub user ygerzhedovich opened a pull request: https://github.com/apache/ignite/pull/5407 Ignite-10217 Ignite-10217 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10217 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5407.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 #5407 commit bdb44a6afb1819baebe0e8e11d1be0d798a42ae1 Author: Yury Gerzhedovich Date: 2018-09-07T09:07:28Z IGNITE-8386: PK indexes don't use wrapped object for table created from SQL commit c9bbaee50fe22e94811085b994b8c190b8951d96 Author: Yury Gerzhedovich Date: 2018-09-07T09:11:18Z Merge branch 'master' into ignite-8386 commit 07c4bd82b934b793603bb9ab98709170d2d2a499 Author: Yury Gerzhedovich Date: 2018-09-07T09:38:09Z IGNITE-8386: PK indexes don't use wrapped object for table created from SQL commit b570babde131f838a63c5b7faf4a7e9c55990d59 Author: Yury Gerzhedovich Date: 2018-09-07T09:40:35Z IGNITE-8386: minor fix commit 3cbd5f2d93a2377f2eb26fb9a90b18adbdd03088 Author: Yury Gerzhedovich Date: 2018-09-18T09:49:46Z Merge branch 'master' into ignite-8386 commit 20e1e74647a10fbcffccc28c423db785bbff781f Author: Yury Gerzhedovich Date: 2018-09-18T14:11:53Z IGNITE-8386: fix of determination if key is complex type or not commit 31e3abd0019cc57c09ec3f26f2414a2b909ae41c Author: Yury Gerzhedovich Date: 2018-09-18T14:13:18Z Merge branch 'master' into ignite-8386 commit 2ef2ca08c15be3955eac97b2260649fd9a18aacb Author: Yury Gerzhedovich Date: 2018-09-19T09:04:15Z Merge branch 'master' into ignite-8386 commit b9c98c0dc2f2e469309ed3219661eee567c856b9 Author: Yury Gerzhedovich Date: 2018-09-20T08:02:59Z Merge remote-tracking branch 'origin/master' into ignite-8386 commit f565d4eb31235d29a84ca80521cf16c04e2a66a8 Author: Yury Gerzhedovich Date: 2018-09-20T08:21:58Z Merge branch 'master' into ignite-8386 commit 32900026187e2a3e63e17bb6e36067ee848be00a Author: devozerov Date: 2018-10-29T14:01:28Z Merge. commit f987371c494f4acb6fccf46371299daedec13bb4 Author: devozerov Date: 2018-10-29T14:01:37Z Merge. commit 4bee027829ac65a81be7107be982bec200e654a0 Author: devozerov Date: 2018-10-29T14:04:16Z Added test to test suite. commit a161f4544a933624a8147d812190e6ed0813928f Author: devozerov Date: 2018-10-29T14:09:21Z WIP. commit 965fe9425e5e398534505f6d812a0aaad4f3ae8e Author: Yury Gerzhedovich Date: 2018-11-01T08:45:54Z Merge branch 'master' into ignite-8386 # Conflicts: # modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java commit 44c0dd3f13219c941dc793e98b266f1e52eb8b03 Author: Yury Gerzhedovich Date: 2018-11-02T09:34:46Z Merge branch 'master' into ignite-8386 commit 3cce96ccaca7145a080f92eacaebf918f348e0fa Author: Yury Gerzhedovich Date: 2018-11-06T08:54:37Z ignite-8386: migration support for unwrapped PK indexes. commit 00e8abd941acfa034149a087fc74dcde5a2d0971 Author: Yury Gerzhedovich Date: 2018-11-06T09:05:39Z Merge branch 'master' into ignite-8386 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java # modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java commit 0845235b250f7c156043c9e792a58468a332ffa9 Author: Yury Gerzhedovich Date: 2018-11-06T09:11:23Z ignite-8386: minor fix after merge. commit 42f92f949d48e85a6d280816c72d52a6b2c63188 Author: Yury Gerzhedovich Date: 2018-11-12T08:10:18Z Merge branch 'master' into ignite-8386 # Conflicts: # modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java commit d747730ebc38891f0c8a6995999e67a270792470 Author: Yury Gerzhedovich Date: 2018-11-13T10:54:36Z Merge branch 'master' into ignite-8386 commit a758369fe646bb2da26bfec21581c109bbf9c08f Author: Yury Gerzhedovich Date: 2018-11-15T14:30:59Z Merge branch 'master' into ignite-10217 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java commit f6ef039e9100880816cc71a4a0e74495b20df9be Author: Yury Gerzhedovich Date: 2018-11-16T09:14:06Z ignite-10217: Unwrap _KEY for secondary and affinity_key indexes commit 5d11d84f83976b532208791952d35a365863a19a Author: Yury Gerzhedovich Date: 2018-11-16T09:14:38Z Merge branch 'master' into ignite-10217 ---
[GitHub] ignite pull request #5406: Ignite-10217
Github user joooger closed the pull request at: https://github.com/apache/ignite/pull/5406 ---
[GitHub] ignite pull request #5406: Ignite-10217
GitHub user joooger opened a pull request: https://github.com/apache/ignite/pull/5406 Ignite-10217 Ignite-10217 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10217 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5406.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 #5406 commit bdb44a6afb1819baebe0e8e11d1be0d798a42ae1 Author: Yury Gerzhedovich Date: 2018-09-07T09:07:28Z IGNITE-8386: PK indexes don't use wrapped object for table created from SQL commit c9bbaee50fe22e94811085b994b8c190b8951d96 Author: Yury Gerzhedovich Date: 2018-09-07T09:11:18Z Merge branch 'master' into ignite-8386 commit 07c4bd82b934b793603bb9ab98709170d2d2a499 Author: Yury Gerzhedovich Date: 2018-09-07T09:38:09Z IGNITE-8386: PK indexes don't use wrapped object for table created from SQL commit b570babde131f838a63c5b7faf4a7e9c55990d59 Author: Yury Gerzhedovich Date: 2018-09-07T09:40:35Z IGNITE-8386: minor fix commit 3cbd5f2d93a2377f2eb26fb9a90b18adbdd03088 Author: Yury Gerzhedovich Date: 2018-09-18T09:49:46Z Merge branch 'master' into ignite-8386 commit 20e1e74647a10fbcffccc28c423db785bbff781f Author: Yury Gerzhedovich Date: 2018-09-18T14:11:53Z IGNITE-8386: fix of determination if key is complex type or not commit 31e3abd0019cc57c09ec3f26f2414a2b909ae41c Author: Yury Gerzhedovich Date: 2018-09-18T14:13:18Z Merge branch 'master' into ignite-8386 commit 2ef2ca08c15be3955eac97b2260649fd9a18aacb Author: Yury Gerzhedovich Date: 2018-09-19T09:04:15Z Merge branch 'master' into ignite-8386 commit b9c98c0dc2f2e469309ed3219661eee567c856b9 Author: Yury Gerzhedovich Date: 2018-09-20T08:02:59Z Merge remote-tracking branch 'origin/master' into ignite-8386 commit f565d4eb31235d29a84ca80521cf16c04e2a66a8 Author: Yury Gerzhedovich Date: 2018-09-20T08:21:58Z Merge branch 'master' into ignite-8386 commit 32900026187e2a3e63e17bb6e36067ee848be00a Author: devozerov Date: 2018-10-29T14:01:28Z Merge. commit f987371c494f4acb6fccf46371299daedec13bb4 Author: devozerov Date: 2018-10-29T14:01:37Z Merge. commit 4bee027829ac65a81be7107be982bec200e654a0 Author: devozerov Date: 2018-10-29T14:04:16Z Added test to test suite. commit a161f4544a933624a8147d812190e6ed0813928f Author: devozerov Date: 2018-10-29T14:09:21Z WIP. commit 965fe9425e5e398534505f6d812a0aaad4f3ae8e Author: Yury Gerzhedovich Date: 2018-11-01T08:45:54Z Merge branch 'master' into ignite-8386 # Conflicts: # modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java commit 44c0dd3f13219c941dc793e98b266f1e52eb8b03 Author: Yury Gerzhedovich Date: 2018-11-02T09:34:46Z Merge branch 'master' into ignite-8386 commit 3cce96ccaca7145a080f92eacaebf918f348e0fa Author: Yury Gerzhedovich Date: 2018-11-06T08:54:37Z ignite-8386: migration support for unwrapped PK indexes. commit 00e8abd941acfa034149a087fc74dcde5a2d0971 Author: Yury Gerzhedovich Date: 2018-11-06T09:05:39Z Merge branch 'master' into ignite-8386 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java # modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java commit 0845235b250f7c156043c9e792a58468a332ffa9 Author: Yury Gerzhedovich Date: 2018-11-06T09:11:23Z ignite-8386: minor fix after merge. commit 42f92f949d48e85a6d280816c72d52a6b2c63188 Author: Yury Gerzhedovich Date: 2018-11-12T08:10:18Z Merge branch 'master' into ignite-8386 # Conflicts: # modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java commit d747730ebc38891f0c8a6995999e67a270792470 Author: Yury Gerzhedovich Date: 2018-11-13T10:54:36Z Merge branch 'master' into ignite-8386 commit a758369fe646bb2da26bfec21581c109bbf9c08f Author: Yury Gerzhedovich Date: 2018-11-15T14:30:59Z Merge branch 'master' into ignite-10217 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java commit f6ef039e9100880816cc71a4a0e74495b20df9be Author: Yury Gerzhedovich Date: 2018-11-16T09:14:06Z ignite-10217: Unwrap _KEY for secondary and affinity_key indexes commit 5d11d84f83976b532208791952d35a365863a19a Author: Yury Gerzhedovich Date: 2018-11-16T09:14:38Z Merge branch 'master' into ignite-10217 ---
[jira] [Created] (IGNITE-10293) VisorNodeDataCollectorJob should not collect caches info on inactive cluster
Alexey Kuznetsov created IGNITE-10293: - Summary: VisorNodeDataCollectorJob should not collect caches info on inactive cluster Key: IGNITE-10293 URL: https://issues.apache.org/jira/browse/IGNITE-10293 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.8 When cluster is inactive, caches not available, so - no need to try to collect info. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10292) ML: Replace IGFS by model storage for TensorFlow
Anton Dmitriev created IGNITE-10292: --- Summary: ML: Replace IGFS by model storage for TensorFlow Key: IGNITE-10292 URL: https://issues.apache.org/jira/browse/IGNITE-10292 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.8 Reporter: Anton Dmitriev Fix For: 2.8 Currently we have a TensorFlow IGFS plugin that provides a file system functionality (see https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/ignite). At the same time IGFS is deprecated and would be great to replace it by a simple model storage based on cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10291) Unable to find row by index created on partial baseline topology
Pavel Vinokurov created IGNITE-10291: Summary: Unable to find row by index created on partial baseline topology Key: IGNITE-10291 URL: https://issues.apache.org/jira/browse/IGNITE-10291 Project: Ignite Issue Type: Bug Components: cache, sql Affects Versions: 2.6, 2.5, 2.4 Reporter: Pavel Vinokurov Attachments: Reproducer.java Steps to reproduce: 1. Start two nodes cluster with persistence. 2. Create table CREATE TABLE PERSON ( FIRST_NAME VARCHAR, LAST_NAME VARCHAR, ADDRESS VARCHAR, LANG VARCHAR, BIRTH_DATE TIMESTAMP, CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, value_type=PersonValueType, AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" Insert 1000 rows. 3. Stop the second node. 4. Create index create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) 5. Start the second node 6. Perform select query for each row: select * from PERSON use index(PERSON_FIRST_NAME_IDX) where FIRST_NAME=? and LAST_NAME=? and ADDRESS=? and LANG = ? Result: The select doesn't return row in half of cases. The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [MTCGA]: new failures in builds [2327011] needs to be handled
Expected failure. Muted. On Fri, Nov 16, 2018 at 6:20 AM wrote: > 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 > IgniteCacheLockPartitionOnAffinityRunTest.testSingleCache > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=475277171234191079&branch=%3Cdefault%3E&tab=testDetails > Changes may lead to failure were done by > - isapego > https://ci.ignite.apache.org//viewModification.html?modId=265274 > - alexey.goncharuk > https://ci.ignite.apache.org//viewModification.html?modId=265721 > - isapego > https://ci.ignite.apache.org//viewModification.html?modId=265179 > - dmitriy.govorukhin > https://ci.ignite.apache.org//viewModification.html?modId=26 > - spiderru5597 > https://ci.ignite.apache.org//viewModification.html?modId=264337 > - irakov > https://ci.ignite.apache.org//viewModification.html?modId=265720 > - spiderru5597 > https://ci.ignite.apache.org//viewModification.html?modId=265040 > - ppozerov > https://ci.ignite.apache.org//viewModification.html?modId=265966 > > - 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 06:20:27 16-11-2018 >
Re: [MTCGA]: new failures in builds [2323069] needs to be handled
Expected failure. Muted. On Fri, Nov 16, 2018 at 12:35 AM wrote: > 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 > IgniteCacheReplicatedQueryEvtsDisabledSelfTest.testSqlQueryEvents > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6915392932418459317&branch=%3Cdefault%3E&tab=testDetails > > *New test failure in master > IgniteCacheReplicatedQueryP2PDisabledSelfTest.testSqlQueryEvents > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-393492269618641229&branch=%3Cdefault%3E&tab=testDetails > > *New test failure in master > IgniteCacheReplicatedQuerySelfTest.testSqlQueryEvents > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=2363137591361112031&branch=%3Cdefault%3E&tab=testDetails > Changes may lead to failure were done by > - ygerzhedovich > https://ci.ignite.apache.org//viewModification.html?modId=263959 > - vozerov > https://ci.ignite.apache.org//viewModification.html?modId=263853 > - vozerov > https://ci.ignite.apache.org//viewModification.html?modId=263956 > > - 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 00:35:13 16-11-2018 >
Re: [MTCGA]: new failures in builds [2323068] needs to be handled
Expected failure. Muted. On Fri, Nov 16, 2018 at 12:21 AM wrote: > 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 > IgniteCacheReplicatedQueryP2PDisabledSelfTest.testSqlQueryEvents > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1328782023632161768&branch=%3Cdefault%3E&tab=testDetails > > *New test failure in master > IgniteCacheReplicatedQuerySelfTest.testSqlQueryEvents > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8379349225494042650&branch=%3Cdefault%3E&tab=testDetails > > *New test failure in master > IgniteCacheReplicatedQueryEvtsDisabledSelfTest.testSqlQueryEvents > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8210650449325388796&branch=%3Cdefault%3E&tab=testDetails > Changes may lead to failure were done by > - ygerzhedovich > https://ci.ignite.apache.org//viewModification.html?modId=263959 > - vozerov > https://ci.ignite.apache.org//viewModification.html?modId=263853 > - vozerov > https://ci.ignite.apache.org//viewModification.html?modId=263956 > > - 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 00:21:14 16-11-2018 >
