[jira] [Created] (IGNITE-12737) Incorrect annotation on TxDeadlockCauseTest

[Nikolai Kulagin (Jira)]

Nikolai Kulagin created IGNITE-12737:


 Summary: Incorrect annotation on TxDeadlockCauseTest
 Key: IGNITE-12737
 URL: https://issues.apache.org/jira/browse/IGNITE-12737
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolai Kulagin


Method TxDeadlockCauseTest#testCauseObject() have annotation 
{color:#ffab00}@Test{color}, but it is not a test case. As a result, JUnit can 
run no one test in this class and printed error.
{code:java}
java.lang.Exception: Method testCauseObject should have no parameters.{code}
Most likely TxDeadlockCauseTest.class was commented on in the suite 
TxDeadlockDetectionTestSuite because of this.

I suggest:
1. Delete the annotation {color:#ffab00}@Test{color};
2. Fix the tests in TxDeadlockCauseTest (3 tests look good, 1 test fails);
3. Uncomment the TxDeadlockCauseTest in the suite.
 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [Apache Ignite Integrations Documentation] Added ALB documentation.

[Denis Magda]

Emmanouil, thanks, I've reviewed and merged the changes!

-
Denis


On Sun, Mar 1, 2020 at 4:30 PM ReadMe  wrote:

> *Emmanouil Gkatziouras* suggested edits to page *Amazon AWS Discovery*.
>
> +++ Added: 27
>
> --- Removed: 2
>
> *Added ALB documentation.*
>
> Documentation for the new Ignite ALB finder
> View Suggested Edits
> 
> — ReadMe
> Follow@readme  on Twitter.· Unsubscribe
> 
> from notifications
>

Re: Ignite 2.8 documentation

[Denis Magda]

Hi Alexey,

Thanks for updating the documentation. The update process is cumbersome as
of now. What will happen is that we will be replacing the content of the
current pages (pre 2.8 pages) with the content from the 2.8 versions. Once
the text is copied manually, a 2.8 version of the page will be deleted. I
would advise Artem to do that this time and update the wiki page with more
details:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document

Also, why should we release this page?
https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms

-
Denis


On Sun, Mar 1, 2020 at 7:59 AM Alexey Zinoviev 
wrote:

> Hi, Igniters, I've finished the ML documentation.
>
> I have the issue that, for example I've created a new version of page with
> postfix -2.8 and the page name contains this postfix.
> How are we going to replace the URL? Or we will replace the content from
> initial page?
>
> For example, I've created the new version of page
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees and
> moved it under new page
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/decision-trees-28
> How it will be processed to obtain the  decision-trees url for the new
> page?
>
>
> In all case the full list of removed/replaced pages for ML is next:
>
> In the release 2.8, please remove the pages
>
>1.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/genetic-algorithms
>
>2.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-multi-class-classification
>
>3. DeepLearning block with 3 pages
>4.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-cross-validation
>
>
> Next pages were replaced with postfix 2.8 and grouped under new pages
>
>1.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/machine-learning
>
>2.
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/preprocessing
>
>3.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/ols-multiple-linear-regression
>
>4.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/k-means-clustering
>
>5.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/multilayer-perceptron
>
>6.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-classification
>
>7.
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/knn-regression
>
>8.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/svm-binary-classification
>
>9.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/logistic-regression
>
>10.
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/random-forest
>
>11.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/gradient-boosting
>
>12.
>https://dash.readme.io/project/apacheignite/v2.7.6/docs/model-updating
>13.
>
> https://dash.readme.io/project/apacheignite/v2.7.6/docs/ann-approximate-nearest-neighbor
>
>
>
>
> ср, 26 февр. 2020 г. в 03:32, Denis Magda :
>
> > Hi Prasad,
> >
> > This is odd behavior and before changing the docs I would try to get to
> the
> > bottom. Let me join the user list conversation.
> >
> > -
> > Denis
> >
> >
> > On Tue, Feb 25, 2020 at 3:46 AM Prasad Bhalerao <
> > prasadbhalerao1...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Can we have this behavior documented? This will help user to design
> their
> > > caches appropriately.
> > >
> > > *For Replicated Cache:*
> > >
> > > Reference mail thread:
> > >
> > >
> >
> http://apache-ignite-users.70518.x6.nabble.com/Read-through-not-working-as-expected-in-case-of-Replicated-cache-td29990.html
> > >
> > >  read through for replicated cache would work where there is either:
> > > - writeThrough enabled and all changes do through it.
> > > - database contents do not change for already read keys.
> > >
> > > Thanks,
> > > Prasad
> > >
> > > On Mon, Feb 24, 2020 at 7:31 PM Alexey Zinoviev <
> zaleslaw@gmail.com>
> > > wrote:
> > >
> > > > Please, could you post in this thread a few examples of the
> > documentation
> > > > tickets in JIRA for the current release, to create them correctly?
> > > >
> > > > пн, 24 февр. 2020 г. в 14:53, Alexey Zinoviev <
> zaleslaw@gmail.com
> > >:
> > > >
> > > > > Ok, will make ticket, no problemo
> > > > >
> > > > > вс, 23 февр. 2020 г., 23:28 Denis Magda :
> > > > >
> > > > >> Alex, thanks for helping with the documentation. Frankly, the
> > tickets
> > > > >> will be useful to get a complete list of all the updates pages
> with
> > > the
> > > > >> goal of extracting info for blog post(s) - we'll be preparing at
> > least
> > > > one
> > > > >> blog for Ignite 2.8 and can create an ML specific blog as well.
> > Also,
> > > > the
> > > > >> tickets might simplify the review process between you and Artem.
> > > > >>
> > > > >> -
> > > > >> Denis
> > > > >>
> > > > >>
> > > > >> On Sat, Feb 22, 2020 at 2:18 AM Alexey Zinoviev <
> > > zaleslaw@gmail.c

[RESULT] [VOTE] Release Apache Ignite 2.8.0 RC1

[Maxim Muzafarov]

Dear community,


The vote for a new release candidate is closed, now.
Vote result: The vote PASSES with 6 votes +1 (6 bindings), 0 two votes
and no -1.


+1 votes:
- Denis Magda (binding)
- Anton Vinogradov (binding)
- Pavel Tupitsyn (binding)
- Ivan Pavlukhin (binding)
- Alexey Zinoviev (binding)
- Nikolay Izhikov (binding)

0 votes:
- Ilya Kasnacheev (binding)
- Sergey Antonov


Vote thread:
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html

[jira] [Created] (IGNITE-12736) [IEP-35] Compute task system view doesn't return task started from remote node

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12736:


 Summary: [IEP-35] Compute task system view doesn't return task 
started from remote node
 Key: IGNITE-12736
 URL: https://issues.apache.org/jira/browse/IGNITE-12736
 Project: Ignite
  Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
 Fix For: 2.8


Bug reproducer:
{code:java}
@Test
public void testComputeBroadcast2() throws Exception {
try (IgniteEx g0 = startGrid(0); IgniteEx g1 = startClientGrid(1)) {
SystemView tasks = 
g0.context().systemView().view(TASKS_VIEW);

g1.compute().broadcastAsync(() -> {
try {
Thread.sleep(60_000L);
}
catch (InterruptedException e) {
throw new RuntimeException(e);
}
});

Thread.sleep(1_000L);

assertEquals(1, tasks.size());
}
}

{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Who can merge excessive backups warning ticket?

[Alexey Goncharuk]

Agree - this is basically what I meant. We should resolve it as 2.9 and
then form the scope for 2.8.1. Sorry for the confusion.

пн, 2 мар. 2020 г. в 19:26, Maxim Muzafarov :

> Folks,
>
>
> I think the issue should be merged into the master branch first (2.9).
> I pinned some critical issues to 2.8.1 which are, from my point, have
> to be fixed in 2.8 but still not due to lack of contributions. Since
> the scope for 2.8.1 is not fixed and not discussed yet the goal for
> such tasks is 2.9.
>
>
> On Mon, 2 Mar 2020 at 19:20, Alexey Goncharuk
>  wrote:
> >
> > Ivan,
> >
> > Unless I missed something, we do not even have a scope for 2.8.1. As I
> > recall, there were some important changes that did not get to 2.8.0. As
> the
> > voting is close to finish, I think we can kick off a discussion for
> 2.8.1?
>

Re: Reference of local service.

[Denis Mekhanikov]

Vyacheslav,

You can't make service interfaces extend
*org.apache.ignite.services.Service*. Currently it works perfectly if
*org.apache.ignite.services.Service* and a user-defined interface are
independent. This is actually the case in our current examples:
https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/servicegrid/SimpleMapService.java
I mentioned the *Serializable* interface just as an example of an interface
that can be present, but it's not the one that is going to be called by a
user.

What I'm trying to say is that there is no way to say whether the service
is going to be used through a proxy only, or usage of a local instance is
also possible.

Vladimir,

I don't like the idea, that enabling or disabling of metrics will change
the behaviour of the component you collect the metrics for. Such behaviour
is far from obvious.

Nikolay,

I agree, that such approach is valid and makes total sense. But making the
*IgniteServices#serviceProxy()* method always return a proxy instead of a
local instance will change the public contract. The javadoc currently says
the following:

> If service is available locally, then local instance is returned,
> otherwise, a remote proxy is dynamically created and provided for the
> specified service.


I propose introducing a new method that will always return a service proxy
regardless of local availability, and deprecating *serviceProxy()* and
*service()
*methods. What do you think?

Denis

пн, 2 мар. 2020 г. в 16:08, Nikolay Izhikov :

> Hello, Vladimir.
>
> > What if we just provide an option to disable service metrics at all?
>
> I don't think we should create an explicit property for service metrics.
> We will implement the way to disable any metrics in the scope of
> IGNITE-11927 [1].
>
> > Usage of a proxy instead of service instances can lead to performance
> > degradation for local instances, which is another argument against such
> change.
>
> As far as I know, many and many modern frameworks use a proxy approach.
> Just to name one - Spring framework works with the proxy.
>
> We should measure the impact on the performance that brings proxy+metric
> and after it make the decision on local service metrics implementation.
> Vladimir, can you, as a contributor of this task make this measurement?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11927
>
> пн, 2 мар. 2020 г. в 12:56, Vladimir Steshin :
>
> > Denis, Vyacheslav, hi.
> >
> > What if we just provide an option to disable service metrics at all? It
> > would keep direct references for local services. Also, we can make
> service
> > metrics disabled by default to keep current code working. A warning of
> > local service issues will be set with the option.
> >
> > пн, 2 мар. 2020 г. в 11:26, Vyacheslav Daradur :
> >
> > > >> Moreover, I don't see a way of implementing such a check. Are you
> > going
> > > to look just for any interface? What about Serializable? Will it do?
> > >
> > > The check should look for the interface which implements
> > > "org.apache.ignite.services.Service", it covers the requirement to be
> > > Serializable.
> > >
> > > >> For now though the best thing we can do is to calculate remote
> > > invocations only, since all of them go through a proxy.
> > >
> > > Let's introduce a system property to manage local services monitoring:
> > > - local services monitoring will be disabled by default - to avoid any
> > > backward compatibility issues;
> > > - local services monitoring can be enabled runtime with a known
> > limitation
> > > for new services for example;
> > > Moreover, if we introduce such a feature flag to ServiceConfiguration -
> > > the new feature can be enabled per service separately.
> > >
> > > What do you think?
> > >
> > >
> > >
> > > On Mon, Mar 2, 2020 at 12:33 AM Denis Mekhanikov <
> dmekhani...@gmail.com>
> > > wrote:
> > >
> > >> Vladimir, Slava,
> > >>
> > >> In general, I like the idea of abstracting the service deployment from
> > >> its usage, but there are some backward-compatibility considerations
> that
> > >> won't let us do so.
> > >>
> > >> Or we can declare usage of services without interfaces incorrect
> > >>
> > >>
> > >> I don't think we can introduce a requirement for all services to have
> an
> > >> interface, unfortunately. Such change can potentially break existing
> > code,
> > >> since such requirement doesn't exist currently.
> > >> Moreover, I don't see a way of implementing such a check. Are you
> going
> > >> to look just for any interface? What about Serializable? Will it do?
> > >>
> > >> Usage of a proxy instead of service instances can lead to performance
> > >> degradation for local instances, which is another argument against
> such
> > >> change.
> > >>
> > >> I think, it will make sense to make all service invocations work
> through
> > >> a proxy in Ignite 3.
> > >> For now though the best thing we can do is to calculate remote
> > >> invocations only, since all of them go through a

Re: Premissions to upload a release to official releases directory

[Maxim Muzafarov]

Nikolay,


Thank you for offering help.
I'll back to you tomorrow.

On Mon, 2 Mar 2020 at 18:59, Denis Magda  wrote:
>
> Nikolay, thanks for offering to help with this step of the process. If
> Maxim is fine then I would let you publish the artifacts.
>
> The docs should be completed this week and we need to develop the practice
> to announce releases only after technical pages are updated and available.
> The vote can run in parallel. Ignite users need to have a full release
> package once a release is published - binaries, Docker images,
> documentation, release notes, etc.
>
>
> -
> Denis
>
>
> On Mon, Mar 2, 2020 at 7:54 AM Nikolay Izhikov  wrote:
>
> > I thought documentation can be updated after the release.
> > Isn’t it?
> >
> > > Is there anybody who can do that?
> >
> > I can do it.
> >
> >
> > > 2 марта 2020 г., в 18:44, Maxim Muzafarov 
> > написал(а):
> > >
> > > Denis,
> > >
> > > Thank you, I think yes.
> > > But I don't expect that the release will be delayed since we still
> > > need some time for documentation preparation.
> > >
> > > On Mon, 2 Mar 2020 at 18:40, Denis Magda  wrote:
> > >>
> > >> Hi Maxim,
> > >>
> > >> This sounds like an option but can take delay the release for more than
> > a
> > >> week. Alternatively, someone from the PMC group can execute this step
> > for
> > >> you. Is there anybody who can do that?
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Mon, Mar 2, 2020 at 6:21 AM Maxim Muzafarov 
> > wrote:
> > >>
> > >>> Ignite PMCs,
> > >>>
> > >>>
> > >>> Hopefully, if not the current release voting, but one of the next one
> > >>> get success soon we'll get the 2.8.0 release candidate accepted.
> > >>>
> > >>> To execute the next release scripts for an accepted release candidate
> > >>> (release_*.sh from a release archive) I need some permissions to
> > >>> upload a release candidate to official release directory. According to
> > >>> Apache documentation [1]: "The PMC can also vote to let
> > >>> non-PMC-members update the dist/release area. To get this set up,
> > >>> please open a JIRA ticket at the INFRA JIRA referencing the PMC vote."
> > >>>
> > >>> As the release manager of Apache Ignite 2.8, I ask your help if you
> > >>> consider it necessary to give me the required agreement for upload
> > >>> release. After that, I'll file a JIRA ticket to INFRA.
> > >>>
> > >>>
> > >>> [1] http://www.apache.org/legal/release-policy.html#upload-ci
> > >>>
> >
> >

Re: Who can merge excessive backups warning ticket?

[Maxim Muzafarov]

Folks,


I think the issue should be merged into the master branch first (2.9).
I pinned some critical issues to 2.8.1 which are, from my point, have
to be fixed in 2.8 but still not due to lack of contributions. Since
the scope for 2.8.1 is not fixed and not discussed yet the goal for
such tasks is 2.9.


On Mon, 2 Mar 2020 at 19:20, Alexey Goncharuk
 wrote:
>
> Ivan,
>
> Unless I missed something, we do not even have a scope for 2.8.1. As I
> recall, there were some important changes that did not get to 2.8.0. As the
> voting is close to finish, I think we can kick off a discussion for 2.8.1?

Re: Who can merge excessive backups warning ticket?

[Alexey Goncharuk]

Ivan,

Unless I missed something, we do not even have a scope for 2.8.1. As I
recall, there were some important changes that did not get to 2.8.0. As the
voting is close to finish, I think we can kick off a discussion for 2.8.1?

Re: Permissions to edit Apache Ignite documentation

[Denis Magda]

Maxim,

Please stay in touch with Artem If you'd like to release Ignite 2.8 docs.
It's a bit complicated with readme and either Artem can complete this step
or he can collaborate with you letting you experience it. Anyway, before we
release 2.8 version of the docs we need to finish the pages. Here is a bit
more on the process:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document#HowtoDocument-Readme.ioDocsforaNextRelease

-
Denis


On Mon, Mar 2, 2020 at 7:57 AM Nikolay Izhikov  wrote:

> Just made you an administrator of Ignite documentation site.
>
> > 2 марта 2020 г., в 18:54, Maxim Muzafarov 
> написал(а):
> >
> > login: maxmu...@gmail.com
> >
> > On Mon, 2 Mar 2020 at 18:54, Maxim Muzafarov  wrote:
> >>
> >> Igniters,
> >>
> >>
> >> Can anyone give permissions to edit\publish documentation Apache
> >> Ignite pages [1]?
> >>
> >>
> >> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-6.3.4.Releasedocumentaiononreadme.io
>
>

Re: Who can merge excessive backups warning ticket?

[Ivan Pavlukhin]

Folks,

Faced a trouble before resolving the ticket [1]. Fix version is set to
2.8.1 and I suppose some changes from master will be cherry-picked to
2.8.1 branch. Do we have 2.8.1 branch?

Best regards,
Ivan Pavlukhin

пн, 2 мар. 2020 г. в 18:42, Ivan Pavlukhin :
>
> Merged to master.
>
> Best regards,
> Ivan Pavlukhin
>
> пн, 2 мар. 2020 г. в 18:41, Denis Magda :
> >
> > Alex Schrbakov,
> >
> > As a reviewer, could you merge the changes?
> >
> >
> > -
> > Denis
> >
> >
> > On Mon, Mar 2, 2020 at 6:15 AM Zhenya Stanilovsky
> >  wrote:
> >
> > >
> > > Hello, no objections found, plz who can merge it [1]?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12725
> > >
> > >
> > >

Re: Premissions to upload a release to official releases directory

[Denis Magda]

Nikolay, thanks for offering to help with this step of the process. If
Maxim is fine then I would let you publish the artifacts.

The docs should be completed this week and we need to develop the practice
to announce releases only after technical pages are updated and available.
The vote can run in parallel. Ignite users need to have a full release
package once a release is published - binaries, Docker images,
documentation, release notes, etc.


-
Denis


On Mon, Mar 2, 2020 at 7:54 AM Nikolay Izhikov  wrote:

> I thought documentation can be updated after the release.
> Isn’t it?
>
> > Is there anybody who can do that?
>
> I can do it.
>
>
> > 2 марта 2020 г., в 18:44, Maxim Muzafarov 
> написал(а):
> >
> > Denis,
> >
> > Thank you, I think yes.
> > But I don't expect that the release will be delayed since we still
> > need some time for documentation preparation.
> >
> > On Mon, 2 Mar 2020 at 18:40, Denis Magda  wrote:
> >>
> >> Hi Maxim,
> >>
> >> This sounds like an option but can take delay the release for more than
> a
> >> week. Alternatively, someone from the PMC group can execute this step
> for
> >> you. Is there anybody who can do that?
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Mon, Mar 2, 2020 at 6:21 AM Maxim Muzafarov 
> wrote:
> >>
> >>> Ignite PMCs,
> >>>
> >>>
> >>> Hopefully, if not the current release voting, but one of the next one
> >>> get success soon we'll get the 2.8.0 release candidate accepted.
> >>>
> >>> To execute the next release scripts for an accepted release candidate
> >>> (release_*.sh from a release archive) I need some permissions to
> >>> upload a release candidate to official release directory. According to
> >>> Apache documentation [1]: "The PMC can also vote to let
> >>> non-PMC-members update the dist/release area. To get this set up,
> >>> please open a JIRA ticket at the INFRA JIRA referencing the PMC vote."
> >>>
> >>> As the release manager of Apache Ignite 2.8, I ask your help if you
> >>> consider it necessary to give me the required agreement for upload
> >>> release. After that, I'll file a JIRA ticket to INFRA.
> >>>
> >>>
> >>> [1] http://www.apache.org/legal/release-policy.html#upload-ci
> >>>
>
>

Re: Permissions to edit Apache Ignite documentation

[Nikolay Izhikov]

Just made you an administrator of Ignite documentation site.

> 2 марта 2020 г., в 18:54, Maxim Muzafarov  написал(а):
> 
> login: maxmu...@gmail.com
> 
> On Mon, 2 Mar 2020 at 18:54, Maxim Muzafarov  wrote:
>> 
>> Igniters,
>> 
>> 
>> Can anyone give permissions to edit\publish documentation Apache
>> Ignite pages [1]?
>> 
>> 
>> [1] 
>> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-6.3.4.Releasedocumentaiononreadme.io

Re: Premissions to upload a release to official releases directory

[Nikolay Izhikov]

I thought documentation can be updated after the release. 
Isn’t it?

> Is there anybody who can do that?

I can do it.


> 2 марта 2020 г., в 18:44, Maxim Muzafarov  написал(а):
> 
> Denis,
> 
> Thank you, I think yes.
> But I don't expect that the release will be delayed since we still
> need some time for documentation preparation.
> 
> On Mon, 2 Mar 2020 at 18:40, Denis Magda  wrote:
>> 
>> Hi Maxim,
>> 
>> This sounds like an option but can take delay the release for more than a
>> week. Alternatively, someone from the PMC group can execute this step for
>> you. Is there anybody who can do that?
>> 
>> -
>> Denis
>> 
>> 
>> On Mon, Mar 2, 2020 at 6:21 AM Maxim Muzafarov  wrote:
>> 
>>> Ignite PMCs,
>>> 
>>> 
>>> Hopefully, if not the current release voting, but one of the next one
>>> get success soon we'll get the 2.8.0 release candidate accepted.
>>> 
>>> To execute the next release scripts for an accepted release candidate
>>> (release_*.sh from a release archive) I need some permissions to
>>> upload a release candidate to official release directory. According to
>>> Apache documentation [1]: "The PMC can also vote to let
>>> non-PMC-members update the dist/release area. To get this set up,
>>> please open a JIRA ticket at the INFRA JIRA referencing the PMC vote."
>>> 
>>> As the release manager of Apache Ignite 2.8, I ask your help if you
>>> consider it necessary to give me the required agreement for upload
>>> release. After that, I'll file a JIRA ticket to INFRA.
>>> 
>>> 
>>> [1] http://www.apache.org/legal/release-policy.html#upload-ci
>>> 

Re: Permissions to edit Apache Ignite documentation

[Maxim Muzafarov]

login: maxmu...@gmail.com

On Mon, 2 Mar 2020 at 18:54, Maxim Muzafarov  wrote:
>
> Igniters,
>
>
> Can anyone give permissions to edit\publish documentation Apache
> Ignite pages [1]?
>
>
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-6.3.4.Releasedocumentaiononreadme.io

Permissions to edit Apache Ignite documentation

[Maxim Muzafarov]

Igniters,


Can anyone give permissions to edit\publish documentation Apache
Ignite pages [1]?


[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-6.3.4.Releasedocumentaiononreadme.io

Re: [VOTE] Release Apache Ignite 2.8.0 RC1

[Nikolay Izhikov]

+1 (binding)

* compiled from source.
* start node from bin distribution.
* check thin driver and made some SQL queries with it.

> 2 марта 2020 г., в 17:33, Sergey Antonov  
> написал(а):
> 
> 0.
> Still can't get access to teamcity links.
> 
> пн, 2 мар. 2020 г., 17:24 Alexey Zinoviev :
> 
>> +1 (binding)
>> I've downloaded the binary archive, run it, checked the ML examples and
>> JavaDocs.
>> 
>> 
>> 
>> вс, 1 мар. 2020 г. в 13:49, Ivan Pavlukhin :
>> 
>>> +1 (binding)
>>> 
>>> Downloaded binary distribution archive, launched a cluster of 2 nodes,
>>> created/filled/queried a table using sqlline.
>>> 
>>> A couple of minor problems along the way (nothing critical to block
>>> the release):
>>> 1. Shell scripts in bin directory (ignite.sh, sqlline.sh, etc.) have
>>> no "execute" permission after extracting. Had to call "chmod +x"
>>> manually.
>>> 2. Query syntax errors with stacktraces are written to default console
>>> output.
>>> 
>>> Best regards,
>>> Ivan Pavlukhin
>>> 
>>> вс, 1 мар. 2020 г. в 11:23, Pavel Tupitsyn :
 
 +1 (binding)
 
 Started .NET nodes and examples, installed NuGet packages and started
 Ignite from there
 
 On Sat, Feb 29, 2020 at 11:28 PM Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com>
 wrote:
 
> Hello!
> 
> 0 (binding)
> 
> I have checked deb package, built and run C++, ran dotnet example and
> sqlline.
> 
> It is unfortunate that we still haven't improved release layout: we
>>> still
> do not ship automake-processed C++, and provide no slim binary
> redistributable.
> 
> Regards,
> --
> Ilya Kasnacheev
> 
> 
> сб, 29 февр. 2020 г. в 13:18, Anton Vinogradov :
> 
>> +1 (binding)
>> 
>> Checked
>> - TC usage completeness and results,
>> - Urls correctness and content
>> 
>> On Fri, Feb 28, 2020 at 7:50 PM Denis Magda 
>>> wrote:
>> 
>>> +1 (binding)
>>> 
>>> Downloaded, started a cluster, ran several examples pulling Maven
>>> artifacts from the staging.
>>> 
>>> 
>>> -
>>> Denis
>>> 
>>> 
>>> On Fri, Feb 28, 2020 at 7:09 AM Maxim Muzafarov <
>> mmu...@apache.org
 
>> wrote:
>>> 
 Dear Community,
 
 
 I have uploaded a release candidate to:
 https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/
 
>>> https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/
 
 The following staging can be used for testing:
 
>> 
>>> https://repository.apache.org/content/repositories/orgapacheignite-1474/
 
 Tag with name 2.8.0-rc1 created:
 
 
>>> 
>> 
> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6
 
 Release 2.8 contains a lot of changes, please refer to the
>> RELEASE_NOTES:
 
 
>>> 
>> 
> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.8
 
 Complete list of resolved issues:
 
 
>>> 
>> 
> 
>>> 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8%20and%20status%20%3D%20Resolved%20and%20resolution%20%3D%20Fixed%20order%20by%20updated
 
 DEVNOTES
 
 
>>> 
>> 
> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.8
 
 
 Additional checks have been performed (available for users
>>> included
 into the release group on TeamCity).
 
 TC [Check RC: Licenses, compile, chksum]
 
 
>>> 
>> 
> 
>>> 
>> https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
 
 TC [3] Build & Upload Nuget Staging Packages
 
 
>>> 
>> 
> 
>>> 
>> https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv
 
 TC [2] Compare w/ Previous Release
 
 
>>> 
>> 
> 
>>> 
>> https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv
 
 
 The vote is formal, see voting guidelines
 https://www.apache.org/foundation/voting.html
 
 +1 - to accept Apache Ignite 2.8.0-rc1
 0 - don't care either way
 -1 - DO NOT accept Apache Ignite Ignite 2.8.0-rc1 (explain why)
 
 See notes on how to verify release here
 https://www.apache.org/info/verification.html
 and
 
>>> 
>> 
> 
>>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/Re

Re: Premissions to upload a release to official releases directory

[Maxim Muzafarov]

Denis,

Thank you, I think yes.
But I don't expect that the release will be delayed since we still
need some time for documentation preparation.

On Mon, 2 Mar 2020 at 18:40, Denis Magda  wrote:
>
> Hi Maxim,
>
> This sounds like an option but can take delay the release for more than a
> week. Alternatively, someone from the PMC group can execute this step for
> you. Is there anybody who can do that?
>
> -
> Denis
>
>
> On Mon, Mar 2, 2020 at 6:21 AM Maxim Muzafarov  wrote:
>
> > Ignite PMCs,
> >
> >
> > Hopefully, if not the current release voting, but one of the next one
> > get success soon we'll get the 2.8.0 release candidate accepted.
> >
> > To execute the next release scripts for an accepted release candidate
> > (release_*.sh from a release archive) I need some permissions to
> > upload a release candidate to official release directory. According to
> > Apache documentation [1]: "The PMC can also vote to let
> > non-PMC-members update the dist/release area. To get this set up,
> > please open a JIRA ticket at the INFRA JIRA referencing the PMC vote."
> >
> > As the release manager of Apache Ignite 2.8, I ask your help if you
> > consider it necessary to give me the required agreement for upload
> > release. After that, I'll file a JIRA ticket to INFRA.
> >
> >
> > [1] http://www.apache.org/legal/release-policy.html#upload-ci
> >

Re: Who can merge excessive backups warning ticket?

[Ivan Pavlukhin]

Merged to master.

Best regards,
Ivan Pavlukhin

пн, 2 мар. 2020 г. в 18:41, Denis Magda :
>
> Alex Schrbakov,
>
> As a reviewer, could you merge the changes?
>
>
> -
> Denis
>
>
> On Mon, Mar 2, 2020 at 6:15 AM Zhenya Stanilovsky
>  wrote:
>
> >
> > Hello, no objections found, plz who can merge it [1]?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12725
> >
> >
> >

Re: Who can merge excessive backups warning ticket?

[Denis Magda]

Alex Schrbakov,

As a reviewer, could you merge the changes?


-
Denis


On Mon, Mar 2, 2020 at 6:15 AM Zhenya Stanilovsky
 wrote:

>
> Hello, no objections found, plz who can merge it [1]?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12725
>
>
>

Re: Premissions to upload a release to official releases directory

[Denis Magda]

Hi Maxim,

This sounds like an option but can take delay the release for more than a
week. Alternatively, someone from the PMC group can execute this step for
you. Is there anybody who can do that?

-
Denis


On Mon, Mar 2, 2020 at 6:21 AM Maxim Muzafarov  wrote:

> Ignite PMCs,
>
>
> Hopefully, if not the current release voting, but one of the next one
> get success soon we'll get the 2.8.0 release candidate accepted.
>
> To execute the next release scripts for an accepted release candidate
> (release_*.sh from a release archive) I need some permissions to
> upload a release candidate to official release directory. According to
> Apache documentation [1]: "The PMC can also vote to let
> non-PMC-members update the dist/release area. To get this set up,
> please open a JIRA ticket at the INFRA JIRA referencing the PMC vote."
>
> As the release manager of Apache Ignite 2.8, I ask your help if you
> consider it necessary to give me the required agreement for upload
> release. After that, I'll file a JIRA ticket to INFRA.
>
>
> [1] http://www.apache.org/legal/release-policy.html#upload-ci
>

Re: [VOTE] Release Apache Ignite 2.8.0 RC1

[Sergey Antonov]

0.
Still can't get access to teamcity links.

пн, 2 мар. 2020 г., 17:24 Alexey Zinoviev :

> +1 (binding)
> I've downloaded the binary archive, run it, checked the ML examples and
> JavaDocs.
>
>
>
> вс, 1 мар. 2020 г. в 13:49, Ivan Pavlukhin :
>
> > +1 (binding)
> >
> > Downloaded binary distribution archive, launched a cluster of 2 nodes,
> > created/filled/queried a table using sqlline.
> >
> > A couple of minor problems along the way (nothing critical to block
> > the release):
> > 1. Shell scripts in bin directory (ignite.sh, sqlline.sh, etc.) have
> > no "execute" permission after extracting. Had to call "chmod +x"
> > manually.
> > 2. Query syntax errors with stacktraces are written to default console
> > output.
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> > вс, 1 мар. 2020 г. в 11:23, Pavel Tupitsyn :
> > >
> > > +1 (binding)
> > >
> > > Started .NET nodes and examples, installed NuGet packages and started
> > > Ignite from there
> > >
> > > On Sat, Feb 29, 2020 at 11:28 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > 0 (binding)
> > > >
> > > > I have checked deb package, built and run C++, ran dotnet example and
> > > > sqlline.
> > > >
> > > > It is unfortunate that we still haven't improved release layout: we
> > still
> > > > do not ship automake-processed C++, and provide no slim binary
> > > > redistributable.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > сб, 29 февр. 2020 г. в 13:18, Anton Vinogradov :
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > Checked
> > > > > - TC usage completeness and results,
> > > > > - Urls correctness and content
> > > > >
> > > > > On Fri, Feb 28, 2020 at 7:50 PM Denis Magda 
> > wrote:
> > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > Downloaded, started a cluster, ran several examples pulling Maven
> > > > > > artifacts from the staging.
> > > > > >
> > > > > >
> > > > > > -
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Fri, Feb 28, 2020 at 7:09 AM Maxim Muzafarov <
> mmu...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Dear Community,
> > > > > > >
> > > > > > >
> > > > > > > I have uploaded a release candidate to:
> > > > > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/
> > > > > > >
> > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/
> > > > > > >
> > > > > > > The following staging can be used for testing:
> > > > > > >
> > > > >
> > https://repository.apache.org/content/repositories/orgapacheignite-1474/
> > > > > > >
> > > > > > > Tag with name 2.8.0-rc1 created:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6
> > > > > > >
> > > > > > > Release 2.8 contains a lot of changes, please refer to the
> > > > > RELEASE_NOTES:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.8
> > > > > > >
> > > > > > > Complete list of resolved issues:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8%20and%20status%20%3D%20Resolved%20and%20resolution%20%3D%20Fixed%20order%20by%20updated
> > > > > > >
> > > > > > > DEVNOTES
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.8
> > > > > > >
> > > > > > >
> > > > > > > Additional checks have been performed (available for users
> > included
> > > > > > > into the release group on TeamCity).
> > > > > > >
> > > > > > > TC [Check RC: Licenses, compile, chksum]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
> > > > > > >
> > > > > > > TC [3] Build & Upload Nuget Staging Packages
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv
> > > > > > >
> > > > > > > TC [2] Compare w/ Previous Release
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv
> > > > > > >
> > > > > > >
> > > > > > > The vote is formal, see voting guidelines
> > > > > > > https://www.apache.org/foundation/voting.html
> > > > > > >
> > > > > > > +1 - to accept Apache Ignite 2.8.0-rc1
> > > > > > > 0 - don't care either way
> > > > > > > -1 - DO NOT accept Apache Ignite Ignite 2.8.0-rc1 (explain why)
> > > > > > >
> > > > > > > See notes on how to verify release here
> > > > > > > https://www.

[jira] [Created] (IGNITE-12735) Metric exporter implementation could lead to NullPointerException from gauge which invoke communication

[Andrey N. Gura (Jira)]

Andrey N. Gura created IGNITE-12735:
---

 Summary: Metric exporter implementation could lead to 
NullPointerException from gauge which invoke communication
 Key: IGNITE-12735
 URL: https://issues.apache.org/jira/browse/IGNITE-12735
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey N. Gura


{{ReadMetricsOnNodeStartupTest#testReadMetricsOnNodeStartup}} test fails 
sometimes. The reason is try to export gauge metric value while 
{{TcpCommunicationMetricsListener}} isn't initialized. 

**Proposed solution:**

Register metrics after export SPIs are already started.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release Apache Ignite 2.8.0 RC1

[Alexey Zinoviev]

+1 (binding)
I've downloaded the binary archive, run it, checked the ML examples and
JavaDocs.



вс, 1 мар. 2020 г. в 13:49, Ivan Pavlukhin :

> +1 (binding)
>
> Downloaded binary distribution archive, launched a cluster of 2 nodes,
> created/filled/queried a table using sqlline.
>
> A couple of minor problems along the way (nothing critical to block
> the release):
> 1. Shell scripts in bin directory (ignite.sh, sqlline.sh, etc.) have
> no "execute" permission after extracting. Had to call "chmod +x"
> manually.
> 2. Query syntax errors with stacktraces are written to default console
> output.
>
> Best regards,
> Ivan Pavlukhin
>
> вс, 1 мар. 2020 г. в 11:23, Pavel Tupitsyn :
> >
> > +1 (binding)
> >
> > Started .NET nodes and examples, installed NuGet packages and started
> > Ignite from there
> >
> > On Sat, Feb 29, 2020 at 11:28 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > 0 (binding)
> > >
> > > I have checked deb package, built and run C++, ran dotnet example and
> > > sqlline.
> > >
> > > It is unfortunate that we still haven't improved release layout: we
> still
> > > do not ship automake-processed C++, and provide no slim binary
> > > redistributable.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > сб, 29 февр. 2020 г. в 13:18, Anton Vinogradov :
> > >
> > > > +1 (binding)
> > > >
> > > > Checked
> > > > - TC usage completeness and results,
> > > > - Urls correctness and content
> > > >
> > > > On Fri, Feb 28, 2020 at 7:50 PM Denis Magda 
> wrote:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > Downloaded, started a cluster, ran several examples pulling Maven
> > > > > artifacts from the staging.
> > > > >
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Fri, Feb 28, 2020 at 7:09 AM Maxim Muzafarov  >
> > > > wrote:
> > > > >
> > > > > > Dear Community,
> > > > > >
> > > > > >
> > > > > > I have uploaded a release candidate to:
> > > > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/
> > > > > >
> https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/
> > > > > >
> > > > > > The following staging can be used for testing:
> > > > > >
> > > >
> https://repository.apache.org/content/repositories/orgapacheignite-1474/
> > > > > >
> > > > > > Tag with name 2.8.0-rc1 created:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6
> > > > > >
> > > > > > Release 2.8 contains a lot of changes, please refer to the
> > > > RELEASE_NOTES:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.8
> > > > > >
> > > > > > Complete list of resolved issues:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8%20and%20status%20%3D%20Resolved%20and%20resolution%20%3D%20Fixed%20order%20by%20updated
> > > > > >
> > > > > > DEVNOTES
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.8
> > > > > >
> > > > > >
> > > > > > Additional checks have been performed (available for users
> included
> > > > > > into the release group on TeamCity).
> > > > > >
> > > > > > TC [Check RC: Licenses, compile, chksum]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv
> > > > > >
> > > > > > TC [3] Build & Upload Nuget Staging Packages
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv
> > > > > >
> > > > > > TC [2] Compare w/ Previous Release
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv
> > > > > >
> > > > > >
> > > > > > The vote is formal, see voting guidelines
> > > > > > https://www.apache.org/foundation/voting.html
> > > > > >
> > > > > > +1 - to accept Apache Ignite 2.8.0-rc1
> > > > > > 0 - don't care either way
> > > > > > -1 - DO NOT accept Apache Ignite Ignite 2.8.0-rc1 (explain why)
> > > > > >
> > > > > > See notes on how to verify release here
> > > > > > https://www.apache.org/info/verification.html
> > > > > > and
> > > > > >
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > > > > >
> > > > > > The vote will hold for 72 hours and will end on March 2-nd 2020
> 15:10
> > > > UTC
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://www.timeanddate.com/countdown/generic?iso=20200302T181010&p0=166&msg=%5

Premissions to upload a release to official releases directory

[Maxim Muzafarov]

Ignite PMCs,


Hopefully, if not the current release voting, but one of the next one
get success soon we'll get the 2.8.0 release candidate accepted.

To execute the next release scripts for an accepted release candidate
(release_*.sh from a release archive) I need some permissions to
upload a release candidate to official release directory. According to
Apache documentation [1]: "The PMC can also vote to let
non-PMC-members update the dist/release area. To get this set up,
please open a JIRA ticket at the INFRA JIRA referencing the PMC vote."

As the release manager of Apache Ignite 2.8, I ask your help if you
consider it necessary to give me the required agreement for upload
release. After that, I'll file a JIRA ticket to INFRA.


[1] http://www.apache.org/legal/release-policy.html#upload-ci

Who can merge excessive backups warning ticket?

[Zhenya Stanilovsky]

Hello, no objections found, plz who can merge it [1]?
 
[1] https://issues.apache.org/jira/browse/IGNITE-12725
 
 
 

[jira] [Created] (IGNITE-12734) Scan query shutting down the node in some cases

[Aleksey Plekhanov (Jira)]

Aleksey Plekhanov created IGNITE-12734:
--

 Summary: Scan query shutting down the node in some cases
 Key: IGNITE-12734
 URL: https://issues.apache.org/jira/browse/IGNITE-12734
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov


Reproducer:

 
{code:java}
public class CachePartitionEvictionQueryTest extends GridCommonAbstractTest {
@Override protected IgniteConfiguration getConfiguration(String name) 
throws Exception {
return super.getConfiguration(name).setDataStorageConfiguration(new 
DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new 
DataRegionConfiguration().setPersistenceEnabled(true)));
}

@Override protected FailureHandler getFailureHandler(String 
igniteInstanceName) {
return new StopNodeFailureHandler();
}

@Test
public void testQuery() throws Exception {

startGrid(getConfiguration(getTestIgniteInstanceName(0)).setConsistentId("1"));

grid(0).cluster().active(true);

grid(0).cluster().baselineAutoAdjustEnabled(true);
grid(0).cluster().baselineAutoAdjustTimeout(0);

IgniteCache cache = grid(0).getOrCreateCache(
new CacheConfiguration(DEFAULT_CACHE_NAME).setBackups(0)
.setAffinity(new 
RendezvousAffinityFunction().setPartitions(2)));

cache.put(0, 0);
cache.put(1, 1);

Iterator iter = grid(0).cache(DEFAULT_CACHE_NAME).query(new 
ScanQuery<>().setPageSize(1)).iterator();

iter.next();


startGrid(getConfiguration(getTestIgniteInstanceName(1)).setConsistentId("0"));

awaitPartitionMapExchange();

forceCheckpoint(grid(0));

iter.next();
}
}

{code}
Node fails with the reason:

 
{noformat}
[2020-03-02 
15:17:46,663][ERROR][test-runner-#1%cache.CachePartitionEvictionQueryTest%][IgniteTestResources]
 Critical system error detected. Will be handled accordingly to configured 
handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler 
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class 
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is 
corrupted [pages(groupId, pageId)=[], msg=Runtime failure on bounds: 
[lower=null, upper=null
class 
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
 B+Tree is corrupted [pages(groupId, pageId)=[], msg=Runtime failure on bounds: 
[lower=null, upper=null]]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5927)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1054)
at 
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.find(CacheDataTree.java:164)
at 
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.find(CacheDataTree.java:63)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1021)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2914)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2884)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2878)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2866)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.cursor(GridCacheOffheapManager.java:2560)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.onHasNext(IgniteCacheOffheapManagerImpl.java:937)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3031)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:38)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
at 
org.apache.ignite.internal.processors.cache.AutoClosableCursorIterator.n

