[GitHub] ignite pull request #5346: IGNITE-10105: Release notes for 2.7

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/5346


---

[GitHub] ignite pull request #5346: IGNITE-10105: Release notes for 2.7

[nizhikov]

GitHub user nizhikov opened a pull request:

https://github.com/apache/ignite/pull/5346

IGNITE-10105: Release notes for 2.7



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nizhikov/ignite IGNITE-10105

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5346.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5346


commit 7a9b5cdbcbbe505749b1b61ee31059adecdd7c0c
Author: Nikolay Izhikov 
Date:   2018-11-08T06:54:12Z

IGNITE-10105: Release notes for 2.7




---

Re: SQL management and monitoring improvements

[Denis Magda]

Yuri,

That's an excellent idea, thank you for driving it.

What is not explained is how to leverage from all that stat. For instance,
how can I know a total number of SELECTs, or a total number of SELECTs
happened yesterday for specific data sets. Do believe that it's feasible
and just not covered.

--
Denis



On Wed, Nov 7, 2018 at 2:01 AM Юрий  wrote:

> Hi Igniters!
>
> I think we can improve Ignite management and monitoring instruments related
> to SQL.
> I've prepared draft of IEP-29: SQL management and monitoring
> <
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-29%3A+SQL+management+and+monitoring
> >
> .
>
> What do you think about it? May be do you have some additional suggestions?
>
>
> --
> Живи с улыбкой! :D
>

Re: Becoming a contributor

[Denis Magda]

Hi Stephen,

This is good news! Added you to the list, please move on ;)

--
Denis

On Wed, Nov 7, 2018 at 2:31 AM Stephen Darlington <
stephen.darling...@gridgain.com> wrote:

> Hi,
>
> I’ve started to work on a couple of tickets:
>
> https://issues.apache.org/jira/browse/IGNITE-10155
> https://issues.apache.org/jira/browse/IGNITE-1436
>
> It would be great if I could be added to the list of contributors so I can
> assign the tickets to myself.
>
> Thanks,
> Stephen
>
>
>
>

[GitHub] ignite pull request #5345: IGNITE-10052: merged to 2.7

[AMashenkov]

GitHub user AMashenkov opened a pull request:

https://github.com/apache/ignite/pull/5345

IGNITE-10052: merged to 2.7

Added MVCC Tx logical WAL records.
Fix PDS recover from WAL.
Tests added.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-10052-2.7

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5345.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5345


commit 686115f93543efdf6389d65733038d047b718091
Author: Andrey V. Mashenkov 
Date:   2018-11-07T09:55:51Z

IGNITE-10052: Fixed MVCC Tx state restore from WAL.

Added MVCC Tx logical WAL records.
Fix PDS recover from WAL.
Tests added.




---

Re: [DISCUSSION] The process of creating an Ignite Enhancement Proposal

[Vladimir Ozerov]

Maxim,

I am not quite understand what is the problem with "many major enhancements
per IEP" and terms such as "optimization" or so. The very goal of initial
IEP process was to accumulate global ideas, so that one may quickly
understand potentially hot areas around the product. This is about
informing community, not about planning and linking to release notes.

Next, I fully agree that it is very good to have isolated IEP describing a
single major change. However, please note that a lot of IEPs start as
research activities. During this time we do not know what correct solution
is, how many major changes would be needed, how many components will be
affected, and how many tickets will be filed. All of this can change
drastically during IEP lifetime. Which looks perfectly fine for me - we
know what to improve, but do not know yet how exactly. If it is about real
implementation or planning you can always create umbrella ticket or so.
Moreover, it is also OK for IEPs to span multiple releases, e.g. this is
how we do this with TDE - huge change, multiple phases, multiple releases.

About names - again, ideally they should be concrete and non ambiguous. But
currently most of immediate product goals are around stabilization and
performance. This is really where we are. So if I, for example,
investigated a set of potential optimizations in area X, why can't I name
it "Optimize X"? If someone else will find more optimizations in the same
are while the first IEP is still active, he can join this IEP. If he find
them after first IEP is completed, then he can name it "Optimize X part 2",
while "Optimize X" will be in archive directory. So who really cares?

I do not see how enforcing any strict rules could help us here.

+1 for the rest.

On Wed, Nov 7, 2018 at 7:36 PM Maxim Muzafarov  wrote:

> Igniters,
>
> I think, our community have accumulated enough experience with the process
> of
> Ignite Enhancement Proposal (IEP) of introducing the major changes
> into the Apache
> Ignite. Now we have to take one step forward and make every major change
> and\or
> improvement clear not only for community developers but also for the
> Apache Ignite
> users too.
>
> Currently, I've seen two different strategies with creating IEPs:
>  - Single IEP per single major improvement;
>  - Single IEP per unit of functionality (group a few major improvements);
>
> Both of them have different advantages and disadvantages.
>
>
> Let's remove the ambiguity and build a convenient working process. For
> example,
> we may consider the best practices used in other open-source projects [2]
> [3].
>
> I propose to (and also propose to update the corresponding wiki page [1]
> and our
> community processes):
>  - use to "Single IEP per single major improvement" approach;
>  - do not group the major enhancements into the single IEP;
>  - avoid inaccurate proposal names (e.g. optimization, improvement,
> stabilization of etc.);
>  - for any public API changes create the IEP;
>  - add a `compatibility\mirgration` section to IEP Template;
>  - add a `public API changes` section to the IEP Template;
>  - link each major release note with the corresponding IEP page (users
> will have a
>better understanding of each feature).
>
>  Igniters, please, share your thoughts.
>
>
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Enhancement+Proposal
> [2]
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
> [3]
> https://cwiki.apache.org/confluence/display/SAMZA/Samza+Enhancement+Proposal
>

Re: Is it time to move forward to JUnit4 (5)?

[oignatenko]

Hello,

I created JIRA task for this move, with detailed explanation and
step-by-step subtasks, your comments are welcome:

- https://issues.apache.org/jira/browse/IGNITE-10173

In brief, the plan is to gradually migrate the part of tests that still uses
Junit 3 (hundreds if not thousands of those that depend on GridAbstractTest
and its subclasses) to newer version. The trick proposed to avoid doing all
this in one (big and risky) step is to introduce a Junit4-based "twin" of
GridAbstractTest (and respective twins of its subclasses) and use it to
gradually change tests to use that newer API instead.

After above is over, Junit 3 and all its related stuff (including
GridAbstractTest) could be safely removed from project.

regards, Oleg




--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-10180) Investigate migration from Junit 4 to 5

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10180:
---

 Summary: Investigate migration from Junit 4 to 5
 Key: IGNITE-10180
 URL: https://issues.apache.org/jira/browse/IGNITE-10180
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


If needed, refer parent task for more details.

Find out if Junit 5 is mature enough - specifically why maven still uses Junit 
4 as default, are there serious reasons for that or not. If it looks okay, 
create a new JIRA task to migrate.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10179:
---

 Summary: Change new tests root to use @BeforeClass and @AfterClass 