Re: Reference of local service.

[Nikolay Izhikov]

Hello, Vladimir.

> What if we just provide an option to disable service metrics at all?

I don't think we should create an explicit property for service metrics.
We will implement the way to disable any metrics in the scope of
IGNITE-11927 [1].

> Usage of a proxy instead of service instances can lead to performance
> degradation for local instances, which is another argument against such
change.

As far as I know, many and many modern frameworks use a proxy approach.
Just to name one - Spring framework works with the proxy.

We should measure the impact on the performance that brings proxy+metric
and after it make the decision on local service metrics implementation.
Vladimir, can you, as a contributor of this task make this measurement?

[1] https://issues.apache.org/jira/browse/IGNITE-11927

пн, 2 мар. 2020 г. в 12:56, Vladimir Steshin :

> Denis, Vyacheslav, hi.
>
> What if we just provide an option to disable service metrics at all? It
> would keep direct references for local services. Also, we can make service
> metrics disabled by default to keep current code working. A warning of
> local service issues will be set with the option.
>
> пн, 2 мар. 2020 г. в 11:26, Vyacheslav Daradur :
>
> > >> Moreover, I don't see a way of implementing such a check. Are you
> going
> > to look just for any interface? What about Serializable? Will it do?
> >
> > The check should look for the interface which implements
> > "org.apache.ignite.services.Service", it covers the requirement to be
> > Serializable.
> >
> > >> For now though the best thing we can do is to calculate remote
> > invocations only, since all of them go through a proxy.
> >
> > Let's introduce a system property to manage local services monitoring:
> > - local services monitoring will be disabled by default - to avoid any
> > backward compatibility issues;
> > - local services monitoring can be enabled runtime with a known
> limitation
> > for new services for example;
> > Moreover, if we introduce such a feature flag to ServiceConfiguration -
> > the new feature can be enabled per service separately.
> >
> > What do you think?
> >
> >
> >
> > On Mon, Mar 2, 2020 at 12:33 AM Denis Mekhanikov 
> > wrote:
> >
> >> Vladimir, Slava,
> >>
> >> In general, I like the idea of abstracting the service deployment from
> >> its usage, but there are some backward-compatibility considerations that
> >> won't let us do so.
> >>
> >> Or we can declare usage of services without interfaces incorrect
> >>
> >>
> >> I don't think we can introduce a requirement for all services to have an
> >> interface, unfortunately. Such change can potentially break existing
> code,
> >> since such requirement doesn't exist currently.
> >> Moreover, I don't see a way of implementing such a check. Are you going
> >> to look just for any interface? What about Serializable? Will it do?
> >>
> >> Usage of a proxy instead of service instances can lead to performance
> >> degradation for local instances, which is another argument against such
> >> change.
> >>
> >> I think, it will make sense to make all service invocations work through
> >> a proxy in Ignite 3.
> >> For now though the best thing we can do is to calculate remote
> >> invocations only, since all of them go through a proxy.
> >> Another option is to provide a simple way for a user to account the
> >> service invocations themselves.
> >>
> >> What do you guys think?
> >>
> >> Denis
> >>
> >>
> >> вт, 25 февр. 2020 г. в 16:50, Vyacheslav Daradur :
> >>
> >>> It is not a change of public API from my point of view.
> >>>
> >>> Also, there is a check to allow getting proxy only for an interface,
> not
> >>> implementation.
> >>>
> >>> Denis, what do you think?
> >>>
> >>>
> >>> вт, 25 февр. 2020 г. в 16:28, Vladimir Steshin :
> >>>
>  Vyacheslav, this is exactly what I found. I'm doing [1] (metrics for
>  services) and realized I have to wrap local calls by a proxy. Is it a
>  change of public API and should come with major release only? Or we
> can
>  declare usage of services without interfaces incorrect?
>  [1] https://issues.apache.org/jira/browse/IGNITE-12464
> 
>  вт, 25 февр. 2020 г. в 16:17, Vyacheslav Daradur  >:
> 
> > {IgniteServices#service(String name)} returns direct reference in the
> > current implementation.
> >
> > So, class casting should work for your example:
> > ((MyServiceImpl)ignite.services().service(“myService”)).bar();
> >
> > It is safer to use an interface instead of an implementation, there
> is
> > no guarantee that in future releases direct link will be returned, a
> > service instance might be wrapped for monitoring for example.
> >
> >
> > On Tue, Feb 25, 2020 at 4:09 PM Vladimir Steshin  >
> > wrote:
> >
> >> Vyacheslav, Hi.
> >>
> >> I see. But can we consider 'locally deployed service' is a proxy
> too,
> >> not direct reference? What if I need to wrap it? This would be local
> >> ser

[jira] [Created] (IGNITE-12733) File transmission must notify listeners when transmission ends and resources released

[Maxim Muzafarov (Jira)]

Maxim Muzafarov created IGNITE-12733:


 Summary: File transmission must notify listeners when transmission 
ends and resources released
 Key: IGNITE-12733
 URL: https://issues.apache.org/jira/browse/IGNITE-12733
 Project: Ignite
  Issue Type: Bug
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov


Currently, there is no such ability to notify a users receiver listener 
({{TransmissionHandler}}) when a file transmission is fully ended. 

So, in case of the next transmission request will be fired right after the 
current on we may get an error -- "Error has been sent back to a remote node. 
The receiver holds the local topic" due to channel resources are not released 
yet.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: How KILL QUERY should work?

[Roman Kondakov]

Nikolay,

I've made a ticket for this issue [1]

> I have one more question.
> Kill query suppose to work as the following:
> 
> 1. User execute some SQL statement.
> 2. User waits or fetch query results.
> 2. Other user(or administrator) executes «KILL QUERY» with the query id from 
> the step 1.
> 3. User receive an exception when trying to fetch more data from any server 
> node.
> 
> Is this use-case correct?

yes, I think this is a correct use case.


[1] https://issues.apache.org/jira/browse/IGNITE-12732


-- 
Kind Regards
Roman Kondakov


On 02.03.2020 14:31, Nikolay Izhikov wrote:
> Roman.
> 
>> So, the problem with this error message is solved, isn't it?
> 
> You are correct.
> 
>> The another problem you've encountered after running KILL QUERY command
>> with correct qryId is freezing. Am I correct? If yes, this is a known
>> issue and I am working on it.
> 
> Yes! Thank you for the explanation.
> Can you, please, name the ticket for this issue?
> 
> I have one more question.
> Kill query suppose to work as the following:
> 
> 1. User execute some SQL statement.
> 2. User waits or fetch query results.
> 2. Other user(or administrator) executes «KILL QUERY» with the query id from 
> the step 1.
> 3. User receive an exception when trying to fetch more data from any server 
> node.
> 
> Is this use-case correct?
> 
> 
>> 2 марта 2020 г., в 14:21, Roman Kondakov  
>> написал(а):
>>
>> Nikolay,
>>
>> as I can see, when you run "SELECT * FROM SYS.SQL_QUERIES ORDER BY
>> START_TIME" from the client node (not from the server node as was in
>> your first reproducer), the query you are looking for is correctly
>> returned in the view's result set. Right? So, the problem with this
>> error message is solved, isn't it?
>>
>>> Error is «Query with provided ID doesn’t exist» 
>>
>> The another problem you've encountered after running KILL QUERY command
>> with correct qryId is freezing. Am I correct? If yes, this is a known
>> issue and I am working on it.
>>
>>
>> -- 
>> Kind Regards
>> Roman Kondakov
>>
>>
>> On 02.03.2020 14:02, Nikolay Izhikov wrote:
>>> Hello, Roman.
>>>
>>> Please, see updated test.
>>> I assert query text to ensure that correct `SELECT` statement used for KILL 
>>> command.
>>>
>>> This test freeze on «KILL QUERY» execution.
>>>
>>> ```
>>> @Test
>>> public void testCancelSQLQuery() throws Exception {
>>>startGrids(1);
>>>IgniteEx client = startClientGrid("client");
>>>
>>>client.cluster().state(ACTIVE);
>>>
>>>IgniteCache cache = client.getOrCreateCache(
>>>new 
>>> CacheConfiguration<>(DEFAULT_CACHE_NAME).setIndexedTypes(Integer.class, 
>>> Integer.class));
>>>
>>>for (int i = 0; i < PAGE_SZ * PAGE_SZ; i++)
>>>cache.put(i, i);
>>>
>>>SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
>>> INTEGER").setSchema("default").setPageSize(10);
>>>Iterator> iter = queryProcessor(client).querySqlFields(qry, 
>>> true).iterator();
>>>
>>>assertNotNull(iter.next());
>>>
>>>List> sqlQries0 = SqlViewExporterSpiTest.execute(client,
>>>"SELECT * FROM SYS.SQL_QUERIES ORDER BY START_TIME");
>>>assertEquals(2, sqlQries0.size());
>>>
>>>String qryId = (String)sqlQries0.get(0).get(0);
>>>assertEquals("SELECT _KEY, _VAL FROM INTEGER", sqlQries0.get(0).get(1));
>>>
>>>SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'");
>>>
>>>while(iter.hasNext())
>>>assertNotNull(iter.next());
>>>
>>>fail("You shouldn't be here!");
>>> }
>>> ```
>>>
 2 марта 2020 г., в 13:48, Roman Kondakov  
 написал(а):

 Nikolay,

> This system view returns queries that are *running* on the node.
> I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.

 It looks a bit weird to me, because when I print results of the running
 queries from server node:

 List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0,
 "SELECT * FROM SYS.SQL_QUERIES");
 System.out.println("sqlQries0=" + sqlQries0);

 it prints only the system view query:

 sqlQries0=[[adfe8400-15c7-40cf-a6d2-41012b50_1, SELECT * FROM
 SYS.SQL_QUERIES, adfe8400-15c7-40cf-a6d2-41012b50, 2020-03-02
 13:25:12.927, -3, false, PUBLIC]]

 but when I do the same for the client node, it prints both queries:

 sqlQries0=[[dbb3418d-dec2-40f4-8276-090fd31fc27d_1, SELECT _KEY, _VAL
 FROM INTEGER, dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02
 13:30:43.953, 17, false, default],
 [dbb3418d-dec2-40f4-8276-090fd31fc27d_2, SELECT * FROM SYS.SQL_QUERIES,
 dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02 13:30:43.974, -4,
 false, PUBLIC]]

 Are you sure you can see both queries in the result of select from the
 server?

 It looks like the statement

> This system view returns queries that are *running* on the node.

 is incorrect. The view returns queries that were *originated* from the
 node, not 

[jira] [Created] (IGNITE-12732) SQL: KILL QUERY command hangs on query when query cursor is held by user or leak