instead of isFirstTest() and isLastTest()
 Key: IGNITE-10179
 URL: https://issues.apache.org/jira/browse/IGNITE-10179
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


If needed, refer parent task for more details.

isFirstTest() and isLastTest() homebrew methods seem to be in GridAbstractTest 
only because Junit 3 lacked necessary functionality; after migration to Junit 4 
these would better changed to use standard API of this framework.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10177) cleanup Junit 3 from the project

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10177:
---

 Summary: cleanup Junit 3 from the project
 Key: IGNITE-10177
 URL: https://issues.apache.org/jira/browse/IGNITE-10177
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


If needed, refer parent task for more details.

1) remove deprecated API of GridAbstractTest and its subclasses 2) remove 
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior 
steps, if there are any



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10178) change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA ticket URL")

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10178:
---

 Summary: change tests that fail("Ignite JIRA ticket URL") to 
@Ignore("Ignite JIRA ticket URL")
 Key: IGNITE-10178
 URL: https://issues.apache.org/jira/browse/IGNITE-10178
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


If needed, refer parent task for more details.

Note this step would better be coordinated with Teamcity and TC bot maintainers 
because it may substantially impact them



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10176) migrate non-core modules tests from Junit 3 to 4

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10176:
---

 Summary: migrate non-core modules tests from Junit 3 to 4
 Key: IGNITE-10176
 URL: https://issues.apache.org/jira/browse/IGNITE-10176
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


If needed, refer parent task for more details.

Migrate using new API introduced and tested at prior step.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10175) migrate core module tests from Junit 3 to 4

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10175:
---

 Summary: migrate core module tests from Junit 3 to 4
 Key: IGNITE-10175
 URL: https://issues.apache.org/jira/browse/IGNITE-10175
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


If needed, refer parent task for more details.

Migrate using new API introduced at prior step.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10174) migrate examples tests from Junit 3 to 4

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10174:
---

 Summary: migrate examples tests from Junit 3 to 4
 Key: IGNITE-10174
 URL: https://issues.apache.org/jira/browse/IGNITE-10174
 Project: Ignite
  Issue Type: Sub-task
Reporter: Oleg Ignatenko


If needed, refer parent task for more details.

This is first task because examples are most publicly visible, relativelly 
small and least risky part of unit tests in the project.
Steps: 1) create Junit-4 based twin of GridAbstractTest (and all needed 
subclasses), 2) declare GridAbstractTest deprecated with reference to use newer 
API instead 3) change unit tests in examples to use new API



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10173) Gradually move unit tests from Junit 3 to newer version

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10173:
---

 Summary: Gradually move unit tests from Junit 3 to newer version
 Key: IGNITE-10173
 URL: https://issues.apache.org/jira/browse/IGNITE-10173
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.6
Reporter: Oleg Ignatenko


(i) Related dev list discussion: [Is it time to move forward to JUnit4 
(5)?|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html]

Currently unit tests in the project are mix of two versions Junit 3 and 4. This 
makes it hard to develop and maintain.

Another reason why migration to newer version is desirable is Junit 4 provides 
developer an option to conveniently mute tests by Ignore annotation while with 
Junit 3 this could only be done by adding fail and manually muting the test in 
Teamcity (the latter turned out to be extremely painful when I had to do some 
things per IGNITE-9884).

This task is to migrate all tests to single uniform version Junit 4 (with 
further option to migrate to Junit 5, see also note below).

The difficulty of migration is that too many tests depend on Junit3-based 
[GridAbstractTest|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java]
 and its subclasses so that making them all change in a single move would be 
very tedious and risky. A way to work around this is to create a parallel 
Junit-4 based "twin" of GridAbstractTest (tentative name 
{{IgniteAbstractTest}}) and using is move to Junit 4 gradually, smoothly and 
safely.

Step by step plan of changes is below (to be further made to sub-tasks under 
this "umbrella" ticket):
 # migrate examples tests from Junit 3 to 4
 This is first task because examples are most publicly visible, relativelly 
small and least risky part of unit tests in the project.
 Steps: 1) create Junit-4 based twin of GridAbstractTest (and all needed 
subclasses), 2) declare GridAbstractTest deprecated with reference to use newer 
API instead 3) change unit tests in examples to use new API
 # migrate core module tests from Junit 3 to 4
 using new API introduced and tested at prior step
 # migrate non-core modules tests from Junit 3 to 4
 using new API introduced and tested at prior step
 # cleanup Junit 3 from the project
 1) remove deprecated API of GridAbstractTest and its subclasses 2) remove 
dependencies from Junit 3 in Maven 3) migrate tests that were missed at prior 
steps, if there are any
 # change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA 
ticket URL")
 Note this step would better be coordinated with Teamcity and TC bot 
maintainers because it may substantially impact them
 # Change new tests root to use @BeforeClass and @AfterClass instead of 
isFirstTest() and isLastTest()
 these homebrew methods seem to be in GridAbstractTest only because Junit 3 
lacked necessary functionality; after migration to Junit 4 these would better 
changed to use standard API of this framework.
 # Investigate migration from Junit 4 to 5
 Find out if Junit 5 is mature enough - specifically why maven still uses Junit 
4 as default, are there serious reasons for that or not. If it looks okay, 
create a new JIRA task to migrate.


Note on migrating to Junit 5. While preparing this task I considered an option 
to migrate from Junit 3 to 5 instead of 4.

I dropped that primarily because migration from Junit 3 requires quite a lot of 
manual changes in the code (changing imports and adding annotations), as 
opposed to migration from Junit 4 to 5 for which there seem to be options to 
make most changes automatically (eg IntelliJ seem to provide such an option). 
Because of that it looks more convenient to split it to separate steps, so that 
after all tests in the project get to Junit 4 we could do an automated 
migration to newer version.

Another thing that made me prefer this way is that I wanted to avoid having 
three different versions Junit in the project (3, 4, 5), even if that would be 
temporarily (note that migration from Junit 3 is expected to be manual and 
quite lengthy, so "temporarily" may mean quite a lot of time really).

Also note that as pointed in above list of steps we better make some 
preliminary assessment on whether time has really come to migrate to Junit 5.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[DISCUSSION] The process of creating an Ignite Enhancement Proposal

[Maxim Muzafarov]

Igniters,

I think, our community have accumulated enough experience with the process of
Ignite Enhancement Proposal (IEP) of introducing the major changes
into the Apache
Ignite. Now we have to take one step forward and make every major change and\or
improvement clear not only for community developers but also for the
Apache Ignite
users too.

Currently, I've seen two different strategies with creating IEPs:
 - Single IEP per single major improvement;
 - Single IEP per unit of functionality (group a few major improvements);

Both of them have different advantages and disadvantages.


Let's remove the ambiguity and build a convenient working process. For example,
we may consider the best practices used in other open-source projects [2] [3].