[Roman Kondakov (Jira)]

Roman Kondakov created IGNITE-12732:
---

 Summary: SQL: KILL QUERY command hangs on query when query cursor 
is held by user or leak
 Key: IGNITE-12732
 URL: https://issues.apache.org/jira/browse/IGNITE-12732
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Roman Kondakov


Scenario to reproduce:
1. Execute a query
2. Don't close the query cursor, don't iterate to the end of results.
3. Run "KILL QUERY" command. The command hangs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: How KILL QUERY should work?

[Nikolay Izhikov]

Roman.

> So, the problem with this error message is solved, isn't it?

You are correct.

> The another problem you've encountered after running KILL QUERY command
> with correct qryId is freezing. Am I correct? If yes, this is a known
> issue and I am working on it.

Yes! Thank you for the explanation.
Can you, please, name the ticket for this issue?

I have one more question.
Kill query suppose to work as the following:

1. User execute some SQL statement.
2. User waits or fetch query results.
2. Other user(or administrator) executes «KILL QUERY» with the query id from 
the step 1.
3. User receive an exception when trying to fetch more data from any server 
node.

Is this use-case correct?


> 2 марта 2020 г., в 14:21, Roman Kondakov  
> написал(а):
> 
> Nikolay,
> 
> as I can see, when you run "SELECT * FROM SYS.SQL_QUERIES ORDER BY
> START_TIME" from the client node (not from the server node as was in
> your first reproducer), the query you are looking for is correctly
> returned in the view's result set. Right? So, the problem with this
> error message is solved, isn't it?
> 
>> Error is «Query with provided ID doesn’t exist» 
> 
> The another problem you've encountered after running KILL QUERY command
> with correct qryId is freezing. Am I correct? If yes, this is a known
> issue and I am working on it.
> 
> 
> -- 
> Kind Regards
> Roman Kondakov
> 
> 
> On 02.03.2020 14:02, Nikolay Izhikov wrote:
>> Hello, Roman.
>> 
>> Please, see updated test.
>> I assert query text to ensure that correct `SELECT` statement used for KILL 
>> command.
>> 
>> This test freeze on «KILL QUERY» execution.
>> 
>> ```
>> @Test
>> public void testCancelSQLQuery() throws Exception {
>>startGrids(1);
>>IgniteEx client = startClientGrid("client");
>> 
>>client.cluster().state(ACTIVE);
>> 
>>IgniteCache cache = client.getOrCreateCache(
>>new 
>> CacheConfiguration<>(DEFAULT_CACHE_NAME).setIndexedTypes(Integer.class, 
>> Integer.class));
>> 
>>for (int i = 0; i < PAGE_SZ * PAGE_SZ; i++)
>>cache.put(i, i);
>> 
>>SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
>> INTEGER").setSchema("default").setPageSize(10);
>>Iterator> iter = queryProcessor(client).querySqlFields(qry, 
>> true).iterator();
>> 
>>assertNotNull(iter.next());
>> 
>>List> sqlQries0 = SqlViewExporterSpiTest.execute(client,
>>"SELECT * FROM SYS.SQL_QUERIES ORDER BY START_TIME");
>>assertEquals(2, sqlQries0.size());
>> 
>>String qryId = (String)sqlQries0.get(0).get(0);
>>assertEquals("SELECT _KEY, _VAL FROM INTEGER", sqlQries0.get(0).get(1));
>> 
>>SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'");
>> 
>>while(iter.hasNext())
>>assertNotNull(iter.next());
>> 
>>fail("You shouldn't be here!");
>> }
>> ```
>> 
>>> 2 марта 2020 г., в 13:48, Roman Kondakov  
>>> написал(а):
>>> 
>>> Nikolay,
>>> 
 This system view returns queries that are *running* on the node.
 I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.
>>> 
>>> It looks a bit weird to me, because when I print results of the running
>>> queries from server node:
>>> 
>>> List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0,
>>> "SELECT * FROM SYS.SQL_QUERIES");
>>> System.out.println("sqlQries0=" + sqlQries0);
>>> 
>>> it prints only the system view query:
>>> 
>>> sqlQries0=[[adfe8400-15c7-40cf-a6d2-41012b50_1, SELECT * FROM
>>> SYS.SQL_QUERIES, adfe8400-15c7-40cf-a6d2-41012b50, 2020-03-02
>>> 13:25:12.927, -3, false, PUBLIC]]
>>> 
>>> but when I do the same for the client node, it prints both queries:
>>> 
>>> sqlQries0=[[dbb3418d-dec2-40f4-8276-090fd31fc27d_1, SELECT _KEY, _VAL
>>> FROM INTEGER, dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02
>>> 13:30:43.953, 17, false, default],
>>> [dbb3418d-dec2-40f4-8276-090fd31fc27d_2, SELECT * FROM SYS.SQL_QUERIES,
>>> dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02 13:30:43.974, -4,
>>> false, PUBLIC]]
>>> 
>>> Are you sure you can see both queries in the result of select from the
>>> server?
>>> 
>>> It looks like the statement
>>> 
 This system view returns queries that are *running* on the node.
>>> 
>>> is incorrect. The view returns queries that were *originated* from the
>>> node, not the all *running* there. I'm not sure whether it is expected
>>> behaviour.
>>> 
>>> 
>>> And what about query hanging: it is a known issue. I'm working on it
>>> right now. I'll file a ticket and propose a patch soon.
 I tried and it doesn’t work, also.
 `KILL QUERY` command just freeze on 
 `CommandProcessor#processKillQueryCommand` line 478.
>>> 
>>> 
>>> -- 
>>> Kind Regards
>>> Roman Kondakov
>>> 
>>> 
>>> On 02.03.2020 13:10, Nikolay Izhikov wrote:
 Hello, Roman.
 
 My initial query was about correct usage of KILL QUERY command.
 It seems for me, that It just doesn’t work.
 
> itself, which is already completed by the time you run "KILL QUERY" 
> command.
 

Re: How KILL QUERY should work?

[Roman Kondakov]

Nikolay,

as I can see, when you run "SELECT * FROM SYS.SQL_QUERIES ORDER BY
START_TIME" from the client node (not from the server node as was in
your first reproducer), the query you are looking for is correctly
returned in the view's result set. Right? So, the problem with this
error message is solved, isn't it?

> Error is «Query with provided ID doesn’t exist» 

The another problem you've encountered after running KILL QUERY command
with correct qryId is freezing. Am I correct? If yes, this is a known
issue and I am working on it.


-- 
Kind Regards
Roman Kondakov


On 02.03.2020 14:02, Nikolay Izhikov wrote:
> Hello, Roman.
> 
> Please, see updated test.
> I assert query text to ensure that correct `SELECT` statement used for KILL 
> command.
> 
> This test freeze on «KILL QUERY» execution.
> 
> ```
> @Test
> public void testCancelSQLQuery() throws Exception {
> startGrids(1);
> IgniteEx client = startClientGrid("client");
> 
> client.cluster().state(ACTIVE);
> 
> IgniteCache cache = client.getOrCreateCache(
> new 
> CacheConfiguration<>(DEFAULT_CACHE_NAME).setIndexedTypes(Integer.class, 
> Integer.class));
> 
> for (int i = 0; i < PAGE_SZ * PAGE_SZ; i++)
> cache.put(i, i);
> 
> SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
> INTEGER").setSchema("default").setPageSize(10);
> Iterator> iter = queryProcessor(client).querySqlFields(qry, 
> true).iterator();
> 
> assertNotNull(iter.next());
> 
> List> sqlQries0 = SqlViewExporterSpiTest.execute(client,
> "SELECT * FROM SYS.SQL_QUERIES ORDER BY START_TIME");
> assertEquals(2, sqlQries0.size());
> 
> String qryId = (String)sqlQries0.get(0).get(0);
> assertEquals("SELECT _KEY, _VAL FROM INTEGER", sqlQries0.get(0).get(1));
> 
> SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'");
> 
> while(iter.hasNext())
> assertNotNull(iter.next());
> 
> fail("You shouldn't be here!");
> }
> ```
> 
>> 2 марта 2020 г., в 13:48, Roman Kondakov  
>> написал(а):
>>
>> Nikolay,
>>
>>> This system view returns queries that are *running* on the node.
>>> I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.
>>
>> It looks a bit weird to me, because when I print results of the running
>> queries from server node:
>>
>> List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0,
>> "SELECT * FROM SYS.SQL_QUERIES");
>> System.out.println("sqlQries0=" + sqlQries0);
>>
>> it prints only the system view query:
>>
>> sqlQries0=[[adfe8400-15c7-40cf-a6d2-41012b50_1, SELECT * FROM
>> SYS.SQL_QUERIES, adfe8400-15c7-40cf-a6d2-41012b50, 2020-03-02
>> 13:25:12.927, -3, false, PUBLIC]]
>>
>> but when I do the same for the client node, it prints both queries:
>>
>> sqlQries0=[[dbb3418d-dec2-40f4-8276-090fd31fc27d_1, SELECT _KEY, _VAL
>> FROM INTEGER, dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02
>> 13:30:43.953, 17, false, default],
>> [dbb3418d-dec2-40f4-8276-090fd31fc27d_2, SELECT * FROM SYS.SQL_QUERIES,
>> dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02 13:30:43.974, -4,
>> false, PUBLIC]]
>>
>> Are you sure you can see both queries in the result of select from the
>> server?
>>
>> It looks like the statement
>>
>>> This system view returns queries that are *running* on the node.
>>
>> is incorrect. The view returns queries that were *originated* from the
>> node, not the all *running* there. I'm not sure whether it is expected
>> behaviour.
>>
>>
>> And what about query hanging: it is a known issue. I'm working on it
>> right now. I'll file a ticket and propose a patch soon.
>>> I tried and it doesn’t work, also.
>>> `KILL QUERY` command just freeze on 
>>> `CommandProcessor#processKillQueryCommand` line 478.
>>
>>
>> -- 
>> Kind Regards
>> Roman Kondakov
>>
>>
>> On 02.03.2020 13:10, Nikolay Izhikov wrote:
>>> Hello, Roman.
>>>
>>> My initial query was about correct usage of KILL QUERY command.
>>> It seems for me, that It just doesn’t work.
>>>
 itself, which is already completed by the time you run "KILL QUERY" 
 command.
>>>
>>> As you can see from the source iterator doesn’t closed in the moment of 
>>> `KILL QUERY` execution.
>>> I suppose that should mean that query still executed.
>>>
 returns only the queries which were originated from the ignite0 node.
>>>
>>> This system view returns queries that are *running* on the node.
>>> I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.
>>> I suppose that mean that query are executed on the server node.
>>>
 Try to replace "ignite0" with a "client" node in this line. I think it may 
 help