I propose to (and also propose to update the corresponding wiki page [1] and our
community processes):
 - use to "Single IEP per single major improvement" approach;
 - do not group the major enhancements into the single IEP;
 - avoid inaccurate proposal names (e.g. optimization, improvement,
stabilization of etc.);
 - for any public API changes create the IEP;
 - add a `compatibility\mirgration` section to IEP Template;
 - add a `public API changes` section to the IEP Template;
 - link each major release note with the corresponding IEP page (users
will have a
   better understanding of each feature).

 Igniters, please, share your thoughts.



[1] 
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Enhancement+Proposal
[2] 
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
[3] https://cwiki.apache.org/confluence/display/SAMZA/Samza+Enhancement+Proposal

[GitHub] ignite pull request #5333: IGNITE-10157 Removed 2 extra @SuppressWarnings th...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/5333


---

[jira] [Created] (IGNITE-10172) Enabling cache statistics on a large cluster with a large number of caches can affect performance

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-10172:
--

 Summary: Enabling cache statistics on a large cluster with a large 
number of caches can affect performance
 Key: IGNITE-10172
 URL: https://issues.apache.org/jira/browse/IGNITE-10172
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.6
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
 Fix For: 2.8


In current implementation cache metrics are collected on each node and sent 
across whole cluster with discovery message 
({{TcpDiscoveryMetricsUpdateMessage}}) with configured frequency 
({{MetricsUpdateFrequency}}, 2 seconds by default).
If there are a lot of caches and a lot of nodes in the cluster, metrics update 
message (which contain metrics for each cache on each node) can reach a 
critical size.
Also frequently collecting all cache metrics have a negative performance impact.
The only way now to disable cache metrics collecting and sending with discovery 
metrics update message is to disable statistics for each cache. But this also 
makes impossible to request some of cache metrics locally (for the current node 
only). Requesting a limited set of cache metrics on the current node doesn't 
have such performance impact as the frequent collecting of all cache metrics, 
but sometimes it's enough for diagnostic purposes.

To solve this introduce new system property which will disable cache metrics 
sending with {{TcpDiscoveryMetricsUpdateMessage}} even if {{statisticsEnabled}} 
flag is true.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] zzzadruga opened a new pull request #61: IGNITE-10169 Show tests and problems values on graphs

[GitBox]

zzzadruga opened a new pull request #61: IGNITE-10169 Show tests and problems 
values on graphs
URL: https://github.com/apache/ignite-teamcity-bot/pull/61
 
 
   IGNITE-10169 Show tests and problems values on graphs instead of the build 
start date


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (IGNITE-10171) Running queries descriptor (GridRunningQueryInfo) contains generated SQL text instead of original SQL text

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-10171:
--

 Summary: Running queries descriptor (GridRunningQueryInfo) 
contains generated SQL text instead of original SQL text
 Key: IGNITE-10171
 URL: https://issues.apache.org/jira/browse/IGNITE-10171
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.6
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
 Fix For: 2.8


Running queries descriptors ({{GridRunningQueryInfo}}) for SQL queries received 
by {{GridQueryProcessor#runningQueries()}} method contains SQL text generated 
from parsed query structure. For diagnostic purposes it's better to store 
original SQL query text instaed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Service grid redesign

[Vyacheslav Daradur]

Dmitriy, I published documentation in wiki:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584

Thank you!
On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov  wrote:
>
> Hi I think wiki is better than any attached docs. Could you please create a
> page?
>
> ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur :
>
> > I prepared a description of the implemented solution and attached it
> > to the issue [1].
> >
> > This should help during a review. Should I post the document into wiki or
> > IEP?
> >
> > I'd like to ask Ignite's experts review the solution [1] [2], please?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > [2] https://github.com/apache/ignite/pull/4434
> > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur 
> > wrote:
> > >
> > > Hi, Igniters! Good news!
> > >
> > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > >
> > > Nikolay Izhikov has reviewed implementation.
> > >
> > > However, we need additional review from other Ignite experts.
> > >
> > > Here is an umbrella ticket [1] and PR [2].
> > >
> > > Could someone step in and do the review?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > [2] https://github.com/apache/ignite/pull/4434
> > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov 
> > wrote:
> > > >
> > > > Pavel, could you assist?
> > > >
> > > > Does it make sense for .Net to specify service class name instead of
> > its
> > > > implementation?
> > > >
> > > > I think, it shouldn't be a problem.
> > > >
> > > > Denis
> > > >
> > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur 
> > wrote:
> > > >
> > > > > I think that the replacement of serialized instance makes sense to me
> > > > > for Java part.
> > > > >
> > > > > But how it should work for .NET client?
> > > > >
> > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > nsamelc...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello, Igniters.
> > > > > > >
> > > > > > > I am working on task [1] that would replace serialized service's
> > > > > instance
> > > > > > > by service's class name and properties map in
> > {ServiceConfiguration}.
> > > > > > >
> > > > > > > The task describes that we should use
> > > > > > > {String className} + {Map properties} instead
> > {Service
> > > > > > > srvc}.
> > > > > > >
> > > > > > > I'd like to clarify the following questions:
> > > > > > >
> > > > > > > 1. What about public methods?
> > > > > > > I suggest to mark them as deprecated and use class name of
> > provided
> > > > > > > instance.
> > > > > > > Also to add deploying methods with new parameters:
> > > > > > >
> > > > > > > @Deprecated
> > > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, Service svc)
> > > > > > >
> > > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, String srvcClsName, Map prop)
> > > > > > >
> > > > > >
> > > > > > I think this makes sense, but I would like other committers to
> > confirm.
> > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > >
> > > > > >
> > > > > > > 2. Is {Map properties} parameter mandatory when
> > > > > deploying a
> > > > > > > service?
> > > > > > > Is it make sense to add deploying methods without it? For
> > example:
> > > > > > >
> > > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, String srvcClsName)
> > > > > > >
> > > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, String srvcClsName, Map prop)
> > > > > > >
> > > > > >
> > > > > > I would always ask the user to pass the property map, but would
> > allow it
> > > > > to
> > > > > > be null.
> > > > > >
> > > > > > D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Re: Wiki permissions to publish a new design document

[Vyacheslav Daradur]

Dmitriy, it works! Thank you so much!
On Wed, Nov 7, 2018 at 5:38 PM Dmitriy Pavlov  wrote:
>
> Vyacheslav, I've added permission. Please check if it's working.
>
> ср, 7 нояб. 2018 г. в 17:31, Vyacheslav Daradur :
>
> > Hi, Igniters!
> >
> > I need permissions to publish a new design document describes Service
> > Grid implementation details.
> >
> > Could someone grant me permissions?
> >
> > Wiki's registered e-mail: daradu...@gmail.com
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

[GitHub] ignite pull request #5249: IGNITE-10133: Switch to per-node TensorFlow worke...

[dmitrievanthony]

Github user dmitrievanthony closed the pull request at:

https://github.com/apache/ignite/pull/5249


---

[GitHub] ignite pull request #5313: IGNITE-10149: Make ignite-tf.sh executable by def...