>>>
>>> I tried and it doesn’t work, also.
>>> `KILL QUERY` command just freeze on 
>>> `CommandProcessor#processKillQueryCommand` line 478.
>>>
>>> ```
>>> /** @throws Exception If failed. */
>>> @Test
>>> public void testCancelSQLQuery() throws Exception {
>>>IgniteEx ignite0 = startGrids(NODES_CNT);
>>>IgniteEx client = startClientGrid("client");
>>>
>>>   

Re: How KILL QUERY should work?

[Nikolay Izhikov]

Hello, Roman.

Please, see updated test.
I assert query text to ensure that correct `SELECT` statement used for KILL 
command.

This test freeze on «KILL QUERY» execution.

```
@Test
public void testCancelSQLQuery() throws Exception {
startGrids(1);
IgniteEx client = startClientGrid("client");

client.cluster().state(ACTIVE);

IgniteCache cache = client.getOrCreateCache(
new 
CacheConfiguration<>(DEFAULT_CACHE_NAME).setIndexedTypes(Integer.class, 
Integer.class));

for (int i = 0; i < PAGE_SZ * PAGE_SZ; i++)
cache.put(i, i);

SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
INTEGER").setSchema("default").setPageSize(10);
Iterator> iter = queryProcessor(client).querySqlFields(qry, 
true).iterator();

assertNotNull(iter.next());

List> sqlQries0 = SqlViewExporterSpiTest.execute(client,
"SELECT * FROM SYS.SQL_QUERIES ORDER BY START_TIME");
assertEquals(2, sqlQries0.size());

String qryId = (String)sqlQries0.get(0).get(0);
assertEquals("SELECT _KEY, _VAL FROM INTEGER", sqlQries0.get(0).get(1));

SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'");

while(iter.hasNext())
assertNotNull(iter.next());

fail("You shouldn't be here!");
}
```

> 2 марта 2020 г., в 13:48, Roman Kondakov  
> написал(а):
> 
> Nikolay,
> 
>> This system view returns queries that are *running* on the node.
>> I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.
> 
> It looks a bit weird to me, because when I print results of the running
> queries from server node:
> 
> List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0,
> "SELECT * FROM SYS.SQL_QUERIES");
> System.out.println("sqlQries0=" + sqlQries0);
> 
> it prints only the system view query:
> 
> sqlQries0=[[adfe8400-15c7-40cf-a6d2-41012b50_1, SELECT * FROM
> SYS.SQL_QUERIES, adfe8400-15c7-40cf-a6d2-41012b50, 2020-03-02
> 13:25:12.927, -3, false, PUBLIC]]
> 
> but when I do the same for the client node, it prints both queries:
> 
> sqlQries0=[[dbb3418d-dec2-40f4-8276-090fd31fc27d_1, SELECT _KEY, _VAL
> FROM INTEGER, dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02
> 13:30:43.953, 17, false, default],
> [dbb3418d-dec2-40f4-8276-090fd31fc27d_2, SELECT * FROM SYS.SQL_QUERIES,
> dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02 13:30:43.974, -4,
> false, PUBLIC]]
> 
> Are you sure you can see both queries in the result of select from the
> server?
> 
> It looks like the statement
> 
>> This system view returns queries that are *running* on the node.
> 
> is incorrect. The view returns queries that were *originated* from the
> node, not the all *running* there. I'm not sure whether it is expected
> behaviour.
> 
> 
> And what about query hanging: it is a known issue. I'm working on it
> right now. I'll file a ticket and propose a patch soon.
>> I tried and it doesn’t work, also.
>> `KILL QUERY` command just freeze on 
>> `CommandProcessor#processKillQueryCommand` line 478.
> 
> 
> -- 
> Kind Regards
> Roman Kondakov
> 
> 
> On 02.03.2020 13:10, Nikolay Izhikov wrote:
>> Hello, Roman.
>> 
>> My initial query was about correct usage of KILL QUERY command.
>> It seems for me, that It just doesn’t work.
>> 
>>> itself, which is already completed by the time you run "KILL QUERY" command.
>> 
>> As you can see from the source iterator doesn’t closed in the moment of 
>> `KILL QUERY` execution.
>> I suppose that should mean that query still executed.
>> 
>>> returns only the queries which were originated from the ignite0 node.
>> 
>> This system view returns queries that are *running* on the node.
>> I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.
>> I suppose that mean that query are executed on the server node.
>> 
>>> Try to replace "ignite0" with a "client" node in this line. I think it may 
>>> help
>> 
>> I tried and it doesn’t work, also.
>> `KILL QUERY` command just freeze on 
>> `CommandProcessor#processKillQueryCommand` line 478.
>> 
>> ```
>> /** @throws Exception If failed. */
>> @Test
>> public void testCancelSQLQuery() throws Exception {
>>IgniteEx ignite0 = startGrids(NODES_CNT);
>>IgniteEx client = startClientGrid("client");
>> 
>>ignite0.cluster().state(ACTIVE);
>> 
>>initCache(client);
>> 
>>SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
>> INTEGER").setSchema("default").setPageSize(10);
>>Iterator> iter = queryProcessor(client).querySqlFields(qry, 
>> true).iterator();
>> 
>>assertNotNull(iter.next());
>> 
>>List> sqlQries0 = SqlViewExporterSpiTest.execute(client, "SELECT 
>> * FROM SYS.SQL_QUERIES");
>>assertEquals(2, sqlQries0.size());
>> 
>> 
>>String qryId = (String)sqlQries0.get(0).get(0);
>>assertEquals("SELECT _KEY, _VAL FROM INTEGER", sqlQries0.get(0).get(1));
>> 
>>//Here test just freeze.
>>SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'");
>> 
>>while(iter.hasNext())
>>assertNotNull(iter.next())

Re: How KILL QUERY should work?

[Roman Kondakov]

Nikolay,

> This system view returns queries that are *running* on the node.
> I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.

It looks a bit weird to me, because when I print results of the running
queries from server node:

List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0,
"SELECT * FROM SYS.SQL_QUERIES");
System.out.println("sqlQries0=" + sqlQries0);

it prints only the system view query:

sqlQries0=[[adfe8400-15c7-40cf-a6d2-41012b50_1, SELECT * FROM
SYS.SQL_QUERIES, adfe8400-15c7-40cf-a6d2-41012b50, 2020-03-02
13:25:12.927, -3, false, PUBLIC]]

but when I do the same for the client node, it prints both queries:

sqlQries0=[[dbb3418d-dec2-40f4-8276-090fd31fc27d_1, SELECT _KEY, _VAL
FROM INTEGER, dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02
13:30:43.953, 17, false, default],
[dbb3418d-dec2-40f4-8276-090fd31fc27d_2, SELECT * FROM SYS.SQL_QUERIES,
dbb3418d-dec2-40f4-8276-090fd31fc27d, 2020-03-02 13:30:43.974, -4,
false, PUBLIC]]

Are you sure you can see both queries in the result of select from the
server?

It looks like the statement

> This system view returns queries that are *running* on the node.

is incorrect. The view returns queries that were *originated* from the
node, not the all *running* there. I'm not sure whether it is expected
behaviour.


And what about query hanging: it is a known issue. I'm working on it
right now. I'll file a ticket and propose a patch soon.
> I tried and it doesn’t work, also.
> `KILL QUERY` command just freeze on 
> `CommandProcessor#processKillQueryCommand` line 478.


-- 
Kind Regards
Roman Kondakov


On 02.03.2020 13:10, Nikolay Izhikov wrote:
> Hello, Roman.
> 
> My initial query was about correct usage of KILL QUERY command.
> It seems for me, that It just doesn’t work.
> 
>> itself, which is already completed by the time you run "KILL QUERY" command.
> 
> As you can see from the source iterator doesn’t closed in the moment of `KILL 
> QUERY` execution.
> I suppose that should mean that query still executed.
> 
>> returns only the queries which were originated from the ignite0 node.
> 
> This system view returns queries that are *running* on the node.
> I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.
> I suppose that mean that query are executed on the server node.
> 
>> Try to replace "ignite0" with a "client" node in this line. I think it may 
>> help
> 
> I tried and it doesn’t work, also.
> `KILL QUERY` command just freeze on 
> `CommandProcessor#processKillQueryCommand` line 478.
> 
> ```
> /** @throws Exception If failed. */
> @Test
> public void testCancelSQLQuery() throws Exception {
> IgniteEx ignite0 = startGrids(NODES_CNT);
> IgniteEx client = startClientGrid("client");
> 
> ignite0.cluster().state(ACTIVE);
> 
> initCache(client);
> 
> SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
> INTEGER").setSchema("default").setPageSize(10);
> Iterator> iter = queryProcessor(client).querySqlFields(qry, 
> true).iterator();
> 
> assertNotNull(iter.next());
> 
> List> sqlQries0 = SqlViewExporterSpiTest.execute(client, "SELECT 
> * FROM SYS.SQL_QUERIES");
> assertEquals(2, sqlQries0.size());
> 
> 
> String qryId = (String)sqlQries0.get(0).get(0);
> assertEquals("SELECT _KEY, _VAL FROM INTEGER", sqlQries0.get(0).get(1));
> 
> //Here test just freeze.
> SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'");
> 
> while(iter.hasNext())
> assertNotNull(iter.next());
> 
> fail("You shouldn't be here!");
> }
> ``
> 
> 
> 
>> 2 марта 2020 г., в 12:46, Roman Kondakov  
>> написал(а):
>>
>> Hi Nikolay,
>>
>> I think that problem here is that the query you are trying to kill is
>>
>>> "SELECT QUERY_ID FROM SYS.SQL_QUERIES"
>>
>> itself, which is already completed by the time you run "KILL QUERY" command.
>>
>> I'm not an expert in the system views, but it seems to me that the line
>>
>>> List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0, "SELECT 
>>> QUERY_ID FROM SYS.SQL_QUERIES");
>>
>> returns only the queries which were originated from the ignite0 node.
>> Since "SELECT _KEY, _VAL FROM INTEGER" was started on the client node,
>> it doesn't get into that list.
>>
>> Try to replace "ignite0" with a "client" node in this line. I think it
>> may help:
>>
>>> List> sqlQries0 = SqlViewExporterSpiTest.execute(client, "SELECT 
>>> QUERY_ID FROM SYS.SQL_QUERIES");
>>
>>
>>
>> -- 
>> Kind Regards
>> Roman Kondakov
>>
>>
>> On 02.03.2020 12:02, Nikolay Izhikov wrote:
>>> Hello, Igniters.
>>>
>>> Ignite right now support `KILL QUERY` command.
>>> I tried to use it and stuck with the simple test.
>>> Error is «Query with provided ID doesn’t exist» 
>>>
>>> Can you, please, advise me - How KILL QUERY should be used?
>>>
>>> ```
>>>@Test
>>>public void testCancelSQLQuery() throws Exception {
>>>IgniteEx ignite0 = startGrids(NODES_CNT);
>>>IgniteEx client = startClientGrid("client");
>>>
>>>

Re: How KILL QUERY should work?

[Nikolay Izhikov]

Hello, Roman.

My initial query was about correct usage of KILL QUERY command.
It seems for me, that It just doesn’t work.

> itself, which is already completed by the time you run "KILL QUERY" command.

As you can see from the source iterator doesn’t closed in the moment of `KILL 
QUERY` execution.
I suppose that should mean that query still executed.

> returns only the queries which were originated from the ignite0 node.

This system view returns queries that are *running* on the node.
I can see «"SELECT _KEY, _VAL FROM INTEGER» in the results of select.
I suppose that mean that query are executed on the server node.

> Try to replace "ignite0" with a "client" node in this line. I think it may 
> help

I tried and it doesn’t work, also.
`KILL QUERY` command just freeze on `CommandProcessor#processKillQueryCommand` 
line 478.

```
/** @throws Exception If failed. */
@Test
public void testCancelSQLQuery() throws Exception {
IgniteEx ignite0 = startGrids(NODES_CNT);
IgniteEx client = startClientGrid("client");

ignite0.cluster().state(ACTIVE);

initCache(client);

SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
INTEGER").setSchema("default").setPageSize(10);
Iterator> iter = queryProcessor(client).querySqlFields(qry, 
true).iterator();

assertNotNull(iter.next());

List> sqlQries0 = SqlViewExporterSpiTest.execute(client, "SELECT * 
FROM SYS.SQL_QUERIES");
assertEquals(2, sqlQries0.size());


String qryId = (String)sqlQries0.get(0).get(0);
assertEquals("SELECT _KEY, _VAL FROM INTEGER", sqlQries0.get(0).get(1));

//Here test just freeze.
SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'");

while(iter.hasNext())
assertNotNull(iter.next());

fail("You shouldn't be here!");
}
``



> 2 марта 2020 г., в 12:46, Roman Kondakov  
> написал(а):
> 
> Hi Nikolay,
> 
> I think that problem here is that the query you are trying to kill is
> 
>> "SELECT QUERY_ID FROM SYS.SQL_QUERIES"
> 
> itself, which is already completed by the time you run "KILL QUERY" command.
> 
> I'm not an expert in the system views, but it seems to me that the line
> 
>> List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0, "SELECT 
>> QUERY_ID FROM SYS.SQL_QUERIES");
> 
> returns only the queries which were originated from the ignite0 node.
> Since "SELECT _KEY, _VAL FROM INTEGER" was started on the client node,
> it doesn't get into that list.
> 
> Try to replace "ignite0" with a "client" node in this line. I think it
> may help:
> 
>> List> sqlQries0 = SqlViewExporterSpiTest.execute(client, "SELECT 
>> QUERY_ID FROM SYS.SQL_QUERIES");
> 
> 
> 
> -- 
> Kind Regards
> Roman Kondakov
> 
> 
> On 02.03.2020 12:02, Nikolay Izhikov wrote:
>> Hello, Igniters.
>> 
>> Ignite right now support `KILL QUERY` command.
>> I tried to use it and stuck with the simple test.
>> Error is «Query with provided ID doesn’t exist» 
>> 
>> Can you, please, advise me - How KILL QUERY should be used?
>> 
>> ```
>>@Test
>>public void testCancelSQLQuery() throws Exception {
>>IgniteEx ignite0 = startGrids(NODES_CNT);
>>IgniteEx client = startClientGrid("client");
>> 
>>ignite0.cluster().state(ACTIVE);
>> 
>>initCache(client);
>> 
>>SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
>> INTEGER").setSchema("default").setPageSize(10);
>>Iterator> iter = queryProcessor(client).querySqlFields(qry, 
>> true).iterator();
>> 
>>assertNotNull(iter.next());
>> 
>>List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0, 
>> "SELECT QUERY_ID FROM SYS.SQL_QUERIES");
>>assertEquals(1, sqlQries0.size());
>>  
>>String qryId = (String)sqlQries0.get(0).get(0);
>>SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'»);
>> 
>>  //Expecting this iteration will fail.
>>while(iter.hasNext())
>>assertNotNull(iter.next());
>> 
>>fail("You shouldn't be here!");
>>}
>> 
>>private void initCache(IgniteEx client) {
>>IgniteCache cache = client.getOrCreateCache(
>>new 
>> CacheConfiguration<>(DEFAULT_CACHE_NAME).setIndexedTypes(Integer.class, 
>> Integer.class));
>> 
>>for (int i = 0; i < PAGE_SZ * PAGE_SZ; i++)
>>cache.put(i, i);
>>}
>> ```
>> 
>> ```
>> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
>> to cancel query 
>> [nodeId=4f812490-47b9-4331-8b51-d783f530,qryId=1,err=Query with provided 
>> ID doesn't exist [nodeId=4f812490-47b9-4331-8b51-d783f530, qryId=1]]
>> 
>>  at 
>> org.apache.ignite.internal.processors.query.h2.CommandProcessor.processKillQueryCommand(CommandProcessor.java:482)
>>  at 
>> org.apache.ignite.internal.processors.query.h2.CommandProcessor.runCommand(CommandProcessor.java:411)
>>  at 
>> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeCommand(IgniteH2Indexing.java:996)
>>  at 
>> org

Re: Read through not working as expected in case of Replicated cache

[Prasad Bhalerao]

Hi Ivan,

Thank you for the clarification.

So the behavior is same for REPLICATED as well as PARTITIONED cache.

1) Can we please have this behavior documented on Ignite web page? This
will just help users to avoid confusion and design their cache effectively.