[dmitrievanthony]

Github user dmitrievanthony closed the pull request at:

https://github.com/apache/ignite/pull/5313


---

[jira] [Created] (IGNITE-10170) .NET: Services.ServicesTestAsync fails

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-10170:
-

 Summary: .NET: Services.ServicesTestAsync fails
 Key: IGNITE-10170
 URL: https://issues.apache.org/jira/browse/IGNITE-10170
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Suntsov


Test run: 
[https://ci.ignite.apache.org/viewLog.html?buildId=2263939&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNet]

Error message:

{noformat}Test(s) failed. Expected: True
 But was: False

at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, 
String message, Object[] args)
 at Apache.Ignite.Core.Tests.Services.ServicesTest.CheckServiceStarted(IIgnite 
grid, Int32 count, String svcName) in 
c:\BuildAgent\work\9198da4c51c3e112\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Services\ServicesTest.cs:line
 1010
 at Apache.Ignite.Core.Tests.Services.ServicesTest.TestCancelException() in 
c:\BuildAgent\work\9198da4c51c3e112\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Services\ServicesTest.cs:line
 745
--- Stderr: ---
[07-11-2018 14:20:33][INFO ][srvc-deploy-#18766%grid1%][GridServiceProcessor] 
Starting service instance [name=Service1, 
execId=e0264c92-3df3-49d8-bac7-d9b40f749161]
[07-11-2018 14:20:34][INFO ][srvc-deploy-#18816%grid2%][GridServiceProcessor] 
Starting service instance [name=Service1, 
execId=f920c229-b91e-4c92-8efe-f19b0fc03d0b]
[07-11-2018 14:20:34][INFO ][srvc-deploy-#18816%grid2%][GridServiceProcessor] 
Cancelled service instance [name=Service1, 
execId=f920c229-b91e-4c92-8efe-f19b0fc03d0b]
[07-11-2018 14:20:34][INFO ][srvc-deploy-#18766%grid1%][GridServiceProcessor] 
Cancelled service instance [name=Service1, 
execId=e0264c92-3df3-49d8-bac7-d9b40f749161]

{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Wiki permissions to publish a new design document

[Dmitriy Pavlov]

Vyacheslav, I've added permission. Please check if it's working.

ср, 7 нояб. 2018 г. в 17:31, Vyacheslav Daradur :

> Hi, Igniters!
>
> I need permissions to publish a new design document describes Service
> Grid implementation details.
>
> Could someone grant me permissions?
>
> Wiki's registered e-mail: daradu...@gmail.com
>
> --
> Best Regards, Vyacheslav D.
>

Wiki permissions to publish a new design document

[Vyacheslav Daradur]

Hi, Igniters!

I need permissions to publish a new design document describes Service
Grid implementation details.

Could someone grant me permissions?

Wiki's registered e-mail: daradu...@gmail.com

--
Best Regards, Vyacheslav D.

[GitHub] ignite pull request #5344: IGNITE-10158 Some tests in IgniteCacheAbstractQue...

[oignatenko]

GitHub user oignatenko opened a pull request:

https://github.com/apache/ignite/pull/5344

IGNITE-10158 Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly 
muted



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-10158

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5344.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5344


commit fa7662e7fbc410a5064815f16838e0ef91b0683b
Author: Alexey Platonov 
Date:   2018-11-07T11:53:58Z

init commit

commit 2afea369eaf285c3d42c377c46161a5041ab0bb0
Author: Alexey Platonov 
Date:   2018-11-07T11:56:23Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-10159

commit ac6414e0c5a2e2b6fe75b6b170fb988421ca1c5d
Author: Oleg Ignatenko 
Date:   2018-11-07T14:14:22Z

IGNITE-10158 Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly 
muted
- fixed as suggested in the ticket
-- verified with diffs overview, clean rebuild and trial execution of 
modified tests on my machine




---

Re: Service grid redesign

[Dmitriy Pavlov]

Hi I think wiki is better than any attached docs. Could you please create a
page?

ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur :

> I prepared a description of the implemented solution and attached it
> to the issue [1].
>
> This should help during a review. Should I post the document into wiki or
> IEP?
>
> I'd like to ask Ignite's experts review the solution [1] [2], please?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9607
> [2] https://github.com/apache/ignite/pull/4434
> On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur 
> wrote:
> >
> > Hi, Igniters! Good news!
> >
> > Service Grid Redesign Phase 1 - is in Patch Available now.
> >
> > Nikolay Izhikov has reviewed implementation.
> >
> > However, we need additional review from other Ignite experts.
> >
> > Here is an umbrella ticket [1] and PR [2].
> >
> > Could someone step in and do the review?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > [2] https://github.com/apache/ignite/pull/4434
> > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov 
> wrote:
> > >
> > > Pavel, could you assist?
> > >
> > > Does it make sense for .Net to specify service class name instead of
> its
> > > implementation?
> > >
> > > I think, it shouldn't be a problem.
> > >
> > > Denis
> > >
> > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur 
> wrote:
> > >
> > > > I think that the replacement of serialized instance makes sense to me
> > > > for Java part.
> > > >
> > > > But how it should work for .NET client?
> > > >
> > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > > > wrote:
> > > > >
> > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> nsamelc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello, Igniters.
> > > > > >
> > > > > > I am working on task [1] that would replace serialized service's
> > > > instance
> > > > > > by service's class name and properties map in
> {ServiceConfiguration}.
> > > > > >
> > > > > > The task describes that we should use
> > > > > > {String className} + {Map properties} instead
> {Service
> > > > > > srvc}.
> > > > > >
> > > > > > I'd like to clarify the following questions:
> > > > > >
> > > > > > 1. What about public methods?
> > > > > > I suggest to mark them as deprecated and use class name of
> provided
> > > > > > instance.
> > > > > > Also to add deploying methods with new parameters:
> > > > > >
> > > > > > @Deprecated
> > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, Service svc)
> > > > > >
> > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, String srvcClsName, Map prop)
> > > > > >
> > > > >
> > > > > I think this makes sense, but I would like other committers to
> confirm.
> > > > > Perhaps Vladimir Ozerov should comment here.
> > > > >
> > > > >
> > > > > > 2. Is {Map properties} parameter mandatory when
> > > > deploying a
> > > > > > service?
> > > > > > Is it make sense to add deploying methods without it? For
> example:
> > > > > >
> > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, String srvcClsName)
> > > > > >
> > > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, String srvcClsName, Map prop)
> > > > > >
> > > > >
> > > > > I would always ask the user to pass the property map, but would
> allow it
> > > > to
> > > > > be null.
> > > > >
> > > > > D.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[jira] [Created] (IGNITE-10169) Show tests and problems values on graphs

[Nikolai Kulagin (JIRA)]

Nikolai Kulagin created IGNITE-10169:


 Summary: Show tests and problems values on graphs
 Key: IGNITE-10169
 URL: https://issues.apache.org/jira/browse/IGNITE-10169
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolai Kulagin
Assignee: Nikolai Kulagin


Show tests and problems values on graphs (currently shows build's start time).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10167) MVCC-compatible IgniteCache.localEntries

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-10167:
---

 Summary: MVCC-compatible IgniteCache.localEntries
 Key: IGNITE-10167
 URL: https://issues.apache.org/jira/browse/IGNITE-10167
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Pavlukhin


IgniteCache API method {{localEntries}} should be supported. The idea is to 
provide an entries iterator seeing latest committed versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10168) SQL security monitoring

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-10168:
--

 Summary: SQL security monitoring
 Key: IGNITE-10168
 URL: https://issues.apache.org/jira/browse/IGNITE-10168
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Yury Gerzhedovich


Security monitoring: For each query we should track who started query: subject 
id, application name/module/label



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10166) JDBC session level IO stats ON/OFF

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-10166:
--

 Summary: JDBC session level IO stats ON/OFF
 Key: IGNITE-10166
 URL: https://issues.apache.org/jira/browse/IGNITE-10166
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Yury Gerzhedovich