2)  You said "You can check it using IgniteCache.localPeek method (ask if
more details how to do it are needed)".  Can you please explain this in
detail?


Regard,
Prasad

On Mon, Mar 2, 2020 at 2:45 PM Ivan Pavlukhin  wrote:

> Hi Prasad,
>
> AFAIK, when value is read through it is not sent to backup nodes. You
> can check it using IgniteCache.localPeek method (ask if more details
> how to do it are needed).
>
> I usually think about read-through cache for a following case. There
> is an underlying storage with "real" data, cache is used to speedup an
> access. Some kind of invalidation mechanism might be used but it is
> assumed fine to read values from cache which are not consistent with
> the backing storage at some point.
>
> Consequently it seems there is no need to distribute values from an
> underlying storage over all replicas because if a value is absent a
> reader will receive an actual value from the underlying storage.
>
> Best regards,
> Ivan Pavlukhin
>
> пн, 2 мар. 2020 г. в 10:41, Prasad Bhalerao  >:
> >
> > Hi Ivan/Denis,
> >
> > Are you saying that when a value is loaded to cache from an underlying
> > storage using read-through approach, value is loaded only on primary node
> > and does not get replicated on its back nodes?
> >
> > I am under the impression that when a value is loaded in a cache using
> > read-through approach, this key/value pair gets replicated on all back-up
> > nodes as well, irrespective of REPLICATED OR PARTITIONED cache.
> > Please correct me if I am wrong.
> >
> > I think the key/value must get replicated on all backup nodes when it is
> > read through underlying storage otherwise user will have to add the same
> > key/value explicitly using cache.put(key,value) operation so that it will
> > get replicated on all of its backup nodes.  This is what I am doing right
> > now as a workaround to solve this issue.
> >
> > I will try to explain my use case again.
> >
> > I have few replicated caches for which read-through is enabled but
> > write-through is disabled. The underlying tables for these caches are
> > updated by different systems. Whenever these tables are updated by 3rd
> > party system I want to reload the "cache entries".
> >
> > I achieve this using below given steps:
> > 1) 3rd party systems sends an update message (which contains the key) to
> > our service by invoking our REST api.
> > 2) Delete an entry from cache using cache().remove(key) method. (Entry is
> > just removed from cache but present in DB as write-through is false)
> > 3) Invoke cache().get(key) method for the same key in step 2 to reload an
> > entry.
> >
> > Thanks,
> > Prasad
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Prasad
> >
> > On Sat, Feb 29, 2020 at 4:49 AM Denis Magda  wrote:
> >
> > > Ivan, thanks for stepping in.
> > >
> > > Prasad, is Ivan's assumption correct that you query the data with SQL
> under
> > > the observed circumstances? My guess is that you were referring to the
> > > key-value APIs as long as the issue is gone when the write-through is
> > > enabled.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Fri, Feb 28, 2020 at 2:30 PM Ivan Pavlukhin 
> > > wrote:
> > >
> > > > As I understand the thing here is in combination of read-through and
> > > > SQL. SQL queries do not read from underlying storage when
> read-through
> > > > is configured. And an observed result happens because query from a
> > > > client node over REPLICATED cache picks random server node (kind of
> > > > load-balancing) to retrieve data. Following happens in the described
> > > > case:
> > > > 1. Value is loaded to a cache from an underlying storage on a primary
> > > > node when cache.get is called.
> > > > 2. Query is executed multiple times and when the chose node is the
> > > > primary node then the value is observed. On other nodes the value is
> > > > absent.
> > > >
> > > > Actually, behavior for PARTITIONED cache is similar, but an
> > > > inconsistency is not observed because SQL queries read data from the
> > > > primary node there. If the primary node leaves a cluster then an SQL
> > > > query will not see the value anymore. So, the same inconsistency will
> > > > appear.
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > > пт, 28 февр. 2020 г. в 13:23, Prasad Bhalerao <
> > > > prasadbhalerao1...@gmail.com>:
> > > > >
> > > > > Can someone please comment on this?
> > > > >
> > > > > On Wed, Feb 26, 2020 at 6:04 AM Denis Magda 
> wrote:
> > > > >
> > > > > > Ignite Dev team,
> > > > > >
> > > > > > This sounds like an issue in our replicated cache implementation
> > > rather
> > > > > > than an expected behavior. Especially, if partitioned caches
> don't
> > > ha

Re: Reference of local service.

[Vladimir Steshin]

Denis, Vyacheslav, hi.

What if we just provide an option to disable service metrics at all? It
would keep direct references for local services. Also, we can make service
metrics disabled by default to keep current code working. A warning of
local service issues will be set with the option.

пн, 2 мар. 2020 г. в 11:26, Vyacheslav Daradur :

> >> Moreover, I don't see a way of implementing such a check. Are you going
> to look just for any interface? What about Serializable? Will it do?
>
> The check should look for the interface which implements
> "org.apache.ignite.services.Service", it covers the requirement to be
> Serializable.
>
> >> For now though the best thing we can do is to calculate remote
> invocations only, since all of them go through a proxy.
>
> Let's introduce a system property to manage local services monitoring:
> - local services monitoring will be disabled by default - to avoid any
> backward compatibility issues;
> - local services monitoring can be enabled runtime with a known limitation
> for new services for example;
> Moreover, if we introduce such a feature flag to ServiceConfiguration -
> the new feature can be enabled per service separately.
>
> What do you think?
>
>
>
> On Mon, Mar 2, 2020 at 12:33 AM Denis Mekhanikov 
> wrote:
>
>> Vladimir, Slava,
>>
>> In general, I like the idea of abstracting the service deployment from
>> its usage, but there are some backward-compatibility considerations that
>> won't let us do so.
>>
>> Or we can declare usage of services without interfaces incorrect
>>
>>
>> I don't think we can introduce a requirement for all services to have an
>> interface, unfortunately. Such change can potentially break existing code,
>> since such requirement doesn't exist currently.
>> Moreover, I don't see a way of implementing such a check. Are you going
>> to look just for any interface? What about Serializable? Will it do?
>>
>> Usage of a proxy instead of service instances can lead to performance
>> degradation for local instances, which is another argument against such
>> change.
>>
>> I think, it will make sense to make all service invocations work through
>> a proxy in Ignite 3.
>> For now though the best thing we can do is to calculate remote
>> invocations only, since all of them go through a proxy.
>> Another option is to provide a simple way for a user to account the
>> service invocations themselves.
>>
>> What do you guys think?
>>
>> Denis
>>
>>
>> вт, 25 февр. 2020 г. в 16:50, Vyacheslav Daradur :
>>
>>> It is not a change of public API from my point of view.
>>>
>>> Also, there is a check to allow getting proxy only for an interface, not
>>> implementation.
>>>
>>> Denis, what do you think?
>>>
>>>
>>> вт, 25 февр. 2020 г. в 16:28, Vladimir Steshin :
>>>
 Vyacheslav, this is exactly what I found. I'm doing [1] (metrics for
 services) and realized I have to wrap local calls by a proxy. Is it a
 change of public API and should come with major release only? Or we can
 declare usage of services without interfaces incorrect?
 [1] https://issues.apache.org/jira/browse/IGNITE-12464

 вт, 25 февр. 2020 г. в 16:17, Vyacheslav Daradur :