IO stats could be enabled/disabled for the given session through SQL commands, 
e.g. *_SET STATISTICS _*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10165) Gather query stats and expose interfaces to access it

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-10165:
--

 Summary: Gather query stats and expose interfaces to access it
 Key: IGNITE-10165
 URL: https://issues.apache.org/jira/browse/IGNITE-10165
 Project: Ignite
  Issue Type: Task
Reporter: Yury Gerzhedovich


For all executed queries we should gather statistics. They should be grouped by 
SQL query and have at least min, max, avg time of execution; min, max, avg of 
IO operations (when IO stats are enabled); number of executions. Access to the 
statistics should be provided through both JMX and system SQL view



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #5336: IGNITE-10159: IgniteCacheAbstractQuerySelfTest.te...

[avplatonov]

GitHub user avplatonov opened a pull request:

https://github.com/apache/ignite/pull/5336

IGNITE-10159: IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap 
fails non-null assertion at localPeek



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-10159

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5336.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5336


commit fa7662e7fbc410a5064815f16838e0ef91b0683b
Author: Alexey Platonov 
Date:   2018-11-07T11:53:58Z

init commit

commit 2afea369eaf285c3d42c377c46161a5041ab0bb0
Author: Alexey Platonov 
Date:   2018-11-07T11:56:23Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-10159




---

[GitHub] ignite pull request #5335: IGNITE-10148. Add yardstick AWS configs

[isuntsov-gridgain]

GitHub user isuntsov-gridgain opened a pull request:

https://github.com/apache/ignite/pull/5335

IGNITE-10148. Add yardstick AWS configs

Added yardstick AWS (S3, ELB) configs.
 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/isuntsov-gridgain/ignite ignite-10148

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5335.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5335


commit 2a09bdf5a1a419a9949b31f2286a420625bbe2d3
Author: Ilya Sunstsov 
Date:   2018-11-07T12:46:55Z

Fixed yardstick pom

commit d0d48aa75ec18c50ad95fbc89f3465226915e457
Author: Ilya Sunstsov 
Date:   2018-11-07T12:47:27Z

Added AWS configs




---

[jira] [Created] (IGNITE-10164) Support query cancel for ODBC and thin clients

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-10164:
--

 Summary: Support query cancel for ODBC and thin clients
 Key: IGNITE-10164
 URL: https://issues.apache.org/jira/browse/IGNITE-10164
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Yury Gerzhedovich


Need to support query cancel for ODBC and thin clients



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10163) Support query cancel for JDBC, ODBC and thin clients

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-10163:
--

 Summary: Support query cancel for JDBC, ODBC and thin clients
 Key: IGNITE-10163
 URL: https://issues.apache.org/jira/browse/IGNITE-10163
 Project: Ignite
  Issue Type: Task
  Components: sql
 Environment: Need to support query cancel for JDBC - 
Statement.cancel() method
Reporter: Yury Gerzhedovich






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10162) IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch fails with IgniteCheckedException: Failed to find SQL table for type: ObjectValue

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10162:
---

 Summary: IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch 
fails with IgniteCheckedException: Failed to find SQL table for type: 
ObjectValue
 Key: IGNITE-10162
 URL: https://issues.apache.org/jira/browse/IGNITE-10162
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko


IgniteCacheAtomicQuerySelfTest#testTwoObjectsTextSearch (in current codebase 
muted by renaming to {{_testTwoObjectsTextSearch}}) fails:
{noformat}
[2018-11-07 14:37:32,728][INFO 
][grid-nio-worker-tcp-comm-1-#91%near.IgniteCacheAtomicQuerySelfTest1%][IgniteCachePartitionedQuerySelfTest$TestTcpCommunicationSpi]
 Accepted incoming communication connection [locAddr=/127.0.0.1:47101, 
rmtAddr=/127.0.0.1:57395][2018-11-07 14:37:32,728][WARN 
][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor] 
Key-value pair is not inserted into any SQL table [cacheName=Object-Object, 
valType=o.a.i.i.processors.cache.IgniteCacheAbstractQuerySelfTest$ObjectValue]
[2018-11-07 14:37:32,728][WARN 
][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]   
^-- Value type(s) are specified via CacheConfiguration.indexedTypes or 
CacheConfiguration.queryEntities
[2018-11-07 14:37:32,728][WARN 
][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]   
^-- Make sure that same type(s) used when adding Object or BinaryObject to cache
[2018-11-07 14:37:32,728][WARN 
][sys-stripe-1-#61%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor]   
^-- Otherwise, entries will be stored in cache, but not appear as SQL Table rows
[2018-11-07 14:37:32,744][INFO 
][grid-nio-worker-tcp-comm-1-#94%near.IgniteCacheAtomicQuerySelfTest2%][IgniteCachePartitionedQuerySelfTest$TestTcpCommunicationSpi]
 Established outgoing communication connection [locAddr=/127.0.0.1:57395, 
rmtAddr=/127.0.0.1:47101]
[2018-11-07 14:37:32,766][WARN 
][sys-stripe-6-#66%near.IgniteCacheAtomicQuerySelfTest2%][GridQueryProcessor] 
Key-value pair is not inserted into any SQL table [cacheName=Object-Object, 
valType=o.a.i.i.processors.cache.IgniteCacheAbstractQuerySelfTest$ObjectValueOther]
[2018-11-07 
14:37:32,867][ERROR][query-#150%near.IgniteCacheAtomicQuerySelfTest2%][GridCacheDistributedQueryManager]
  Failed to run query [qry=GridCacheQueryInfo [loc=false, 
trans=null, rdc=null, qry=GridCacheQueryAdapter [type=TEXT, 
clsName=ObjectValue, clause=str, filter=null, transform=null, part=null, 
incMeta=false, metrics=null, pageSize=1024, timeout=0, incBackups=false, 
forceLocal=false, dedup=false, prj=null, keepBinary=false, 
subjId=964a4e0a-38e6-47db-b91c-95d3c410, taskHash=0, mvccSnapshot=null], 
locFut=null, sndId=964a4e0a-38e6-47db-b91c-95d3c410, reqId=27, 
incMeta=false, all=false], node=5c1facf8-cf09-498f-bdf0-e75f9942]
class org.apache.ignite.IgniteCheckedException: Failed to find SQL table for 
type: ObjectValue
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.typeName(GridQueryProcessor.java:2675)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.access$500(GridQueryProcessor.java:129)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$9.applyx(GridQueryProcessor.java:2617)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$9.applyx(GridQueryProcessor.java:2615)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2696)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.queryText(GridQueryProcessor.java:2614)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.executeQuery(GridCacheQueryManager.java:614)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.queryResult(GridCacheQueryManager.java:1472)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1106)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:234)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:109)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:107)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(Grid

[jira] [Created] (IGNITE-10161) Be able to cancel any query by query id

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-10161:
--

 Summary: Be able to cancel any query by query id
 Key: IGNITE-10161
 URL: https://issues.apache.org/jira/browse/IGNITE-10161
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Yury Gerzhedovich
Assignee: Yury Gerzhedovich
 Fix For: 2.8


User should be able to cancel any query by query id through both JMX and SQL 
command.

SQL syntax: *KILL QUERY _ _*

Query should be canceled  together with its parts on all nodes. 

Initial cancel query sends to initial node *node_id* which can cancel all 
related parts of query on other nodes. In case *node_id* node not available 
cancel query should be sent all nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #5334: IGNITE-10118: JDBC v2 getSchema fix.

[pavel-kuznetsov]

GitHub user pavel-kuznetsov opened a pull request:

https://github.com/apache/ignite/pull/5334

IGNITE-10118: JDBC v2 getSchema fix.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-10118

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5334.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5334


commit c8521cb526367a2d9448dcb7e1ca500e8494b74b
Author: Pavel Kuznetsov 
Date:   2018-11-06T00:01:46Z

ignite-9989: Draft of the fix.

In jdbc v2, now we avoid using distributed task that fetches metadata to
get PK metadata. We use existing cache descriptors instead.

commit 1e7b3f1947da236b071465c661525ffbe40af06b
Author: Pavel Kuznetsov 
Date:   2018-11-06T14:39:11Z

ignite-9989: Updated tests to work with many tables.

Backported test for primary keys metadata from metadata test of jdbc
thin driver. This change made IGNITE-10118 highlighted.

commit f12c8549b0de14a3dbecc464d5f19d927560ca56
Author: Pavel Kuznetsov 
Date:   2018-11-06T14:50:01Z

ignite-9989: Jdbc v2 PK meta refactoring.

javadoc, moved method to QueryUtils.

commit 033e7613912d86ed85b5316a4f32838f6d5575fb
Author: Pavel Kuznetsov 
Date:   2018-11-07T12:04:01Z

ignite-9989: Added missed catalog validation.

commit 3ab5bab624d8ab54a36dd4bf55de5ab37c98e901
Author: Pavel Kuznetsov 
Date:   2018-11-07T11:16:41Z

ignite-10118: Draft of the fix.

Schemas metadata now is fetched from GridKernalContext directly.

commit 7662d4de591e6deebdb2596d9e7916d0a3c53921
Author: Pavel Kuznetsov 
Date:   2018-11-07T11:47:07Z

ignite-10118: Refactoring.

Use lightweight view of collection of cache descriptors instead of
for-loop with filter over that collection.

commit 53194e807c691a58e2981a3a2108a4d6477902e7
Author: Pavel Kuznetsov 
Date:   2018-11-07T12:12:43Z

ignite-10118: Added missing schema name filtering.




---

[jira] [Created] (IGNITE-10160) Add unique identifier for all SQL queries

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-10160:
--

 Summary: Add unique identifier for all SQL queries
 Key: IGNITE-10160
 URL: https://issues.apache.org/jira/browse/IGNITE-10160
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Yury Gerzhedovich
Assignee: Yury Gerzhedovich
 Fix For: 2.8


Each of execution query should have unique identifier for whole cluster. It 
could be an initial node UUID + sequentially growing number of an executing 
queries on the node. As example: *b3c0624a-122c-46ea-9d65-67b56df1* and 
*341*. This query id should be used for all of the query parts executed on 
other nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10159) IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap fails non-null assertion at localPeek

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10159:
---

 Summary: IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap 
fails non-null assertion at localPeek
 Key: IGNITE-10159
 URL: https://issues.apache.org/jira/browse/IGNITE-10159
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko


IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap (in current codebase 
muted by renaming to {{_testObjectQueryWithSwap}}) fails with the following 
error:
{noformat}
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNotNull(Assert.java:256)
at junit.framework.Assert.assertNotNull(Assert.java:248)
at junit.framework.TestCase.assertNotNull(TestCase.java:417)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheAbstractQuerySelfTest.testObjectQueryWithSwap(IgniteCacheAbstractQuerySelfTest.java:960)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
...{noformat}

Code referred to above is:
{code}assertNotNull(c.localPeek(i, CachePeekMode.ONHEAP));{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Service grid redesign

[Vyacheslav Daradur]

I prepared a description of the implemented solution and attached it
to the issue [1].

This should help during a review. Should I post the document into wiki or IEP?

I'd like to ask Ignite's experts review the solution [1] [2], please?

[1] https://issues.apache.org/jira/browse/IGNITE-9607
[2] https://github.com/apache/ignite/pull/4434
On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur  wrote:
>
> Hi, Igniters! Good news!
>
> Service Grid Redesign Phase 1 - is in Patch Available now.
>
> Nikolay Izhikov has reviewed implementation.
>
> However, we need additional review from other Ignite experts.
>
> Here is an umbrella ticket [1] and PR [2].
>
> Could someone step in and do the review?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9607
> [2] https://github.com/apache/ignite/pull/4434
> On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov  
> wrote:
> >
> > Pavel, could you assist?
> >
> > Does it make sense for .Net to specify service class name instead of its
> > implementation?
> >
> > I think, it shouldn't be a problem.
> >
> > Denis
> >
> > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur  wrote:
> >
> > > I think that the replacement of serialized instance makes sense to me
> > > for Java part.
> > >
> > > But how it should work for .NET client?
> > >
> > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan 
> > > wrote:
> > > >
> > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev 
> > > > wrote:
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I am working on task [1] that would replace serialized service's
> > > instance
> > > > > by service's class name and properties map in {ServiceConfiguration}.
> > > > >
> > > > > The task describes that we should use
> > > > > {String className} + {Map properties} instead {Service
> > > > > srvc}.
> > > > >
> > > > > I'd like to clarify the following questions:
> > > > >
> > > > > 1. What about public methods?
> > > > > I suggest to mark them as deprecated and use class name of provided
> > > > > instance.
> > > > > Also to add deploying methods with new parameters:
> > > > >
> > > > > @Deprecated
> > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, Service svc)
> > > > >
> > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, String srvcClsName, Map prop)
> > > > >
> > > >
> > > > I think this makes sense, but I would like other committers to confirm.
> > > > Perhaps Vladimir Ozerov should comment here.
> > > >
> > > >
> > > > > 2. Is {Map properties} parameter mandatory when
> > > deploying a
> > > > > service?
> > > > > Is it make sense to add deploying methods without it? For example:
> > > > >
> > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, String srvcClsName)
> > > > >
> > > > > public IgniteInternalFuture deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, String srvcClsName, Map prop)
> > > > >
> > > >
> > > > I would always ask the user to pass the property map, but would allow it
> > > to
> > > > be null.
> > > >
> > > > D.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