> {IgniteServices#service(String name)} returns direct reference in the
> current implementation.
>
> So, class casting should work for your example:
> ((MyServiceImpl)ignite.services().service(“myService”)).bar();
>
> It is safer to use an interface instead of an implementation, there is
> no guarantee that in future releases direct link will be returned, a
> service instance might be wrapped for monitoring for example.
>
>
> On Tue, Feb 25, 2020 at 4:09 PM Vladimir Steshin 
> wrote:
>
>> Vyacheslav, Hi.
>>
>> I see. But can we consider 'locally deployed service' is a proxy too,
>> not direct reference? What if I need to wrap it? This would be local
>> service working via proxy or null.
>>
>> вт, 25 февр. 2020 г. в 16:03, Vyacheslav Daradur > >:
>>
>>> Hi, Vladimir
>>>
>>> The answer is in API docs: "Gets *locally deployed service* with
>>> specified name." [1]
>>>
>>> That means {IgniteServices#service(String name)} returns only
>>> locally deployed instance or null.
>>>
>>> {IgniteServices#serviceProxy(…)} returns proxy to call instances
>>> across the cluster. Might be used for load-balancing.
>>>
>>> [1]
>>> https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L569
>>>
>>> On Tue, Feb 25, 2020 at 3:51 PM Vladimir Steshin 
>>> wrote:
>>>
 Hello, Igniters.

 Previous e-mail was with wrong topic 'daradu...@gmail.com' :)

 I got a question what exactly IgniteServices#service(String name)
 is supposed to return: reference to the object or a proxy for some 
 reason
 like IgniteSer

Re: How KILL QUERY should work?

[Roman Kondakov]

Hi Nikolay,

I think that problem here is that the query you are trying to kill is

> "SELECT QUERY_ID FROM SYS.SQL_QUERIES"

itself, which is already completed by the time you run "KILL QUERY" command.

I'm not an expert in the system views, but it seems to me that the line

> List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0, "SELECT 
> QUERY_ID FROM SYS.SQL_QUERIES");

returns only the queries which were originated from the ignite0 node.
Since "SELECT _KEY, _VAL FROM INTEGER" was started on the client node,
it doesn't get into that list.

Try to replace "ignite0" with a "client" node in this line. I think it
may help:

> List> sqlQries0 = SqlViewExporterSpiTest.execute(client, "SELECT 
> QUERY_ID FROM SYS.SQL_QUERIES");



-- 
Kind Regards
Roman Kondakov


On 02.03.2020 12:02, Nikolay Izhikov wrote:
> Hello, Igniters.
> 
> Ignite right now support `KILL QUERY` command.
> I tried to use it and stuck with the simple test.
> Error is «Query with provided ID doesn’t exist» 
> 
> Can you, please, advise me - How KILL QUERY should be used?
> 
> ```
> @Test
> public void testCancelSQLQuery() throws Exception {
> IgniteEx ignite0 = startGrids(NODES_CNT);
> IgniteEx client = startClientGrid("client");
> 
> ignite0.cluster().state(ACTIVE);
> 
> initCache(client);
> 
> SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
> INTEGER").setSchema("default").setPageSize(10);
> Iterator> iter = queryProcessor(client).querySqlFields(qry, 
> true).iterator();
> 
> assertNotNull(iter.next());
> 
> List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0, 
> "SELECT QUERY_ID FROM SYS.SQL_QUERIES");
> assertEquals(1, sqlQries0.size());
>   
> String qryId = (String)sqlQries0.get(0).get(0);
> SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'»);
> 
>   //Expecting this iteration will fail.
> while(iter.hasNext())
> assertNotNull(iter.next());
> 
> fail("You shouldn't be here!");
> }
> 
> private void initCache(IgniteEx client) {
> IgniteCache cache = client.getOrCreateCache(
> new 
> CacheConfiguration<>(DEFAULT_CACHE_NAME).setIndexedTypes(Integer.class, 
> Integer.class));
> 
> for (int i = 0; i < PAGE_SZ * PAGE_SZ; i++)
> cache.put(i, i);
> }
> ```
> 
> ```
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to cancel query 
> [nodeId=4f812490-47b9-4331-8b51-d783f530,qryId=1,err=Query with provided 
> ID doesn't exist [nodeId=4f812490-47b9-4331-8b51-d783f530, qryId=1]]
> 
>   at 
> org.apache.ignite.internal.processors.query.h2.CommandProcessor.processKillQueryCommand(CommandProcessor.java:482)
>   at 
> org.apache.ignite.internal.processors.query.h2.CommandProcessor.runCommand(CommandProcessor.java:411)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeCommand(IgniteH2Indexing.java:996)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1085)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2454)
> 
> 

Re: Read through not working as expected in case of Replicated cache

[Ivan Pavlukhin]

Hi Prasad,

AFAIK, when value is read through it is not sent to backup nodes. You
can check it using IgniteCache.localPeek method (ask if more details
how to do it are needed).

I usually think about read-through cache for a following case. There
is an underlying storage with "real" data, cache is used to speedup an
access. Some kind of invalidation mechanism might be used but it is
assumed fine to read values from cache which are not consistent with
the backing storage at some point.

Consequently it seems there is no need to distribute values from an
underlying storage over all replicas because if a value is absent a
reader will receive an actual value from the underlying storage.

Best regards,
Ivan Pavlukhin

пн, 2 мар. 2020 г. в 10:41, Prasad Bhalerao :
>
> Hi Ivan/Denis,
>
> Are you saying that when a value is loaded to cache from an underlying
> storage using read-through approach, value is loaded only on primary node
> and does not get replicated on its back nodes?
>
> I am under the impression that when a value is loaded in a cache using
> read-through approach, this key/value pair gets replicated on all back-up
> nodes as well, irrespective of REPLICATED OR PARTITIONED cache.
> Please correct me if I am wrong.
>
> I think the key/value must get replicated on all backup nodes when it is
> read through underlying storage otherwise user will have to add the same
> key/value explicitly using cache.put(key,value) operation so that it will
> get replicated on all of its backup nodes.  This is what I am doing right
> now as a workaround to solve this issue.
>
> I will try to explain my use case again.
>
> I have few replicated caches for which read-through is enabled but
> write-through is disabled. The underlying tables for these caches are
> updated by different systems. Whenever these tables are updated by 3rd
> party system I want to reload the "cache entries".
>
> I achieve this using below given steps:
> 1) 3rd party systems sends an update message (which contains the key) to
> our service by invoking our REST api.
> 2) Delete an entry from cache using cache().remove(key) method. (Entry is
> just removed from cache but present in DB as write-through is false)
> 3) Invoke cache().get(key) method for the same key in step 2 to reload an
> entry.
>
> Thanks,
> Prasad
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Prasad
>
> On Sat, Feb 29, 2020 at 4:49 AM Denis Magda  wrote:
>
> > Ivan, thanks for stepping in.
> >
> > Prasad, is Ivan's assumption correct that you query the data with SQL under
> > the observed circumstances? My guess is that you were referring to the
> > key-value APIs as long as the issue is gone when the write-through is
> > enabled.
> >
> > -
> > Denis
> >
> >
> > On Fri, Feb 28, 2020 at 2:30 PM Ivan Pavlukhin 
> > wrote:
> >
> > > As I understand the thing here is in combination of read-through and
> > > SQL. SQL queries do not read from underlying storage when read-through
> > > is configured. And an observed result happens because query from a
> > > client node over REPLICATED cache picks random server node (kind of
> > > load-balancing) to retrieve data. Following happens in the described
> > > case:
> > > 1. Value is loaded to a cache from an underlying storage on a primary
> > > node when cache.get is called.
> > > 2. Query is executed multiple times and when the chose node is the
> > > primary node then the value is observed. On other nodes the value is
> > > absent.
> > >
> > > Actually, behavior for PARTITIONED cache is similar, but an
> > > inconsistency is not observed because SQL queries read data from the
> > > primary node there. If the primary node leaves a cluster then an SQL
> > > query will not see the value anymore. So, the same inconsistency will
> > > appear.
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > > пт, 28 февр. 2020 г. в 13:23, Prasad Bhalerao <
> > > prasadbhalerao1...@gmail.com>:
> > > >
> > > > Can someone please comment on this?
> > > >
> > > > On Wed, Feb 26, 2020 at 6:04 AM Denis Magda  wrote:
> > > >
> > > > > Ignite Dev team,
> > > > >
> > > > > This sounds like an issue in our replicated cache implementation
> > rather
> > > > > than an expected behavior. Especially, if partitioned caches don't
> > have
> > > > > such a specificity.
> > > > >
> > > > > Who can explain why write-through needs to be enabled for replicated
> > > caches
> > > > > to reload an entry from an underlying database properly/consistently?
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Tue, Feb 25, 2020 at 5:11 AM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I think this is by design. You may suggest edits on readme.io.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пн, 24 февр. 2020 г. в 17:28, Prasad Bhalerao <
> > > > > > prasadbhalerao1...@gmail.com>:
> > > > > >
> > > > > >> Hi,
> > > > >

How KILL QUERY should work?

[Nikolay Izhikov]

Hello, Igniters.

Ignite right now support `KILL QUERY` command.
I tried to use it and stuck with the simple test.
Error is «Query with provided ID doesn’t exist» 

Can you, please, advise me - How KILL QUERY should be used?

```
@Test
public void testCancelSQLQuery() throws Exception {
IgniteEx ignite0 = startGrids(NODES_CNT);
IgniteEx client = startClientGrid("client");

ignite0.cluster().state(ACTIVE);

initCache(client);

SqlFieldsQuery qry = new SqlFieldsQuery("SELECT _KEY, _VAL FROM 
INTEGER").setSchema("default").setPageSize(10);
Iterator> iter = queryProcessor(client).querySqlFields(qry, 
true).iterator();

assertNotNull(iter.next());

List> sqlQries0 = SqlViewExporterSpiTest.execute(ignite0, 
"SELECT QUERY_ID FROM SYS.SQL_QUERIES");
assertEquals(1, sqlQries0.size());

String qryId = (String)sqlQries0.get(0).get(0);
SqlViewExporterSpiTest.execute(client, "KILL QUERY '" + qryId + "'»);

//Expecting this iteration will fail.
while(iter.hasNext())
assertNotNull(iter.next());

fail("You shouldn't be here!");
}

private void initCache(IgniteEx client) {
IgniteCache cache = client.getOrCreateCache(
new 
CacheConfiguration<>(DEFAULT_CACHE_NAME).setIndexedTypes(Integer.class, 
Integer.class));

for (int i = 0; i < PAGE_SZ * PAGE_SZ; i++)
cache.put(i, i);
}
```

```
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
cancel query [nodeId=4f812490-47b9-4331-8b51-d783f530,qryId=1,err=Query 
with provided ID doesn't exist [nodeId=4f812490-47b9-4331-8b51-d783f530, 
qryId=1]]

at 
org.apache.ignite.internal.processors.query.h2.CommandProcessor.processKillQueryCommand(CommandProcessor.java:482)
at 
org.apache.ignite.internal.processors.query.h2.CommandProcessor.runCommand(CommandProcessor.java:411)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeCommand(IgniteH2Indexing.java:996)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1085)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2454)

Re: Reference of local service.

[Vyacheslav Daradur]

>> Moreover, I don't see a way of implementing such a check. Are you going
to look just for any interface? What about Serializable? Will it do?

The check should look for the interface which implements
"org.apache.ignite.services.Service", it covers the requirement to be
Serializable.

>> For now though the best thing we can do is to calculate remote
invocations only, since all of them go through a proxy.

Let's introduce a system property to manage local services monitoring:
- local services monitoring will be disabled by default - to avoid any
backward compatibility issues;
- local services monitoring can be enabled runtime with a known limitation
for new services for example;
Moreover, if we introduce such a feature flag to ServiceConfiguration - the
new feature can be enabled per service separately.

What do you think?



On Mon, Mar 2, 2020 at 12:33 AM Denis Mekhanikov 
wrote:

> Vladimir, Slava,
>
> In general, I like the idea of abstracting the service deployment from its
> usage, but there are some backward-compatibility considerations that won't
> let us do so.
>
> Or we can declare usage of services without interfaces incorrect
>
>
> I don't think we can introduce a requirement for all services to have an
> interface, unfortunately. Such change can potentially break existing code,
> since such requirement doesn't exist currently.
> Moreover, I don't see a way of implementing such a check. Are you going to
> look just for any interface? What about Serializable? Will it do?
>
> Usage of a proxy instead of service instances can lead to performance
> degradation for local instances, which is another argument against such
> change.
>
> I think, it will make sense to make all service invocations work through a
> proxy in Ignite 3.
> For now though the best thing we can do is to calculate remote invocations
> only, since all of them go through a proxy.
> Another option is to provide a simple way for a user to account the
> service invocations themselves.
>
> What do you guys think?
>
> Denis
>
>
> вт, 25 февр. 2020 г. в 16:50, Vyacheslav Daradur :
>
>> It is not a change of public API from my point of view.
>>
>> Also, there is a check to allow getting proxy only for an interface, not
>> implementation.
>>
>> Denis, what do you think?
>>
>>
>> вт, 25 февр. 2020 г. в 16:28, Vladimir Steshin :
>>
>>> Vyacheslav, this is exactly what I found. I'm doing [1] (metrics for
>>> services) and realized I have to wrap local calls by a proxy. Is it a
>>> change of public API and should come with major release only? Or we can
>>> declare usage of services without interfaces incorrect?
>>> [1] https://issues.apache.org/jira/browse/IGNITE-12464
>>>
>>> вт, 25 февр. 2020 г. в 16:17, Vyacheslav Daradur :
>>>
 {IgniteServices#service(String name)} returns direct reference in the
 current implementation.

 So, class casting should work for your example:
 ((MyServiceImpl)ignite.services().service(“myService”)).bar();

 It is safer to use an interface instead of an implementation, there is
 no guarantee that in future releases direct link will be returned, a
 service instance might be wrapped for monitoring for example.


 On Tue, Feb 25, 2020 at 4:09 PM Vladimir Steshin 
 wrote:

> Vyacheslav, Hi.
>
> I see. But can we consider 'locally deployed service' is a proxy too,
> not direct reference? What if I need to wrap it? This would be local
> service working via proxy or null.
>
> вт, 25 февр. 2020 г. в 16:03, Vyacheslav Daradur  >:
>
>> Hi, Vladimir
>>
>> The answer is in API docs: "Gets *locally deployed service* with
>> specified name." [1]
>>
>> That means {IgniteServices#service(String name)} returns only
>> locally deployed instance or null.
>>
>> {IgniteServices#serviceProxy(…)} returns proxy to call instances
>> across the cluster. Might be used for load-balancing.
>>
>> [1]
>> https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L569
>>
>> On Tue, Feb 25, 2020 at 3:51 PM Vladimir Steshin 
>> wrote:
>>
>>> Hello, Igniters.
>>>
>>> Previous e-mail was with wrong topic 'daradu...@gmail.com' :)
>>>
>>> I got a question what exactly IgniteServices#service(String name) is
>>> supposed to return: reference to the object or a proxy for some reason 
>>> like
>>> IgniteServices#serviceProxy(…)? Vyacheslav D., can you tell me your 
>>> opinion?
>>>
>>> public interface MyService {
>>>
>>>public void foo();
>>>
>>> }
>>>
>>> public class MyServiceImpl implements Service, MyService {
>>>
>>>@Override public void foo(){ … }
>>>
>>>public void bar(){ … };
>>>
>>> }
>>>
>>>
>>> // Is it required to support
>>>
>>> MyServiceImpl