[GitHub] ignite pull request #5214: IGNITE-9975 Set partition counters to 0 when rese...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/5214


---

[jira] [Created] (IGNITE-10158) Some tests in IgniteCacheAbstractQuerySelfTest are incorrectly muted

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10158:
---

 Summary: Some tests in IgniteCacheAbstractQuerySelfTest are 
incorrectly muted
 Key: IGNITE-10158
 URL: https://issues.apache.org/jira/browse/IGNITE-10158
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Oleg Ignatenko


Some tests in 
[IgniteCacheAbstractQuerySelfTest|https://github.com/apache/ignite/blob/master/modules/indexing/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheAbstractQuerySelfTest.java]
 are muted by renaming (prefixing with underscore, {{_test...}} and refer 
invalid JIRA URL in fail parameter 
("http://atlassian.gridgain.com/jira/browse/GG-11216";).

- _testDifferentKeyTypes
  this test should change expectation to opposite and after that recovered
- _testObjectQueryWithSwap and _testTwoObjectsTextSearch
  Need to be properly muted and further investigated, per separate tickets. Per 
my preliminary checks tests fail because
  of wrong cache configuration, although there is also a chance that test 
design is wrong and these should be deleted.

There is also a dead code there, a private class {{EmptyObject}} - it needs to 
be deleted. Code that was using this class was removed per 
[IGNITE-1232|https://issues.apache.org/jira/browse/IGNITE-1232] ([commit 
79b8b08|https://github.com/gridgain/apache-ignite/commit/68891e89dd0e0f19321d6a4d45ae7372279b8b08#diff-a2f35b3aa70a70b98ce0cd6a1381d1f7])
 but this private class was forgotten.

I also searched project code for other occurrences of mentioned troublesome 
fail parameter "GG-11216" and found yet another incorrectly muted test: 
{{IgniteCacheQueryMultiThreadedSelfTest#_testMultiThreadedSwapUnswapLongString}}
 This test should be recovered. It passed on my machine and per my comparison 
with similar test cases {{testMultiThreadedSwapUnswapLong}} and 
{{testMultiThreadedSwapUnswapString}} its design looks fairly reasonable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #5333: IGNITE-10157 Removed 2 extra @SuppressWarnings th...

[ibessonov]

GitHub user ibessonov opened a pull request:

https://github.com/apache/ignite/pull/5333

IGNITE-10157 Removed 2 extra @SuppressWarnings that suppressed nothing.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-10157

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5333.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5333


commit 66349c7cb7969222c0915b2cbc00ca4b84dc930c
Author: ibessonov 
Date:   2018-11-07T10:48:28Z

IGNITE-10157 Removed 2 extra @SuppressWarnings that suppressed nothing.




---

[GitHub] ignite pull request #5330: IGNITE-9870 GridDhtPartitionsFullMessage#prepareM...

[voropava]

GitHub user voropava reopened a pull request:

https://github.com/apache/ignite/pull/5330

IGNITE-9870 GridDhtPartitionsFullMessage#prepareMarshal compression 
parallelization.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9870

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5330.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5330


commit a988cd095c2e41a05701305a07b9140145d0bbe4
Author: Pavel Voronkin 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Implemented parallel GridDhtPartitionsFullMessage zip and unzip 
using getNetCompressionLevel() BEST_SPEED by default.

commit cd0e4555cdca4865e0fd9b06a23afd756510518e
Author: Pavel Voronkin 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Fixed javadoc.

commit ecae04a6810c10e24f079422b376797f022b84b4
Author: pereslegin-pa 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Fixed imports.




---

[GitHub] ignite pull request #5330: Ignite 9870

[voropava]

Github user voropava closed the pull request at:

https://github.com/apache/ignite/pull/5330


---

[GitHub] ignite pull request #5330: Ignite 9870

[voropava]

Github user voropava closed the pull request at:

https://github.com/apache/ignite/pull/5330


---

[GitHub] ignite pull request #5330: Ignite 9870

[voropava]

GitHub user voropava reopened a pull request:

https://github.com/apache/ignite/pull/5330

Ignite 9870



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9870

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5330.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5330


commit a988cd095c2e41a05701305a07b9140145d0bbe4
Author: Pavel Voronkin 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Implemented parallel GridDhtPartitionsFullMessage zip and unzip 
using getNetCompressionLevel() BEST_SPEED by default.

commit cd0e4555cdca4865e0fd9b06a23afd756510518e
Author: Pavel Voronkin 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Fixed javadoc.

commit ecae04a6810c10e24f079422b376797f022b84b4
Author: pereslegin-pa 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Fixed imports.




---

[jira] [Created] (IGNITE-10157) Fix inspections failures in GridTestUtils

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-10157:
--

 Summary: Fix inspections failures in GridTestUtils
 Key: IGNITE-10157
 URL: https://issues.apache.org/jira/browse/IGNITE-10157
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


Fix these fails:

https://ci.ignite.apache.org/viewLog.html?buildId=2261996&tab=Inspection&buildTypeId=IgniteTests24Java8_InspectionsCore



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #5332: IGNITE-10156 Fixed converting DynamicCacheDescrip...

[akalash]

GitHub user akalash opened a pull request:

https://github.com/apache/ignite/pull/5332

IGNITE-10156 Fixed converting DynamicCacheDescriptor to StoredCacheDa…

…ta during saving

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-10156

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5332.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5332


commit b8856da786a9afb7d7a33969eb9f96ddc5113383
Author: Anton Kalashnikov 
Date:   2018-11-02T16:08:14Z

IGNITE-10156 Fixed converting DynamicCacheDescriptor to StoredCacheData 
during saving




---

[GitHub] ignite pull request #5331: GG-13597 Fixed converting DynamicCacheDescriptor ...

[akalash]

GitHub user akalash opened a pull request:

https://github.com/apache/ignite/pull/5331

GG-13597 Fixed converting DynamicCacheDescriptor to StoredCacheData d…

…uring saving

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-10156

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5331.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5331


commit 1b7540923005d66549399cd1f8de5a83b76ecc3e
Author: Anton Kalashnikov 
Date:   2018-11-02T16:08:14Z

GG-13597 Fixed converting DynamicCacheDescriptor to StoredCacheData during 
saving




---

[GitHub] ignite pull request #5331: GG-13597 Fixed converting DynamicCacheDescriptor ...

[akalash]

Github user akalash closed the pull request at:

https://github.com/apache/ignite/pull/5331


---

Becoming a contributor

[Stephen Darlington]

Hi,

I’ve started to work on a couple of tickets:

https://issues.apache.org/jira/browse/IGNITE-10155
https://issues.apache.org/jira/browse/IGNITE-1436

It would be great if I could be added to the list of contributors so I can 
assign the tickets to myself.

Thanks,
Stephen

[jira] [Created] (IGNITE-10156) Invalid convertation DynamicCacheDescriptor to StoredCacheData

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-10156:
--

 Summary: Invalid convertation DynamicCacheDescriptor to 
StoredCacheData
 Key: IGNITE-10156
 URL: https://issues.apache.org/jira/browse/IGNITE-10156
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Invalid convertation DynamicCacheDescriptor to StoredCacheData in 
CacheRegistry#persistCacheConfigurations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #5330: Ignite 9870

[voropava]

GitHub user voropava opened a pull request:

https://github.com/apache/ignite/pull/5330

Ignite 9870



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9870

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5330.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5330


commit a988cd095c2e41a05701305a07b9140145d0bbe4
Author: Pavel Voronkin 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Implemented parallel GridDhtPartitionsFullMessage zip and unzip 
using getNetCompressionLevel() BEST_SPEED by default.

commit cd0e4555cdca4865e0fd9b06a23afd756510518e
Author: Pavel Voronkin 
Date:   2018-08-14T18:20:50Z

IGNITE-9870 Fixed javadoc.




---

[jira] [Created] (IGNITE-10155) Yardstick should allow modifier when starting servers

[Stephen Darlington (JIRA)]

Stephen Darlington created IGNITE-10155:
---

 Summary: Yardstick should allow modifier when starting servers
 Key: IGNITE-10155
 URL: https://issues.apache.org/jira/browse/IGNITE-10155
 Project: Ignite
  Issue Type: Improvement
  Components: yardstick
Reporter: Stephen Darlington


Currently, Yardstick will start as many copies of Ignite as specified in the 
configuration file. However there is currently no way to customise the 
behaviour of each of those nodes. The example I'm currently working with is 
forcing CPU affinity.

Related: it's also error prone to specify multiple nodes (when the number is 
large). It would be nice to have some kind of shorthand to say you want, say, 
four nodes on this particular host.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10154) Critical worker liveness check configuration is non-trivial and inconsistent

[Artem Budnikov (JIRA)]

Artem Budnikov created IGNITE-10154:
---

 Summary: Critical worker liveness check configuration is 
non-trivial and inconsistent
 Key: IGNITE-10154
 URL: https://issues.apache.org/jira/browse/IGNITE-10154
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.7
Reporter: Artem Budnikov
 Fix For: 2.7


The way the critical thread liveness check is configured has a number of 
usability issues.

1) By default, the liveness check is disabled (i.e. if no failure handler is 
specified in the configuration). However, if you specify any handler (including 
the default one), liveness check gets enabled (which is something the users may 
not want) unless you disable it explicitly.

2) Users that use Ignite 2.6 with a configured failure handler will get this 
check enabled after migrating to Ignite 2.7.

In the two cases above, the functionality changes in a non-trivial. Ideally, we 
need an option that enables this functionality explicitly. A possible example 
would be to keep liveness check disabled until the user sets the 
systemWorkerBlockedTimeout to a positive value. (Or the other way around: 
enable liveness check by default until the user explicitly disables it).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #5329: IGNITE-10108: Refactored a test to avoid passing ...

[shroman]

GitHub user shroman opened a pull request:

https://github.com/apache/ignite/pull/5329

IGNITE-10108: Refactored a test to avoid passing anonymous classes on…

… compute.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shroman/ignite IGNITE-10108

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/5329.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5329


commit c5218201b65cf1807041f1d2aaeb561cc24b96e5
Author: shroman 
Date:   2018-11-07T10:18:11Z

IGNITE-10108: Refactored a test to avoid passing anonymous classes on 
compute.




---

SQL management and monitoring improvements

[Юрий]

Hi Igniters!

I think we can improve Ignite management and monitoring instruments related
to SQL.
I've prepared draft of IEP-29: SQL management and monitoring

.

What do you think about it? May be do you have some additional suggestions?


-- 
Живи с улыбкой! :D

[jira] [Created] (IGNITE-10153) [TC Bot] Implement tests running time report

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-10153:


 Summary: [TC Bot] Implement tests running time report
 Key: IGNITE-10153
 URL: https://issues.apache.org/jira/browse/IGNITE-10153
 Project: Ignite
  Issue Type: Task
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov


In order to optimize running time of existing test base (at the moment all 
tests require ~ 50 hours of running time on available agents) we need a report 
page with info about each suite.

At the first stage page will show tests running longer than 1 minute for each 
suite in the latest run in master branch.

Later other features may be added like analyzing PRs or other branches, 
adjusting running time limit (e.g. all tests longer than 30 seconds and so on).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSSION] Spark Data Frame through Thin Client

[Ray]

>From my past experience with Spark Data Frame API, the thick client approach
leads to many usability problems.

Ex.
http://apache-ignite-users.70518.x6.nabble.com/Local-node-SEGMENTED-error-causing-node-goes-down-for-no-obvious-reason-td25061.html

I think it makes a lot of sense to change to thin client.



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[GitHub] SomeFire commented on a change in pull request #60: IGNITE-10146 Refresh missing from Git prs while full reindex

[GitBox]

SomeFire commented on a change in pull request #60: IGNITE-10146 Refresh 
missing from Git prs while full reindex
URL: https://github.com/apache/ignite-teamcity-bot/pull/60#discussion_r231416964
 
 

 ##
 File path: 
ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/github/ignited/GitHubConnIgnitedImpl.java
 ##
 @@ -134,13 +137,30 @@ protected String runActualizePrs(String srvId, boolean 
fullReindex) {
 cntSaved += savedThisChunk;
 totalChecked += ghData.size();
 
+if (fullReindex)
+actualPrs.addAll(ghData.stream()
+.map(pr -> pr.getNumber())
+.collect(Collectors.toSet()));
+
 
 Review comment:
   ```suggestion
   }
   
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] SomeFire commented on a change in pull request #60: IGNITE-10146 Refresh missing from Git prs while full reindex

[GitBox]

SomeFire commented on a change in pull request #60: IGNITE-10146 Refresh 
missing from Git prs while full reindex
URL: https://github.com/apache/ignite-teamcity-bot/pull/60#discussion_r231416889
 
 

 ##
 File path: 
ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/github/ignited/GitHubConnIgnitedImpl.java
 ##
 @@ -134,13 +137,30 @@ protected String runActualizePrs(String srvId, boolean 
fullReindex) {
 cntSaved += savedThisChunk;
 totalChecked += ghData.size();
 
+if (fullReindex)
 
 Review comment:
   ```suggestion
   if (fullReindex) {
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services