Re: Lack of accounting for extremely disruptive functionality

[Denis Magda]

Hi Roman!

In fact, that particular issue you’re referring to was handled directly in JIRA 
[1] in order to address the reported CVE [2]. Now I see, that as one of the 
ticket reviewers, I should have initiated a broader discussion on @dev to avoid 
the point we came to today with the update notifier. 

Speaking about the notifier in general, that’s not a new piece of code. It was 
originally donated to Ignite at the time of incubation and we planned to make 
use of it for the whole community (for instance, knowing such metrics as JDK 
version we can not only see what’s the most popular Java version Ignite runs on 
but to decide if there is a reason to support Java 7).

However, due to a lack of resources and shifting priorities and interests 
inside of the community we haven’t completed the upgrade process of the 
notifier and none of the data gathered by it is used for any purpose. So, now, 
the reasonable decision would be to disable the notifier completely and 
initiate a separate discussion on @dev going over its scope, functionality and 
future. 

Thoughts?

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

[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805 


> On Jun 5, 2017, at 6:27 PM, Roman Shaposhnik  wrote:
> 
> Hi!
> 
> there's a thread about an extremely questionable practice
> that Apache Ignite engages in. A practice that borderlines
> on unsolicited data collection (and as such may even be
> illegal in some jurisdictions without an explicit opt-in):
>
> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_V1REQ9hUERCFog%40mail.gmail.com%3E
> 
> This thread, however, is not focused on the legality (IANAL) of
> the practice nor it is focused on security implications of it. I'd live
> to talk about an absolute lack of any accounting for an extremely
> disruptive functionality like this one.
> 
> Because you see, when I asked myself a question "how the heck
> could something like this possible end up in a project with
> virtually 0 discussion that I remember?" My next thought was -- well
> let me use Git and JIRA to get to the bottom of this. Quite to
> my surprise every single commit that touches the URL in question
> has virtually 0 accounting for why it is there. No JIRA IDs, not extended
> comments -- nothing.
> 
> My understanding is that you guys pride yourself on being RTC project.
> Can someone please explain to me how all of these got reviewed:
> https://github.com/apache/ignite/commit/952be8b995050b34379006dd6e739da3fe3b49e3
> https://github.com/apache/ignite/commit/33ec73f901ca5dba441c6ca4e118d55165f3d25e
> https://github.com/apache/ignite/commit/551b3d1eab2a0b78d3f259f1bf24f1f6f3ff7b06
> https://github.com/apache/ignite/commit/c4030f926a7339cfcae14e19cec22d9d37cd94dd
> https://github.com/apache/ignite/commit/73c5e43c6c161aa18aa9e8ff2b09e582c7aedce4
> 
> Thanks,
> Roman.

[jira] [Created] (IGNITE-5414) Web Console: Model import should use unique indexes if no PK found

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-5414:


 Summary: Web Console: Model import should use unique indexes if no 
PK found
 Key: IGNITE-5414
 URL: https://issues.apache.org/jira/browse/IGNITE-5414
 Project: Ignite
  Issue Type: Task
  Components: wizards
Affects Versions: 1.7
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.1


When import model from RDBMS some tables without primary key could have unique 
index that could be used for key fields generation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Fwd: Persistent Distributed Store Metrics

[Konstantin Boudnik]

On Mon, Jun 05, 2017 at 07:41PM, Dmitriy Setrakyan wrote:
> On Mon, Jun 5, 2017 at 6:46 PM, Konstantin Boudnik  wrote:
> 
> > Wow, hold on - as far as I remember there was a VOTE to accept the
> > contribution of the code into the project _on a branch_. We haven't vetted
> > its
> > inclusion into the next release, We are still at the phase of getting
> > familiar
> > with the code.
> >
> 
> Cos, the community has been vetting the inclusion of the new code for over
> 3 weeks already (the process and dates are documented here [2]). To be
> honest, I am not sure what the appropriate time frame should be, but I
> would think that a month would be a good check-in point.

I would think it should be as long as we, as the community, are comfortable
with the massive change coming into the release. We already been through the
discussion on the timing, etc. and I don't want to harp on that.

> There is also an active stabilization thread for the persistence branch
> [3]. I encouraged the community to get involved and post any questions or
> concerns there as well.
> 
> There is an upcoming in-memory computing conference that is coming up in
> June in Amsterdam [4], where there are many Ignite talks scheduled. It
> would be great to be able to talk about the persistence features of Ignite
> there as well. I would like to ask the community to mobilize with reviewing
> the donated code, so we could have something concrete to tell the audience
> on the conference.

I am sure that having the code on the branch is good enough to be able to talk
about this. Having this in the release isn't really a contingency to be able
to make a presentation, right?

Cos

> [2]
> http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html
> [3]
> http://apache-ignite-developers.2346864.n4.nabble.com/Persistent-Store-Stabilization-for-release-td18288.html
> [4] https://imcsummit.org/
> 
> 
> 
> > And from what I am seeing in the discussions like this [1], we need to be
> > extra careful.
> >
> 
> I would keep the discussion in [1] separate from the persistence store.
> These are 2 unrelated issues. I will respond on [1] either today or
> tomorrow, but I agree in general that it should be fixed ASAP.
> 
> 
> > BTW, you have sent this email 9 days before the vote had happened! A bit
> > too
> > soon, if you ask me.
> >
> 
> Cos, this email was sent 1 week after the initial donated code branch was
> presented to the community (see [2] above). The developers involved were
> eager to make it available to the users as soon as possible, but no code
> has been merged to the master branch yet.
> 
> I would like to encourage everyone in the community to participate in the
> persistence branch coding discussions, like the one in this thread, and
> familiarize themselves with the code.
> 
> 
> >
> > [1] https://is.gd/UQCr51
> >
> > Cos
> >
> > On Wed, May 17, 2017 at 11:16AM, Dmitriy Govorukhin wrote:
> > > Folk,
> > >
> > > As you know, ignite 2.1 will contain new module (pds), it will be
> > > provide ability to store data on disk. Let's discuss what type of
> > > metrics we need for this?
> > > I think it must be metrics per memory policy, per cache, checkpoint,
> > > and global metrics which will be aggregate all metrics.
> > >
> > > I did sketch.
> > >
> > > PersistentStoreMetrics.java
> > >
> > > public interface PersistentStoreMetrics {
> > >
> > > // Global metrics.
> > >
> > > public long getMemorySize();
> > >
> > > public long getDiskSize();
> > >
> > > public long getPagesInMemory();
> > >
> > > public long getPagesSizeInMemory();
> > >
> > > public long getPagesOnDisk();
> > >
> > > public long getPagesSizeOnDisk();
> > >
> > > public long getFreePages();
> > >
> > > public long getFreePagesSize();
> > >
> > > public long getDirtyPages();
> > >
> > > public long getDirtyPagesSize();
> > >
> > > public long walLog();
> > >
> > > public long walLogSize();
> > >
> > > // Frequency.
> > >
> > > public long getPagesRead();
> > >
> > > public long getPagesWrite();
> > >
> > > public long getFsync();
> > >
> > > public long getWal();
> > >
> > > public long getAverageWalFsyncTime();
> > >
> > > // Per cache.
> > >
> > > public PersistentStoreCacheMetrics cache(String name);
> > >
> > > public PersistentStoreCacheMetrics cache(int cacheId);
> > >
> > > // For last checkpoint.
> > >
> > > public PersistentStoreCheckpointMetrics getLastCheckPoint();
> > > }
> > >
> > > >>>
> > >
> > > PersistentStoreCacheMetrics.java
> > >
> > > public interface PersistentStoreCacheMetrics {
> > >
> > > public String name();
> > >
> > > public double getFillFactor();
> > >
> > > public double getFillFactor(int part);
> > >
> > > public long getMemorySize();
> > >
> > > public long getDiskSize();
> > >
> > > public long getPagesInMemory();
> > >
> > > public long 

Fwd: Persistent Distributed Store Metrics

[Dmitriy Setrakyan]

On Mon, Jun 5, 2017 at 6:46 PM, Konstantin Boudnik  wrote:

> Wow, hold on - as far as I remember there was a VOTE to accept the
> contribution of the code into the project _on a branch_. We haven't vetted
> its
> inclusion into the next release, We are still at the phase of getting
> familiar
> with the code.
>

Cos, the community has been vetting the inclusion of the new code for over
3 weeks already (the process and dates are documented here [2]). To be
honest, I am not sure what the appropriate time frame should be, but I
would think that a month would be a good check-in point.

There is also an active stabilization thread for the persistence branch
[3]. I encouraged the community to get involved and post any questions or
concerns there as well.

There is an upcoming in-memory computing conference that is coming up in
June in Amsterdam [4], where there are many Ignite talks scheduled. It
would be great to be able to talk about the persistence features of Ignite
there as well. I would like to ask the community to mobilize with reviewing
the donated code, so we could have something concrete to tell the audience
on the conference.

[2]
http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html
[3]
http://apache-ignite-developers.2346864.n4.nabble.com/Persistent-Store-Stabilization-for-release-td18288.html
[4] https://imcsummit.org/



> And from what I am seeing in the discussions like this [1], we need to be
> extra careful.
>

I would keep the discussion in [1] separate from the persistence store.
These are 2 unrelated issues. I will respond on [1] either today or
tomorrow, but I agree in general that it should be fixed ASAP.


> BTW, you have sent this email 9 days before the vote had happened! A bit
> too
> soon, if you ask me.
>

Cos, this email was sent 1 week after the initial donated code branch was
presented to the community (see [2] above). The developers involved were
eager to make it available to the users as soon as possible, but no code
has been merged to the master branch yet.

I would like to encourage everyone in the community to participate in the
persistence branch coding discussions, like the one in this thread, and
familiarize themselves with the code.


>
> [1] https://is.gd/UQCr51
>
> Cos
>
> On Wed, May 17, 2017 at 11:16AM, Dmitriy Govorukhin wrote:
> > Folk,
> >
> > As you know, ignite 2.1 will contain new module (pds), it will be
> > provide ability to store data on disk. Let's discuss what type of
> > metrics we need for this?
> > I think it must be metrics per memory policy, per cache, checkpoint,
> > and global metrics which will be aggregate all metrics.
> >
> > I did sketch.
> >
> > PersistentStoreMetrics.java
> >
> > public interface PersistentStoreMetrics {
> >
> > // Global metrics.
> >
> > public long getMemorySize();
> >
> > public long getDiskSize();
> >
> > public long getPagesInMemory();
> >
> > public long getPagesSizeInMemory();
> >
> > public long getPagesOnDisk();
> >
> > public long getPagesSizeOnDisk();
> >
> > public long getFreePages();
> >
> > public long getFreePagesSize();
> >
> > public long getDirtyPages();
> >
> > public long getDirtyPagesSize();
> >
> > public long walLog();
> >
> > public long walLogSize();
> >
> > // Frequency.
> >
> > public long getPagesRead();
> >
> > public long getPagesWrite();
> >
> > public long getFsync();
> >
> > public long getWal();
> >
> > public long getAverageWalFsyncTime();
> >
> > // Per cache.
> >
> > public PersistentStoreCacheMetrics cache(String name);
> >
> > public PersistentStoreCacheMetrics cache(int cacheId);
> >
> > // For last checkpoint.
> >
> > public PersistentStoreCheckpointMetrics getLastCheckPoint();
> > }
> >
> > >>>
> >
> > PersistentStoreCacheMetrics.java
> >
> > public interface PersistentStoreCacheMetrics {
> >
> > public String name();
> >
> > public double getFillFactor();
> >
> > public double getFillFactor(int part);
> >
> > public long getMemorySize();
> >
> > public long getDiskSize();
> >
> > public long getPagesInMemory();
> >
> > public long getPagesSizeInMemory();
> >
> > public long getPagesOnDisk();
> >
> > public long getPagesSizeOnDisk();
> >
> > public long getFreePages();
> >
> > public long getFreePagesSize();
> >
> > public long getDirtyPages();
> >
> > public long getDirtyPagesSize();
> >
> > public long getPagesRead();
> >
> > public long getPagesWritten();
> > }
> >
> > >>>
> >
> > PersistentStoreCheckpointMetrics.java
> >
> > public interface PersistentStoreCheckpointMetrics {
> >
> > public long getTotalPages();
> >
> > //TODO Page type is internal?
> > public long[] pagesType();
> >
> > public long getExecutingTime();
> >
> > public long getFsyncTime();
> >
> > public long getPagesCopyOnWrite();
> > }
>

Re: Persistent Distributed Store Metrics

[Konstantin Boudnik]

Wow, hold on - as far as I remember there was a VOTE to accept the
contribution of the code into the project _on a branch_. We haven't vetted its
inclusion into the next release, We are still at the phase of getting familiar
with the code. 

And from what I am seeing in the discussions like this [1], we need to be
extra careful.

BTW, you have sent this email 9 days before the vote had happened! A bit too
soon, if you ask me.

[1] https://is.gd/UQCr51

Cos

On Wed, May 17, 2017 at 11:16AM, Dmitriy Govorukhin wrote:
> Folk,
> 
> As you know, ignite 2.1 will contain new module (pds), it will be
> provide ability to store data on disk. Let's discuss what type of
> metrics we need for this?
> I think it must be metrics per memory policy, per cache, checkpoint,
> and global metrics which will be aggregate all metrics.
> 
> I did sketch.
> 
> PersistentStoreMetrics.java
> 
> public interface PersistentStoreMetrics {
> 
> // Global metrics.
> 
> public long getMemorySize();
> 
> public long getDiskSize();
> 
> public long getPagesInMemory();
> 
> public long getPagesSizeInMemory();
> 
> public long getPagesOnDisk();
> 
> public long getPagesSizeOnDisk();
> 
> public long getFreePages();
> 
> public long getFreePagesSize();
> 
> public long getDirtyPages();
> 
> public long getDirtyPagesSize();
> 
> public long walLog();
> 
> public long walLogSize();
> 
> // Frequency.
> 
> public long getPagesRead();
> 
> public long getPagesWrite();
> 
> public long getFsync();
> 
> public long getWal();
> 
> public long getAverageWalFsyncTime();
> 
> // Per cache.
> 
> public PersistentStoreCacheMetrics cache(String name);
> 
> public PersistentStoreCacheMetrics cache(int cacheId);
> 
> // For last checkpoint.
> 
> public PersistentStoreCheckpointMetrics getLastCheckPoint();
> }
> 
> >>>
> 
> PersistentStoreCacheMetrics.java
> 
> public interface PersistentStoreCacheMetrics {
> 
> public String name();
> 
> public double getFillFactor();
> 
> public double getFillFactor(int part);
> 
> public long getMemorySize();
> 
> public long getDiskSize();
> 
> public long getPagesInMemory();
> 
> public long getPagesSizeInMemory();
> 
> public long getPagesOnDisk();
> 
> public long getPagesSizeOnDisk();
> 
> public long getFreePages();
> 
> public long getFreePagesSize();
> 
> public long getDirtyPages();
> 
> public long getDirtyPagesSize();
> 
> public long getPagesRead();
> 
> public long getPagesWritten();
> }
> 
> >>>
> 
> PersistentStoreCheckpointMetrics.java
> 
> public interface PersistentStoreCheckpointMetrics {
> 
> public long getTotalPages();
> 
> //TODO Page type is internal?
> public long[] pagesType();
> 
> public long getExecutingTime();
> 
> public long getFsyncTime();
> 
> public long getPagesCopyOnWrite();
> }

Lack of accounting for extremely disruptive functionality

[Roman Shaposhnik]

Hi!

there's a thread about an extremely questionable practice
that Apache Ignite engages in. A practice that borderlines
on unsolicited data collection (and as such may even be
illegal in some jurisdictions without an explicit opt-in):

https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_V1REQ9hUERCFog%40mail.gmail.com%3E

This thread, however, is not focused on the legality (IANAL) of
the practice nor it is focused on security implications of it. I'd live
to talk about an absolute lack of any accounting for an extremely
disruptive functionality like this one.

Because you see, when I asked myself a question "how the heck
could something like this possible end up in a project with
virtually 0 discussion that I remember?" My next thought was -- well
let me use Git and JIRA to get to the bottom of this. Quite to
my surprise every single commit that touches the URL in question
has virtually 0 accounting for why it is there. No JIRA IDs, not extended
comments -- nothing.

My understanding is that you guys pride yourself on being RTC project.
Can someone please explain to me how all of these got reviewed:
 
https://github.com/apache/ignite/commit/952be8b995050b34379006dd6e739da3fe3b49e3
 
https://github.com/apache/ignite/commit/33ec73f901ca5dba441c6ca4e118d55165f3d25e
 
https://github.com/apache/ignite/commit/551b3d1eab2a0b78d3f259f1bf24f1f6f3ff7b06
 
https://github.com/apache/ignite/commit/c4030f926a7339cfcae14e19cec22d9d37cd94dd
 
https://github.com/apache/ignite/commit/73c5e43c6c161aa18aa9e8ff2b09e582c7aedce4

Thanks,
Roman.

[jira] [Created] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint

[Konstantin Boudnik (JIRA)]

Konstantin Boudnik created IGNITE-5413:
--

 Summary: Ignite shouldn't expose nor send (clear-text) env 
variables to a 3rd endpoint
 Key: IGNITE-5413
 URL: https://issues.apache.org/jira/browse/IGNITE-5413
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.1.4
Reporter: Konstantin Boudnik
Priority: Blocker
 Fix For: 2.1


Apache Ignite is periodically accessing to 
https://ignite.run/update_status_ignite-plain-text.php

It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but 
of course it has been happening for a long time.

Corresponding code is 
https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82

Posting JVM env variable (or any other user's specific information) without an 
explicit user's consent is a bad idea and should be disabled by default. 
See  
https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313
for more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: "Review workflow" changes to prevent "broken review" issues.

[Dmitriy Setrakyan]

Wow, we have 66 tickets waiting for review this is pretty bad.
Something must definitely change.

>From my side, having a contributor shop around for a reviewer is not really
fair. However, I would support the idea of Apache Ignite community electing
a person responsible to find reviewers for all contributions.

D.

On Mon, Jun 5, 2017 at 11:23 AM, Dmitry Pavlov 
wrote:

> 1) There is waiting for review list here
> https://cwiki.apache.org/confluence/display/IGNITE/
> Issues+waiting+for+review
>
> 2) some of contributions are supplemented by dev-list messages (please
> review my PR…)
>
>
> And these two tools sometimes do not help. I suppose it is because of
> reviewers already have some things to do, but not because of lack of tool
> support. Do you have other explanations?
>
>
> But still, Igor’s suggestion to notify to dev list sounds reasonable to me.
>
>
>
> Anton, could it solve your requirement to know about issue needed to
> review?
>
> пн, 5 июн. 2017 г. в 21:06, Igor Sapego :
>
> > By the way, there are emails being sent from Jira to devlist every
> > time someone adds comment to ticket, or, for example, edits its
> > title which helps a lot to keep a track of ticket's state.
> >
> > But by some reason there is no such notification when ticket silently
> > getting moved to "Patch available" state. I believe, that would help if
> > there was a notification for that. Is it possible to configure?
> >
> > Best Regards,
> > Igor
> >
> > On Mon, Jun 5, 2017 at 9:00 PM, Denis Magda  wrote:
> >
> > > In general, I tend to agree with Anton that something needs to be
> changed
> > > in this direction.
> > >
> > > How many of you flip through dev list, JIRA or GitHub notifications in
> an
> > > attempt to find tickets that demand your attention? I bet the
> percentage
> > is
> > > pretty low.
> > >
> > > To solve this issue I see two options:
> > > 1) Proposed by Anton.
> > > 2) Having a guy in the community who’ll keep an eye on all the incoming
> > > pull-requests shuffling them between committer in the same way proposed
> > in
> > > 1.
> > >
> > > Personally, I’m for 1.
> > >
> > > —
> > > Denis
> > >
> > > > On Jun 5, 2017, at 10:28 AM, Dmitry Pavlov 
> > > wrote:
> > > >
> > > > Hi Anton,
> > > >
> > > >
> > > > It is ok for me if it is advice and hint for faster review, as it is
> > now.
> > > >
> > > >
> > > > We can periodically remind about this opportunity at dev list or in
> the
> > > > issue comments. We can remind that tasks in patch available status
> may
> > be
> > > > reassigned by contributor.
> > > >
> > > >
> > > > Looking from prospective of overall throughput: it is not clear for
> me
> > > how
> > > > this process change will help.
> > > >
> > > >
> > > > Best Regards,
> > > >
> > > > Dmitriy Pavlov
> > > >
> > > > пн, 5 июн. 2017 г. в 20:16, Anton Vinogradov :
> > > >
> > > >> Vova,
> > > >>
> > > >> Contributors interested to make contributions and I propose them to
> > use
> > > >> *same* strategy as we (people inside the community) use.
> > > >> "-1" will not solve this issue, but my "tips" will.
> > > >>
> > > >> Dmitry,
> > > >>
> > > >> The main problem here is that nobody notified that someone is
> waiting
> > > for
> > > >> the review.
> > > >> It's not a problem for me to provide tips or to make review, but
> it's
> > > >> problem to periodically check is there somebody waiting.
> > > >>
> > > >> Guys,
> > > >> Let's try this approach, and I'm pretty sure it will help.
> > > >>
> > > >> On Mon, Jun 5, 2017 at 7:58 PM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Hi Igniters, Anton,
> > > >>>
> > > >>> Let’s imagine that development process as a chain of production
> > stages
> > > >>> 1) Developing patch by contributor
> > > >>> 2) Review changes by committer
> > > >>>
> > > >>> Reviews waiting too long time to be done at stage 2 may indicate
> that
> > > >> speed
> > > >>> (potential throughput) of step 2 is less than throughput at step 1.
> > > T2 > > >>>
> > > >>> In terms of this model (inspired by Goldratt’s Theory of
> Constraints
> > > >>> (TOC)), I have a question:
> > > >>> Will this responsibility movement (to find appropriate reviewer to
> > > >>> contributor) help us to increase overall throughput?
> > > >>>
> > > >>> If we agree constraint in terms of TOC is throughput T2, I suggest
> > > >>> following steps
> > > >>> - Increase the throughput T2 of the committers
> > > >>> - Reduce the load on the committers by improve quality of code
> after
> > > >> stage
> > > >>> 1 given to review (pre review by non-committer, automatic review,
> > code
> > > >>> inspections)
> > > >>>
> > > >>> Best Regards,
> > > >>> Dmitriy Pavlov
> > > >>>
> > > >>>
> > > >>> пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov :
> > > >>>
> > >  Igniters,
> > > 
> > >  Currently, according to
> > > 
> > >  

CI Server permissions changed

[Aleksey Chetaev]

Hi,
That all users don't be admins, I changed permissions scheme on CI server
(http://ci.ignite.apache.org)
We have four groups:
 > TeamCity Admins - group for committers. Users in this group have full
access permission to CI server and can add new users.
 > Ignite Tests Admins - groups for guys, who was in admins group but don't
in committers list. This group have admin access to all projects with tests,
can create, edit and start builds with test.
 > Ignite Release Managers - group which have access to release project.
 > All Users - groups which content all CI server users. Users in this group
can start and stop builds in projects with Ignite tests. (Users add to this
group automaticly on created).

Best Regards,
Aleksey Chetaev.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/CI-Server-permissions-changed-tp18500.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[GitHub] ignite pull request #2090: ignite-2190 fix issue

[nizhikov]

GitHub user nizhikov opened a pull request:

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

ignite-2190 fix issue

Added GridCacheEmptyScanQueryTest to reproduce bug described in task
Minor fixes in IgniteProcessProxy and GridAbstractTest for a possibility to 
modify separate jvm grid classpath
Added ignite-2190-1.0.jar to binary dependencies(source can be obtained 
from https://github.com/nizhikov/ignite-2190-binary)

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

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

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

https://github.com/apache/ignite/pull/2090.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 #2090


commit 3314e31dae58a5ed7459fcde7b185a9c6375c2a0
Author: Ижиков Николай Владимирович 

Date:   2017-06-05T20:14:14Z

ignite-2190 fix issue
Added GridCacheEmptyScanQueryTest to reproduce bug described in task
Minor fixes in IgniteProcessProxy and GridAbstractTest for a possibility to 
modify separate jvm grid classpath
Added ignite-2190-1.0.jar to binary dependencies(source can be obtained 
from https://github.com/nizhikov/ignite-2190-binary)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2088: Ignite 5355 Create release report task on TeamCit...

[achetaev]

Github user achetaev closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2088: Ignite 5355 Create release report task on TeamCit...

[achetaev]

GitHub user achetaev opened a pull request:

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

Ignite 5355 Create release report task on TeamCity



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

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

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

https://github.com/apache/ignite/pull/2088.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 #2088


commit a6ad620cece5be02da4f8394a501f7c7fd76f165
Author: Aleksey Chetaev 
Date:   2017-06-01T15:00:21Z

IGNITE-5355: Added new class to ignite-tools for generate release report

commit 1aeee2062d48324712bc51c1b6cde9969d58cacc
Author: Aleksey Chetaev 
Date:   2017-06-01T15:17:10Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-5355

commit 42876c924e7ccbd84b3883acae21d069aa971b34
Author: Aleksey Chetaev 
Date:   2017-06-01T17:23:43Z

IGNITE-5355 Add needed dependencies to tools/pom.xml

commit dcb5cca3b923ad2c5fffcf85b24fe062b109d74c
Author: Aleksey Chetaev 
Date:   2017-06-02T13:13:20Z

IGNITE-5355 Implemet reports templates for customise reports withou code 
change

commit 92d48295a2fe27cd348e5fce761f459cdc485064
Author: Aleksey Chetaev 
Date:   2017-06-05T18:04:48Z

IGNITE-5355 Implement description for release readed from template

commit c375699503772dee64509824d0c9b7826a351277
Author: Aleksey Chetaev 
Date:   2017-06-05T19:25:38Z

Add reading report css from file




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2086: Ignite 5355

[achetaev]

Github user achetaev closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2087: IGNITE-5408

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5412) JDBC thin: review ResultSetMetadata implementation

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5412:
---

 Summary: JDBC thin: review ResultSetMetadata implementation
 Key: IGNITE-5412
 URL: https://issues.apache.org/jira/browse/IGNITE-5412
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


1) Is it correct?
2) Why do we have muted tests for it?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2087: IGNITE-5408

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5408



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

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

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

https://github.com/apache/ignite/pull/2087.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 #2087


commit ecacd40e3b66270e821d3ba22a08d38c03db9333
Author: devozerov 
Date:   2017-06-05T18:56:42Z

Done for new driver.

commit 394e94992b0f913250c9723b86c9a98c13ae4aab
Author: devozerov 
Date:   2017-06-05T18:59:12Z

Done for old driver.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2082: IGNITE-5380

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: "Review workflow" changes to prevent "broken review" issues.

[Dmitry Pavlov]

1) There is waiting for review list here
https://cwiki.apache.org/confluence/display/IGNITE/Issues+waiting+for+review

2) some of contributions are supplemented by dev-list messages (please
review my PR…)


And these two tools sometimes do not help. I suppose it is because of
reviewers already have some things to do, but not because of lack of tool
support. Do you have other explanations?


But still, Igor’s suggestion to notify to dev list sounds reasonable to me.



Anton, could it solve your requirement to know about issue needed to review?

пн, 5 июн. 2017 г. в 21:06, Igor Sapego :

> By the way, there are emails being sent from Jira to devlist every
> time someone adds comment to ticket, or, for example, edits its
> title which helps a lot to keep a track of ticket's state.
>
> But by some reason there is no such notification when ticket silently
> getting moved to "Patch available" state. I believe, that would help if
> there was a notification for that. Is it possible to configure?
>
> Best Regards,
> Igor
>
> On Mon, Jun 5, 2017 at 9:00 PM, Denis Magda  wrote:
>
> > In general, I tend to agree with Anton that something needs to be changed
> > in this direction.
> >
> > How many of you flip through dev list, JIRA or GitHub notifications in an
> > attempt to find tickets that demand your attention? I bet the percentage
> is
> > pretty low.
> >
> > To solve this issue I see two options:
> > 1) Proposed by Anton.
> > 2) Having a guy in the community who’ll keep an eye on all the incoming
> > pull-requests shuffling them between committer in the same way proposed
> in
> > 1.
> >
> > Personally, I’m for 1.
> >
> > —
> > Denis
> >
> > > On Jun 5, 2017, at 10:28 AM, Dmitry Pavlov 
> > wrote:
> > >
> > > Hi Anton,
> > >
> > >
> > > It is ok for me if it is advice and hint for faster review, as it is
> now.
> > >
> > >
> > > We can periodically remind about this opportunity at dev list or in the
> > > issue comments. We can remind that tasks in patch available status may
> be
> > > reassigned by contributor.
> > >
> > >
> > > Looking from prospective of overall throughput: it is not clear for me
> > how
> > > this process change will help.
> > >
> > >
> > > Best Regards,
> > >
> > > Dmitriy Pavlov
> > >
> > > пн, 5 июн. 2017 г. в 20:16, Anton Vinogradov :
> > >
> > >> Vova,
> > >>
> > >> Contributors interested to make contributions and I propose them to
> use
> > >> *same* strategy as we (people inside the community) use.
> > >> "-1" will not solve this issue, but my "tips" will.
> > >>
> > >> Dmitry,
> > >>
> > >> The main problem here is that nobody notified that someone is waiting
> > for
> > >> the review.
> > >> It's not a problem for me to provide tips or to make review, but it's
> > >> problem to periodically check is there somebody waiting.
> > >>
> > >> Guys,
> > >> Let's try this approach, and I'm pretty sure it will help.
> > >>
> > >> On Mon, Jun 5, 2017 at 7:58 PM, Dmitry Pavlov 
> > >> wrote:
> > >>
> > >>> Hi Igniters, Anton,
> > >>>
> > >>> Let’s imagine that development process as a chain of production
> stages
> > >>> 1) Developing patch by contributor
> > >>> 2) Review changes by committer
> > >>>
> > >>> Reviews waiting too long time to be done at stage 2 may indicate that
> > >> speed
> > >>> (potential throughput) of step 2 is less than throughput at step 1.
> > T2 > >>>
> > >>> In terms of this model (inspired by Goldratt’s Theory of Constraints
> > >>> (TOC)), I have a question:
> > >>> Will this responsibility movement (to find appropriate reviewer to
> > >>> contributor) help us to increase overall throughput?
> > >>>
> > >>> If we agree constraint in terms of TOC is throughput T2, I suggest
> > >>> following steps
> > >>> - Increase the throughput T2 of the committers
> > >>> - Reduce the load on the committers by improve quality of code after
> > >> stage
> > >>> 1 given to review (pre review by non-committer, automatic review,
> code
> > >>> inspections)
> > >>>
> > >>> Best Regards,
> > >>> Dmitriy Pavlov
> > >>>
> > >>>
> > >>> пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov :
> > >>>
> >  Igniters,
> > 
> >  Currently, according to
> > 
> >  https://cwiki.apache.org/confluence/display/IGNITE/How+
> > >>> to+Contribute#HowtoContribute-SubmittingforReview
> >  ,
> >  contributor can ask for review by moving ticket to PATCH AVAILABLE
> > >> state.
> > 
> >  And, as far as I can see, this cause broken tickets issue.
> >  Contributor can wait somebody who'll review his changes for a month
> or
> > >>> even
> >  more.
> > 
> >  I propose to change workflow and *make contributor responsible to
> find
> >  reviewer*.
> >  It's pretty easy to find a person able to review changes in most of
> > >>> cases.
> > 
> >  1) You can check git history of files you modified and find persons
> > >> with
> >  

[GitHub] ignite pull request #2086: Ignite 5355

[achetaev]

GitHub user achetaev opened a pull request:

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

Ignite 5355



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

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

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

https://github.com/apache/ignite/pull/2086.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 #2086


commit a6ad620cece5be02da4f8394a501f7c7fd76f165
Author: Aleksey Chetaev 
Date:   2017-06-01T15:00:21Z

IGNITE-5355: Added new class to ignite-tools for generate release report

commit 1aeee2062d48324712bc51c1b6cde9969d58cacc
Author: Aleksey Chetaev 
Date:   2017-06-01T15:17:10Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-5355

commit 42876c924e7ccbd84b3883acae21d069aa971b34
Author: Aleksey Chetaev 
Date:   2017-06-01T17:23:43Z

IGNITE-5355 Add needed dependencies to tools/pom.xml

commit dcb5cca3b923ad2c5fffcf85b24fe062b109d74c
Author: Aleksey Chetaev 
Date:   2017-06-02T13:13:20Z

IGNITE-5355 Implemet reports templates for customise reports withou code 
change

commit 92d48295a2fe27cd348e5fce761f459cdc485064
Author: Aleksey Chetaev 
Date:   2017-06-05T18:04:48Z

IGNITE-5355 Implement description for release readed from template




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2085: IGNITE-5400 .NET: IgniteConfiguration.SqlConnecto...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5400 .NET: IgniteConfiguration.SqlConnectorConfiguration



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5400

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

https://github.com/apache/ignite/pull/2085.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 #2085


commit c7324b71d25864651ebe5d2336b43db4f5ad8313
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:04:02Z

IGNITE-5400 .NET: IgniteConfiguration.SqlConnectorConfiguration

commit 1dd8b62e623a3effdf80249c44e5407cf476d9bd
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:14:45Z

wip

commit 4b16665d3f23ee1da2338c9967da23f3f1edbea5
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:18:13Z

Config file done

commit 62c248318bfac660c20a0d284935ea54e67a3d9d
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:18:57Z

wip

commit 49134eb74bd872145511f3c3cd8b5f998c30f59e
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:34:49Z

wip thread pool sizes

commit 29a54876f7fe51e20e665ad085609f2bf56f4642
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:37:42Z

wip

commit 261f269d827899e8367054bdb0113bf9cb3033f8
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:40:59Z

wip

commit 9aaeca474e84a01d719ea5252522ba2a1ea58db5
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:44:36Z

wip

commit 405d0a6350791e7f5d8d686c82f6fdb73523709c
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:45:59Z

wip tests

commit 63399bae4ba22f8adc38ef69c7f8889fb62742d2
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:47:43Z

wip

commit 27ab9ddc3dec9ff6b6c1bda3ca30136e5b806e72
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:49:01Z

wip

commit 417fbb64b37ee237de726cfe1067f284aa866362
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:50:40Z

wip tests

commit 7da92ca16e6a5230681e1b24b1192f5d068db0ad
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:51:56Z

wip tests

commit e5566b71e39d8fd034bb34d73e46d7f934d9b00f
Author: Pavel Tupitsyn 
Date:   2017-06-05T16:23:28Z

wip

commit 55cd2d253b3a47b2d5447529d3f8b0632cc2a603
Author: Pavel Tupitsyn 
Date:   2017-06-05T16:24:31Z

java read-write done

commit 0a86fec0804c777a584f584457c756688f0c8400
Author: Pavel Tupitsyn 
Date:   2017-06-05T16:31:36Z

wip

commit 784e03299c413312aab5af5152025abb4656a83f
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:16:34Z

wip

commit 44c12b2be058be502daa17b945146593dbf7513d
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:19:22Z

wip tests

commit 7f57c359c03acc364bfc4c7e4a33ceca41bf384d
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:24:57Z

wip

commit 81d8d43624016b78222b87d44dc9fa8a47d53f15
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:31:37Z

wip

commit d3b9f3879468dfcd03622a05a15067227c87f579
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:42:22Z

Fix default value serialization

commit 5343c943f3f4e5c6a72852f762326d91bb6e8440
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:45:05Z

wip

commit 89187cde6b3314f4f1d33fcbcbe0b3e855ac3da4
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:56:49Z

wip schema

commit 2e97df5f306c9fdab5a0798cdba6796c5873dba4
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:59:48Z

wip schema

commit 63253f46a5a87bb5269fb6fdf0a4955b9f7eb424
Author: Pavel Tupitsyn 
Date:   2017-06-05T18:03:42Z

xsd done

commit a12e8970cbfdb52f2464893cd72d42c7f27d74ab
Author: Pavel Tupitsyn 
Date:   2017-06-05T18:08:08Z

All done




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: "Review workflow" changes to prevent "broken review" issues.

[Igor Sapego]

By the way, there are emails being sent from Jira to devlist every
time someone adds comment to ticket, or, for example, edits its
title which helps a lot to keep a track of ticket's state.

But by some reason there is no such notification when ticket silently
getting moved to "Patch available" state. I believe, that would help if
there was a notification for that. Is it possible to configure?

Best Regards,
Igor

On Mon, Jun 5, 2017 at 9:00 PM, Denis Magda  wrote:

> In general, I tend to agree with Anton that something needs to be changed
> in this direction.
>
> How many of you flip through dev list, JIRA or GitHub notifications in an
> attempt to find tickets that demand your attention? I bet the percentage is
> pretty low.
>
> To solve this issue I see two options:
> 1) Proposed by Anton.
> 2) Having a guy in the community who’ll keep an eye on all the incoming
> pull-requests shuffling them between committer in the same way proposed in
> 1.
>
> Personally, I’m for 1.
>
> —
> Denis
>
> > On Jun 5, 2017, at 10:28 AM, Dmitry Pavlov 
> wrote:
> >
> > Hi Anton,
> >
> >
> > It is ok for me if it is advice and hint for faster review, as it is now.
> >
> >
> > We can periodically remind about this opportunity at dev list or in the
> > issue comments. We can remind that tasks in patch available status may be
> > reassigned by contributor.
> >
> >
> > Looking from prospective of overall throughput: it is not clear for me
> how
> > this process change will help.
> >
> >
> > Best Regards,
> >
> > Dmitriy Pavlov
> >
> > пн, 5 июн. 2017 г. в 20:16, Anton Vinogradov :
> >
> >> Vova,
> >>
> >> Contributors interested to make contributions and I propose them to use
> >> *same* strategy as we (people inside the community) use.
> >> "-1" will not solve this issue, but my "tips" will.
> >>
> >> Dmitry,
> >>
> >> The main problem here is that nobody notified that someone is waiting
> for
> >> the review.
> >> It's not a problem for me to provide tips or to make review, but it's
> >> problem to periodically check is there somebody waiting.
> >>
> >> Guys,
> >> Let's try this approach, and I'm pretty sure it will help.
> >>
> >> On Mon, Jun 5, 2017 at 7:58 PM, Dmitry Pavlov 
> >> wrote:
> >>
> >>> Hi Igniters, Anton,
> >>>
> >>> Let’s imagine that development process as a chain of production stages
> >>> 1) Developing patch by contributor
> >>> 2) Review changes by committer
> >>>
> >>> Reviews waiting too long time to be done at stage 2 may indicate that
> >> speed
> >>> (potential throughput) of step 2 is less than throughput at step 1.
> T2 >>>
> >>> In terms of this model (inspired by Goldratt’s Theory of Constraints
> >>> (TOC)), I have a question:
> >>> Will this responsibility movement (to find appropriate reviewer to
> >>> contributor) help us to increase overall throughput?
> >>>
> >>> If we agree constraint in terms of TOC is throughput T2, I suggest
> >>> following steps
> >>> - Increase the throughput T2 of the committers
> >>> - Reduce the load on the committers by improve quality of code after
> >> stage
> >>> 1 given to review (pre review by non-committer, automatic review, code
> >>> inspections)
> >>>
> >>> Best Regards,
> >>> Dmitriy Pavlov
> >>>
> >>>
> >>> пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov :
> >>>
>  Igniters,
> 
>  Currently, according to
> 
>  https://cwiki.apache.org/confluence/display/IGNITE/How+
> >>> to+Contribute#HowtoContribute-SubmittingforReview
>  ,
>  contributor can ask for review by moving ticket to PATCH AVAILABLE
> >> state.
> 
>  And, as far as I can see, this cause broken tickets issue.
>  Contributor can wait somebody who'll review his changes for a month or
> >>> even
>  more.
> 
>  I propose to change workflow and *make contributor responsible to find
>  reviewer*.
>  It's pretty easy to find a person able to review changes in most of
> >>> cases.
> 
>  1) You can check git history of files you modified and find persons
> >> with
>  expertise in this code
>  2) In case you have problems with such search you can always use
>  maintainers list (
> 
>  https://cwiki.apache.org/confluence/display/IGNITE/How+
> >>> to+Contribute#HowtoContribute-ReviewProcessandMaintainers
>  )
> 
>  Thoughts?
> 
> >>>
> >>
>
>

[GitHub] ignite pull request #2073: IGNITE-5355 Create task with release tools

[achetaev]

Github user achetaev closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: "Review workflow" changes to prevent "broken review" issues.

[Denis Magda]

In general, I tend to agree with Anton that something needs to be changed in 
this direction.

How many of you flip through dev list, JIRA or GitHub notifications in an 
attempt to find tickets that demand your attention? I bet the percentage is 
pretty low.

To solve this issue I see two options:
1) Proposed by Anton.
2) Having a guy in the community who’ll keep an eye on all the incoming 
pull-requests shuffling them between committer in the same way proposed in 1.

Personally, I’m for 1.

—
Denis

> On Jun 5, 2017, at 10:28 AM, Dmitry Pavlov  wrote:
> 
> Hi Anton,
> 
> 
> It is ok for me if it is advice and hint for faster review, as it is now.
> 
> 
> We can periodically remind about this opportunity at dev list or in the
> issue comments. We can remind that tasks in patch available status may be
> reassigned by contributor.
> 
> 
> Looking from prospective of overall throughput: it is not clear for me how
> this process change will help.
> 
> 
> Best Regards,
> 
> Dmitriy Pavlov
> 
> пн, 5 июн. 2017 г. в 20:16, Anton Vinogradov :
> 
>> Vova,
>> 
>> Contributors interested to make contributions and I propose them to use
>> *same* strategy as we (people inside the community) use.
>> "-1" will not solve this issue, but my "tips" will.
>> 
>> Dmitry,
>> 
>> The main problem here is that nobody notified that someone is waiting for
>> the review.
>> It's not a problem for me to provide tips or to make review, but it's
>> problem to periodically check is there somebody waiting.
>> 
>> Guys,
>> Let's try this approach, and I'm pretty sure it will help.
>> 
>> On Mon, Jun 5, 2017 at 7:58 PM, Dmitry Pavlov 
>> wrote:
>> 
>>> Hi Igniters, Anton,
>>> 
>>> Let’s imagine that development process as a chain of production stages
>>> 1) Developing patch by contributor
>>> 2) Review changes by committer
>>> 
>>> Reviews waiting too long time to be done at stage 2 may indicate that
>> speed
>>> (potential throughput) of step 2 is less than throughput at step 1. T2>> 
>>> In terms of this model (inspired by Goldratt’s Theory of Constraints
>>> (TOC)), I have a question:
>>> Will this responsibility movement (to find appropriate reviewer to
>>> contributor) help us to increase overall throughput?
>>> 
>>> If we agree constraint in terms of TOC is throughput T2, I suggest
>>> following steps
>>> - Increase the throughput T2 of the committers
>>> - Reduce the load on the committers by improve quality of code after
>> stage
>>> 1 given to review (pre review by non-committer, automatic review, code
>>> inspections)
>>> 
>>> Best Regards,
>>> Dmitriy Pavlov
>>> 
>>> 
>>> пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov :
>>> 
 Igniters,
 
 Currently, according to
 
 https://cwiki.apache.org/confluence/display/IGNITE/How+
>>> to+Contribute#HowtoContribute-SubmittingforReview
 ,
 contributor can ask for review by moving ticket to PATCH AVAILABLE
>> state.
 
 And, as far as I can see, this cause broken tickets issue.
 Contributor can wait somebody who'll review his changes for a month or
>>> even
 more.
 
 I propose to change workflow and *make contributor responsible to find
 reviewer*.
 It's pretty easy to find a person able to review changes in most of
>>> cases.
 
 1) You can check git history of files you modified and find persons
>> with
 expertise in this code
 2) In case you have problems with such search you can always use
 maintainers list (
 
 https://cwiki.apache.org/confluence/display/IGNITE/How+
>>> to+Contribute#HowtoContribute-ReviewProcessandMaintainers
 )
 
 Thoughts?
 
>>> 
>> 

Re: Request for contributor permissions

[Denis Magda]

Hello Alexey, what’s your JIRA id?

—
Denis

> On Jun 5, 2017, at 2:04 AM, Alexey Ivanov  wrote:
> 
> Hello everybody,
> 
> Please give me contributor permissions.
> 
> Alexey Ivanov
> 

[GitHub] ignite pull request #2084: Ignite 5410

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

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

Ignite 5410



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

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

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

https://github.com/apache/ignite/pull/2084.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 #2084


commit bfb00b6e61f9709718c30971997aeb0ac79e86b4
Author: Alexandr Kuramshin 
Date:   2016-11-18T20:12:28Z

IgniteTcpCommunicationBigClusterTest added

commit 02dd92e605b9b53f5a16c7ec5f8e7b5698b15ba4
Author: Alexandr Kuramshin 
Date:   2016-11-18T21:55:37Z

IgniteTcpCommunicationBigClusterTest update

commit 6acf193a3d356d1bad4c02a53ac76833ed1008d0
Author: Alexandr Kuramshin 
Date:   2016-11-19T09:55:45Z

Have got TcpCommunicationSpi error

commit 4fd39653d24f62f19f70b4dffba8497185cc46fb
Author: Alexandr Kuramshin 
Date:   2016-11-19T16:39:10Z

Some discovery have been done

commit c2c181922c7c24ea457577e32d2af897c8bec87f
Author: Alexandr Kuramshin 
Date:   2016-11-19T20:11:28Z

Prove that problem is not in the onFirstMessage hang

commit f8076edba097f6077229b2090ee3ff1a3369878c
Author: Alexandr Kuramshin 
Date:   2016-11-19T20:26:37Z

Revert: Prove that problem is not in the onFirstMessage hang

commit 6e1f2dfc2acb3dbb8f24aa51ed67b2ee447b4585
Author: Alexandr Kuramshin 
Date:   2016-11-21T08:55:09Z

Revert: pushing unnecessary changes to the master

commit ed794ca815f6bb1471af15779279d287576b39cc
Author: Alexandr Kuramshin 
Date:   2016-11-21T09:08:00Z

Revert: pushing unnecessary changes to the master

commit 3a57d63668bed239e21eca588134272783472e97
Author: iveselovskiy 
Date:   2016-12-09T14:13:37Z

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

commit 166ad21d560c41c42a6de81cf5910537baa3ac92
Author: iveselovskiy 
Date:   2016-12-12T18:46:44Z

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

commit 1eaba3e91bfe54c2bf6f761ac3f238a3b181a8e0
Author: iveselovskiy 
Date:   2017-03-27T18:41:07Z

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

commit cef7775c9dcfc32b11a4cc4678b3a69a1e1b17da
Author: iveselovskiy 
Date:   2017-03-30T13:05:23Z

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

commit 84e26d6fa2f6aec742fafb4d8145fbc9f697da70
Author: iveselovskiy 
Date:   2017-03-31T09:35:07Z

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

commit be360213d74c9f005e4e3a1beb661323262bb7fb
Author: iveselovskiy 
Date:   2017-03-31T12:18:43Z

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

commit ec3de454894f4bba4497b6c0ca0564a730525244
Author: iveselovskiy 
Date:   2017-04-17T15:22:00Z

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

commit 88de0693b76c80fdc6533a799e0475fd53a4b0fc
Author: iveselovskiy 
Date:   2017-05-02T13:20:47Z

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

commit 04d8f4ef69ea92b96642ecc3b797703858574c69
Author: iveselovskiy 
Date:   2017-05-11T13:23:05Z

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

commit a4f3655a11f2b57c190d72588694ca036f10b898
Author: iveselovskiy 
Date:   2017-05-15T14:43:13Z

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

commit a67c15db148735d01ef4d4227d80551224f548ff
Author: iveselovskiy 
Date:   2017-05-15T15:20:40Z

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

commit 3547f8c01148c8a38ef872c2b8f2f6a5631420bb
Author: iveselovskiy 
Date:   2017-05-17T16:20:02Z

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

commit dfc84ed19b643ec0e0cd234438e71f724b3154a9
Author: iveselovskiy 
Date:   2017-05-22T15:33:55Z

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

commit 2d87f95c07aa00a09562d411e0f1d80560817dee
Author: iveselovskiy 
Date:   2017-05-23T16:48:35Z

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

commit db476184f024f8397048a4e9df1556014dadbde5
Author: iveselovskiy 
Date:   2017-05-29T13:37:24Z

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

commit 4a1b219255fcd8a147542a6ec4a272d30e48e61c
Author: iveselovskiy 
Date:   2017-05-31T11:59:53Z

Merge branch 'master' of 

Re: place for printing info about partition distribution (IGNITE-4756)

[Denis Magda]

Taras, Yakov,

Please join the conversation.

—
Denis

> On Jun 4, 2017, at 3:43 AM, Вадим Опольский  wrote:
> 
> Guys, lets suggest the format for this log.
> 
> Yakov's version is "print only nodes that differ on +/-10% from average 
> partitions count we can print problem message looks like:
> 
> [cacheName=NAME, nodes=[nodeId= percentageOfTotalPartsCount=, parts=[, ...,]]
> 
> Where the first element of parts array is a count of primary partitions, the 
> second is count of backup0 partitions etc.
>  The default value of the property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD 
> must disable distribution calculation because it takes  * 
>  *  operations per node. "
> 
> Do you agree ?
> 
> 
> -- Forwarded message --
> From: Вадим Опольский >
> Date: 2017-06-04 13:42 GMT+03:00
> Subject: Fwd: place for printing info about partition distribution 
> (IGNITE-4756)
> To: Denis Magda >, 
> tled...@gridgain.com , Yakov Zhdanov 
> >
> 
> 
> Hello guys!
> 
> I cant start resolve issue 4756 
> (https://issues.apache.org/jira/browse/IGNITE-4756 
> ) because don't understand 
> place for pinting info about partition.
> 
> Yakov, Taras do you have any idea about it ?
> 
> Vadim Opolski
> 
> 
> 
> -- Forwarded message --
> From: Вадим Опольский >
> Date: 2017-05-31 18:24 GMT+03:00
> Subject: place for printing info about partition distribution
> To: dev@ignite.apache.org , Denis Magda 
> >, tled...@gridgain.com 
> , Yakov Zhdanov  >
> 
> 
> Hello guys!
> 
> I want to discuss and suggest some format and place for pinting info about 
> partition distribution to log from issue 
> https://issues.apache.org/jira/browse/IGNITE-4756 
> 
> What do you think about it ?
> 
> Issue is about RendezvousAffinityFunction and FairAffinityFunction classes.
> 
> Vadim
> 
> 
> 

Re: "Review workflow" changes to prevent "broken review" issues.

[Dmitry Pavlov]

Hi Anton,


It is ok for me if it is advice and hint for faster review, as it is now.


We can periodically remind about this opportunity at dev list or in the
issue comments. We can remind that tasks in patch available status may be
reassigned by contributor.


Looking from prospective of overall throughput: it is not clear for me how
this process change will help.


Best Regards,

Dmitriy Pavlov

пн, 5 июн. 2017 г. в 20:16, Anton Vinogradov :

> Vova,
>
> Contributors interested to make contributions and I propose them to use
> *same* strategy as we (people inside the community) use.
> "-1" will not solve this issue, but my "tips" will.
>
> Dmitry,
>
> The main problem here is that nobody notified that someone is waiting for
> the review.
> It's not a problem for me to provide tips or to make review, but it's
> problem to periodically check is there somebody waiting.
>
> Guys,
> Let's try this approach, and I'm pretty sure it will help.
>
> On Mon, Jun 5, 2017 at 7:58 PM, Dmitry Pavlov 
> wrote:
>
> > Hi Igniters, Anton,
> >
> > Let’s imagine that development process as a chain of production stages
> > 1) Developing patch by contributor
> > 2) Review changes by committer
> >
> > Reviews waiting too long time to be done at stage 2 may indicate that
> speed
> > (potential throughput) of step 2 is less than throughput at step 1. T2 >
> > In terms of this model (inspired by Goldratt’s Theory of Constraints
> > (TOC)), I have a question:
> > Will this responsibility movement (to find appropriate reviewer to
> > contributor) help us to increase overall throughput?
> >
> > If we agree constraint in terms of TOC is throughput T2, I suggest
> > following steps
> > - Increase the throughput T2 of the committers
> > - Reduce the load on the committers by improve quality of code after
> stage
> > 1 given to review (pre review by non-committer, automatic review, code
> > inspections)
> >
> > Best Regards,
> > Dmitriy Pavlov
> >
> >
> > пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov :
> >
> > > Igniters,
> > >
> > > Currently, according to
> > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > to+Contribute#HowtoContribute-SubmittingforReview
> > > ,
> > > contributor can ask for review by moving ticket to PATCH AVAILABLE
> state.
> > >
> > > And, as far as I can see, this cause broken tickets issue.
> > > Contributor can wait somebody who'll review his changes for a month or
> > even
> > > more.
> > >
> > > I propose to change workflow and *make contributor responsible to find
> > > reviewer*.
> > > It's pretty easy to find a person able to review changes in most of
> > cases.
> > >
> > > 1) You can check git history of files you modified and find persons
> with
> > > expertise in this code
> > > 2) In case you have problems with such search you can always use
> > > maintainers list (
> > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/How+
> > to+Contribute#HowtoContribute-ReviewProcessandMaintainers
> > > )
> > >
> > > Thoughts?
> > >
> >
>

Re: "Review workflow" changes to prevent "broken review" issues.

[Anton Vinogradov]

Vova,

Contributors interested to make contributions and I propose them to use
*same* strategy as we (people inside the community) use.
"-1" will not solve this issue, but my "tips" will.

Dmitry,

The main problem here is that nobody notified that someone is waiting for
the review.
It's not a problem for me to provide tips or to make review, but it's
problem to periodically check is there somebody waiting.

Guys,
Let's try this approach, and I'm pretty sure it will help.

On Mon, Jun 5, 2017 at 7:58 PM, Dmitry Pavlov  wrote:

> Hi Igniters, Anton,
>
> Let’s imagine that development process as a chain of production stages
> 1) Developing patch by contributor
> 2) Review changes by committer
>
> Reviews waiting too long time to be done at stage 2 may indicate that speed
> (potential throughput) of step 2 is less than throughput at step 1. T2
> In terms of this model (inspired by Goldratt’s Theory of Constraints
> (TOC)), I have a question:
> Will this responsibility movement (to find appropriate reviewer to
> contributor) help us to increase overall throughput?
>
> If we agree constraint in terms of TOC is throughput T2, I suggest
> following steps
> - Increase the throughput T2 of the committers
> - Reduce the load on the committers by improve quality of code after stage
> 1 given to review (pre review by non-committer, automatic review, code
> inspections)
>
> Best Regards,
> Dmitriy Pavlov
>
>
> пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov :
>
> > Igniters,
> >
> > Currently, according to
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-SubmittingforReview
> > ,
> > contributor can ask for review by moving ticket to PATCH AVAILABLE state.
> >
> > And, as far as I can see, this cause broken tickets issue.
> > Contributor can wait somebody who'll review his changes for a month or
> even
> > more.
> >
> > I propose to change workflow and *make contributor responsible to find
> > reviewer*.
> > It's pretty easy to find a person able to review changes in most of
> cases.
> >
> > 1) You can check git history of files you modified and find persons with
> > expertise in this code
> > 2) In case you have problems with such search you can always use
> > maintainers list (
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-ReviewProcessandMaintainers
> > )
> >
> > Thoughts?
> >
>

[GitHub] ignite pull request #2083: IGNITE-5196

[gvvinblade]

GitHub user gvvinblade opened a pull request:

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

IGNITE-5196



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

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

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

https://github.com/apache/ignite/pull/2083.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 #2083


commit 93ef1c9761df653a8a1019380c8b20ce20827d42
Author: Igor Seliverstov 
Date:   2017-06-05T13:43:07Z

IGNITE-5196




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Persistent Store and IgniteServices

[Alexey Goncharuk]

Hi Semyon,

Given that both ServiceDescriptors and service assignments are stored in
the system cache, services should survive the cluster restart, but this
needs to be double-checked because service assignments become obsolete and
need to be fully recalculated.

I will check this and give an update.

2017-06-05 15:42 GMT+03:00 Semyon Boikov :

> Hi guys,
>
> If persistent store feature is enabled, will IgniteServices survive cluster
> restrart?
>
> Thanks!
>

Re: "Review workflow" changes to prevent "broken review" issues.

[Dmitry Pavlov]

Hi Igniters, Anton,

Let’s imagine that development process as a chain of production stages
1) Developing patch by contributor
2) Review changes by committer

Reviews waiting too long time to be done at stage 2 may indicate that speed
(potential throughput) of step 2 is less than throughput at step 1. T2:

> Igniters,
>
> Currently, according to
>
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-SubmittingforReview
> ,
> contributor can ask for review by moving ticket to PATCH AVAILABLE state.
>
> And, as far as I can see, this cause broken tickets issue.
> Contributor can wait somebody who'll review his changes for a month or even
> more.
>
> I propose to change workflow and *make contributor responsible to find
> reviewer*.
> It's pretty easy to find a person able to review changes in most of cases.
>
> 1) You can check git history of files you modified and find persons with
> expertise in this code
> 2) In case you have problems with such search you can always use
> maintainers list (
>
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers
> )
>
> Thoughts?
>

Re: "Review workflow" changes to prevent "broken review" issues.

[Vladimir Ozerov]

We should keep in mind that contributor do not have to do anything, as this
is community. Instead, it is responsibility of the community to make sure
that contributions are processed in a timely manner, and that contributors
have positive experience with us.

So, -1 from my side.

On Mon, Jun 5, 2017 at 6:28 PM, Anton Vinogradov  wrote:

> Igniters,
>
> Currently, according to
> https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-SubmittingforReview
> ,
> contributor can ask for review by moving ticket to PATCH AVAILABLE state.
>
> And, as far as I can see, this cause broken tickets issue.
> Contributor can wait somebody who'll review his changes for a month or even
> more.
>
> I propose to change workflow and *make contributor responsible to find
> reviewer*.
> It's pretty easy to find a person able to review changes in most of cases.
>
> 1) You can check git history of files you modified and find persons with
> expertise in this code
> 2) In case you have problems with such search you can always use
> maintainers list (
> https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-ReviewProcessandMaintainers
> )
>
> Thoughts?
>

[jira] [Created] (IGNITE-5411) Persist affinity key on disc

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5411:
---

 Summary: Persist affinity key on disc
 Key: IGNITE-5411
 URL: https://issues.apache.org/jira/browse/IGNITE-5411
 Project: Ignite
  Issue Type: Task
  Components: binary
Reporter: Vladimir Ozerov
 Fix For: 2.1


Currently binary metadata is not persisted on a disk anyhow. It means that 
after full cluster restart we will loose all runtime metadata (except of those 
configured explicitly in {{IgniteConfiguration.binaryConfiguration}}.

In future releases we will store metadata in separate storage. For now I 
propose only to store typeId -> affinityKey mapping on disc to improve value of 
{{CREATE TABLE}} feature where affinity key is essential for data co-location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2067: Ignite 3562 lucene 5.5.2 new

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2066: Ignite 3562 lucene 5.5.2

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Persistent Distributed Store Metrics

[Alexey Goncharuk]

Guyd,

I've extended the set of metrics a little bit and pushed my changes to
ignite-5375 branch. Can you please review the metrics and see if we are now
ok with the interfaces?

2017-06-01 21:04 GMT+03:00 Denis Magda :

> Sergey, thanks,
>
> You get a green light from my side. Please go ahead and bring this to life
> unless anyone else has any comments.
>
> —
> Denis
>
> > On Jun 1, 2017, at 4:18 AM, Sergey Chugunov 
> wrote:
> >
> > Guys,
> >
> > I created a ticket [1] summing up results of our discussion. Please
> review
> > and leave comments if something is still unclear there.
> >
> > Thanks,
> > Sergey
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5375
> >
> > On Wed, May 31, 2017 at 11:56 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >> Denis, I do agree, the concept of virtual memory may work. I will start
> >> another discussion thread on that.
> >>
> >> We should extensively javadoc all these interfaces. The current
> one-liner
> >> javadoc documentation is not enough.
> >>
> >> Also, I would like to make a small correction to the MemoryMetrics
> >> interface, see below...
> >>
> >>
> >> On Wed, May 31, 2017 at 1:35 PM, Denis Magda  wrote:
> >>
> >>> Guys,
> >>> If to assume that the *page memory* is a sort of *virtual* memory that
> >>> maps a page to RAM or disk then MemoryMetrics interface makes sense if
> we
> >>> think of it as {Virtual}MemoryMetrics. It’s late to rename the
> interface
> >>> but this design flaw can be handled with a proper documentation.
> >>> At all, let’s gather all the page memory related metrics (both RAM and
> >>> disk) in MemoryMetrics interface. Here is it’s final version:
> >>> public interface MemoryMetrics {
> >>>public String getName();
> >>>
> >>>public long getTotalAllocatedPages();
> >>
> >>
> >> I think this method currently returns only the pages allocated in
> memory.
> >> To behave correctly, it now should return the total pages allocated
> within
> >> the virtual memory, which should be equal to the total pages on disk.
> >>
> >>
> >>>public long getPagesOnDisk();
> >>>
> >>
> >> This method should be removed as it represents the same value as
> >> "getTotalAllocatedPages()" method. Instead, we should add the following
> >> method:
> >>
> >> // Returns the number of pages allocated in physical off-heap memory.
> >> getPhysicalMemoryPages();
> >>
> >>
> >>>
> >>>public long getDirtyPages();
> >>>
> >>>public float getAllocationRate();
> >>>
> >>>public float getEvictionRate();
> >>>
> >>>public float getPagesFillFactor();
> >>>
> >>>public double getPagesMissRate();
> >>>
> >>>public float getLargeEntriesPagesPercentage();
> >>> }
> >>> I would rename getAllocationRate and getEvitionRate to
> >>> getPagesAllocationRate and getEvictionRates respectively but then we
> need
> >>> to deprecate the existing methods which is not good.
> >>>
> >>> As for the persistence metrics related to WAL and checkpointing let’s
> >>> store them here:
> >>>
> >>> public interface PersistentStoreMetrics {
> >>>public double getWalLoggingRate();
> >>>
> >>>public int getWalArchiveSegments();
> >>>
> >>>public double getWalFsyncTime();
> >>>
> >>>public double getCheckpointingTime();
> >>>
> >>>public double getCheckpointingFsyncTime();
> >>>
> >>>public long getCheckpointingTotalPagesNumber();
> >>>
> >>>public long[] getCheckpointingPagesByTypeNumber();
> >>>
> >>>public long getCheckpointingCopiedOnWritePagesNumber();
> >>> }
> >>>
> >>> Comments on the name of non released methods are welcomed.
> >>>
> >>> —
> >>> Denis
> >>>
>  On May 30, 2017, at 2:59 PM, Dmitriy Setrakyan  >
> >>> wrote:
> 
>  On Tue, May 30, 2017 at 2:46 PM, Denis Magda 
> >> wrote:
> 
> > I don’t have any extra metrics in mind for now. All I want to say
> that
> > presently the Store metrics interface aggregates WAL and
> checkpointing
> > metrics and in the future we might add additional Store related
> >> metrics
> > there (that has nothing to do with WAL). So, this is why
> >>> IgniteWalMetrics
> > doesn’t sound like a generic interface.
> >
> 
>  I think it is getting more and more confusing. I, for instance, do not
>  understand where memory metrics end and storage begins, neither I
> think
> >>> it
>  is important to separate memory policy related metrics from the WAL or
>  Checkpoint related metrics.
> 
>  How about we put them all together and have clear method names?
> 
> 
> >
> > —
> > Denis
> >
> >> On May 30, 2017, at 2:39 PM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> > wrote:
> >>
> >> On Tue, May 30, 2017 at 1:22 PM, Denis Magda 
> >>> wrote:
> >>
> >>> I’m afraid that in the future we might need to add non WAL related
> > metrics
> 

[jira] [Created] (IGNITE-5410) Invocation of HadoopOutputStream.write() with an empty array сauses an AssertionError.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-5410:
---

 Summary: Invocation of HadoopOutputStream.write() with an empty 
array сauses an AssertionError.
 Key: IGNITE-5410
 URL: https://issues.apache.org/jira/browse/IGNITE-5410
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 2.1
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
Priority: Minor


Writing an array of zero length causes the following AssertionError:

{code}
java.lang.AssertionError: 0
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopOffheapBuffer.move(HadoopOffheapBuffer.java:95)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.move(HadoopDataOutStream.java:55)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.collections.HadoopMultimapBase$AdderBase$1.move(HadoopMultimapBase.java:206)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.write(HadoopDataOutStream.java:70)
at org.apache.hadoop.io.BytesWritable.write(BytesWritable.java:187)
...
{code}

Suggested fix is to change the assertion to 
{code} assert size > 0 : size; {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5409) JDBC thin: support schema in query string

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5409:
---

 Summary: JDBC thin: support schema in query string
 Key: IGNITE-5409
 URL: https://issues.apache.org/jira/browse/IGNITE-5409
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


We need to support the following syntax: 
{{jdbc:ignite:thin://host:port/schema}}. 

In this case schema should be set to provided name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2082: IGNITE-5380

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5380



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

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

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

https://github.com/apache/ignite/pull/2082.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 #2082


commit 79917bfbc67eefa68d799746158c0d5ab5fcc19f
Author: Alexander Paschenko 
Date:   2017-06-01T15:33:35Z

IGNITE-5380 Query entity conflicts validation - first steps

commit 11736f3623fee692b97246b05854233ea06431c2
Author: Alexander Paschenko 
Date:   2017-06-02T10:02:32Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit 0bcf86240db99c697f2ae73ae1a472f867862547
Author: Alexander Paschenko 
Date:   2017-06-02T13:02:42Z

Merge remote-tracking branch 'apache/master' into ignite-5380

# Conflicts:
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/ddl/DdlStatementsProcessor.java

commit 621879d687480428bc375dd7c150712cf400b786
Author: Alexander Paschenko 
Date:   2017-06-02T13:29:41Z

IGNITE-5380 Additional schema wide index name uniqueness check.

commit ac06866faebb5d1f1f8d74ad0e99026e9a5f2264
Author: Alexander Paschenko 
Date:   2017-06-02T13:35:49Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit bce568648a6bc2f97bff0e7b36ced8fa08c26aee
Author: Alexander Paschenko 
Date:   2017-06-05T11:45:13Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit 0ebf6c7cf3e453e15cc8b84ac0dda48e1bf4037e
Author: Alexander Paschenko 
Date:   2017-06-05T15:35:10Z

IGNITE-5380 Tests.

commit 43a50f94dfc2aaf08b209d8d080ead885b5c02a9
Author: Alexander Paschenko 
Date:   2017-06-05T15:35:44Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit 0c83f340a1351c56d6bedb477cf1e61b05184909
Author: devozerov 
Date:   2017-06-05T15:45:59Z

Review.

commit a8c2ecdd8c340d7b17d193800fbd88c7342828e4
Author: devozerov 
Date:   2017-06-05T15:52:49Z

Review (unwrap issue).

commit 910b6595ce0b6ff8e8a7639e1a8195989d8f22ab
Author: Alexander Paschenko 
Date:   2017-06-05T16:00:39Z

IGNITE-5380 Minor.

commit 8dd7930726deb7f1bcb900e5276ec36b08ea631e
Author: Alexander Paschenko 
Date:   2017-06-05T16:08:55Z

IGNITE-5380 Minor.

commit e0fbf03b552905f1c251baea38fd2934999e7f69
Author: Alexander Paschenko 
Date:   2017-06-05T16:09:26Z

Merge remote-tracking branch 'apache/master' into ignite-5380




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2081: IGNITE-5379

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

"Review workflow" changes to prevent "broken review" issues.

[Anton Vinogradov]

Igniters,

Currently, according to
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-SubmittingforReview
,
contributor can ask for review by moving ticket to PATCH AVAILABLE state.

And, as far as I can see, this cause broken tickets issue.
Contributor can wait somebody who'll review his changes for a month or even
more.

I propose to change workflow and *make contributor responsible to find
reviewer*.
It's pretty easy to find a person able to review changes in most of cases.

1) You can check git history of files you modified and find persons with
expertise in this code
2) In case you have problems with such search you can always use
maintainers list (
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers
)

Thoughts?

[GitHub] ignite pull request #2081: IGNITE-5379

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5379



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

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

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

https://github.com/apache/ignite/pull/2081.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 #2081


commit ae8a40e56b4c95babd705e51f0412e9278281ceb
Author: devozerov 
Date:   2017-06-05T15:13:23Z

Done.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

New version of Web Console released

[Alexey Kuznetsov]

Igniters!

I'd like to announce that we just pushed new version of Ignite Web Console to
master branch
 and redeployed the new version on GridGain infrastructure (https://console
.gridgain.com) where you can give it a try right a way.

NOTE: You may need to refresh page (F5 or Ctrl+R) in order to reload Web
Console.

*What's new:*
 * Support for Ignite 1.x / Ignite 2.0
   You can configure, query and monitoring  Ignite 1.x and Ignite 2.0 from
single Web Console.

 * Improved build with web pack

*Coming soon:*
* Notifications about Web Console updates!
  Web console will show banner with warning about upcoming updates.

* Support for Ignite 2.1

* Improved stack trace for SQL errors.

Stay tuned for updates!


-- 
Alexey Kuznetsov

[GitHub] ignite pull request #2080: IGNITE-5275

[devozerov]

Github user devozerov closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2057: IGNITE-5309: Added schema to SqlFieldsQuery for C...

[isapego]

Github user isapego closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2071: IGNITE-5263: Replaced ODBC connection param "Cach...

[isapego]

Github user isapego closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Persistent Store and IgniteServices

[Semyon Boikov]

Hi guys,

If persistent store feature is enabled, will IgniteServices survive cluster
restrart?

Thanks!

[jira] [Created] (IGNITE-5408) JDBC driver should not require Class.forName() call

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5408:
---

 Summary: JDBC driver should not require Class.forName() call
 Key: IGNITE-5408
 URL: https://issues.apache.org/jira/browse/IGNITE-5408
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


Modern JDBC drivers do not require explicit init through {{Class.forName}}. 
Instead, it works as follows:
1) {{java.sql.Driver}} file is created under {{META-INF/services}} directory.
2) Driver has static initializer which registers itself within 
{{DriverManager}}.

We should do that for both think and new thin drivers, and remove all 
{{Class.forName}} calls from tests afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2080: IGNITE-5275

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5275



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

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

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

https://github.com/apache/ignite/pull/2080.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 #2080


commit 87d86a15ef26b74ae08c5f5a042c493ba963dda4
Author: devozerov 
Date:   2017-06-04T07:19:58Z

WIP.

commit 31205503d8f4eef72955aae19aa28ae448fc84c1
Author: devozerov 
Date:   2017-06-04T07:40:49Z

Created configuration bean.

commit 0bc5708b16ffb53848abc2ad4a40e6fde6782134
Author: devozerov 
Date:   2017-06-05T08:15:33Z

Merge branch 'master' into ignite-5275

commit c950aba8063c34c2046d699feb49673be9d605e6
Author: devozerov 
Date:   2017-06-05T10:18:02Z

Added connector configuration.

commit 954aaae5f1eb62ba7550c3fad1cf9bc0c7cfb511
Author: devozerov 
Date:   2017-06-05T10:36:57Z

Implemented ODBC -> SQL config conversion.

commit 3fd27fb2fbd844487c98a91791aad5b3835b2226
Author: devozerov 
Date:   2017-06-05T10:54:10Z

Added validation.

commit 4af1d1dee67a52934492ec023d219d56b784c126
Author: devozerov 
Date:   2017-06-05T10:54:50Z

Minors.

commit e89c0405b695a2b3c710dabfd536b4e4efe276cd
Author: devozerov 
Date:   2017-06-05T11:06:11Z

WIP.

commit d7e1c315e9ad63b68fc07046c7e4c1ec16a90fd8
Author: devozerov 
Date:   2017-06-05T11:07:35Z

Last class left: SqlListenerProcessorValidationSelfTest.

commit 6768a9ac8edc642f89b8939d411265c7e830abd3
Author: devozerov 
Date:   2017-06-05T11:20:43Z

WIP on tests.

commit b4dede2e18dc8b4dc5f82639158f649f548c2490
Author: devozerov 
Date:   2017-06-05T11:47:40Z

WIP on tests.

commit e598b20b47c5c3eafa2c3f39cacaf077aaae76aa
Author: devozerov 
Date:   2017-06-05T11:47:57Z

WIP.

commit 254a5a1cef52b3a228013c5d9ae0b1ce67c02ede
Author: devozerov 
Date:   2017-06-05T12:04:04Z

Tests.

commit bdf4bdadf147167fe4c6a4bd4584294a00b0a5c4
Author: devozerov 
Date:   2017-06-05T12:04:14Z

WIP.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2079: IGNITE-5233: JDBC thin Driver: implement metadata...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-5233: JDBC thin Driver: implement metadata support 



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

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

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

https://github.com/apache/ignite/pull/2079.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 #2079


commit b5c48680feb029c614557b457dc4e6451ca20f2d
Author: tledkov-gridgain 
Date:   2017-06-02T15:32:04Z

IGNITE-5233: save the progress

commit 06edb3ea591382aae22b73e0012edb166c022b55
Author: tledkov-gridgain 
Date:   2017-06-02T15:51:27Z

IGNITE-5233: save the progress

commit a50df0b490cf4972079fb90e0d0c593cf03e670c
Author: tledkov-gridgain 
Date:   2017-06-05T11:55:19Z

IGNITE-5233: index & params meta

commit 8df35cb890b2c2e88d3dd172c68579bb59bd
Author: tledkov-gridgain 
Date:   2017-06-05T12:06:36Z

Merge branch 'master' into ignite-5233

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/jdbc/thin/JdbcThinConnection.java




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5407) Web console: Wrong generation of marshaller on version switch

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-5407:
-

 Summary: Web console: Wrong generation of marshaller on version 
switch
 Key: IGNITE-5407
 URL: https://issues.apache.org/jira/browse/IGNITE-5407
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.0
Reporter: Vasiliy Sisko
 Fix For: 2.1


2) Marshaller on Summary is not changed when version is changed

on Cluster set version 1.x and set OptimizedMarshaller
go to Summary and look at preview - it shows Optimized
change version to 2.0 - look at preview - marshaller is still Optimized



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5406) VisorExecutorConfiguration and VisroGridConfiguration should use IgniteConfiguration.sqlConnectorConfiguration insread of IgniteConfiguration.odbcConfiguration

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5406:
---

 Summary: VisorExecutorConfiguration and VisroGridConfiguration 
should use IgniteConfiguration.sqlConnectorConfiguration insread of 
IgniteConfiguration.odbcConfiguration
 Key: IGNITE-5406
 URL: https://issues.apache.org/jira/browse/IGNITE-5406
 Project: Ignite
  Issue Type: Bug
  Components: sql, visor
Reporter: Vladimir Ozerov
Assignee: Alexey Kuznetsov
 Fix For: 2.1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2078: Ignite gg 8.0.4.ea2 for tests

[EdShangGG]

GitHub user EdShangGG opened a pull request:

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

Ignite gg 8.0.4.ea2 for tests



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

$ git pull https://github.com/gridgain/apache-ignite ignite-gg-8.0.4.ea2

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

https://github.com/apache/ignite/pull/2078.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 #2078


commit be881725b39926f62df437c2805ac9203fea5737
Author: Ilya Lantukh 
Date:   2016-10-11T16:19:20Z

gg-11595 : WIP.

commit e6d82d8da50b9af9607a914e00da3937d839862a
Author: Ilya Lantukh 
Date:   2016-10-12T16:20:50Z

gg-11595 : WIP.

commit cb9c18ccfc937b4a880eddb5df5d0389de9c7bee
Author: Ilya Lantukh 
Date:   2016-10-13T12:54:39Z

gg-11595 : WIP.

commit ed45f2238361e5bbbe907fdeb4b7a3d7b2b051dd
Author: Ilya Lantukh 
Date:   2016-10-27T13:02:28Z

gg-11595 : Support for restore with concurrent cache operations.

commit e95c68b77cbd3ad30d9f6d0b332137fb26000a41
Author: Ilya Lantukh 
Date:   2016-10-27T13:35:46Z

gg-11595 : Minors.

commit 7a44f1ebccf4fe0f26f54e070bbacbf24fbee3d7
Author: Ilya Lantukh 
Date:   2016-12-16T15:56:24Z

gg-11701 : WIP.

commit 3e2b28075ab5d00dce7fadf4769967f7a0ee2ee8
Author: Ilya Lantukh 
Date:   2016-12-19T12:25:11Z

Merge branches 'ignite-gg-11701' and 'ignite-gg-8.0.2.ea1' of 
https://github.com/gridgain/apache-ignite into ignite-gg-11701

commit cc568f9f6823de04f0beeca45ada4160a58307e4
Author: Ilya Lantukh 
Date:   2016-12-21T13:11:36Z

gg-11701 : WIP

commit e93f8d43a92dd8bde12c4677b5fcc6b0c2de6ce6
Author: Ilya Lantukh 
Date:   2016-12-27T10:45:29Z

Merge branches 'ignite-gg-11701' and 'ignite-gg-8.0.2.ea1' of 
https://github.com/gridgain/apache-ignite into ignite-gg-11701

commit 721f255eb2de1d8207e35328e2dec6514c22500d
Author: Ilya Lantukh 
Date:   2016-12-28T15:58:38Z

gg-11701 : Fixed preloading.

commit bed897dc01960dcbb7219ad948973e0f27bfa564
Author: Ilya Lantukh 
Date:   2016-12-28T16:31:51Z

gg-11701 : Fixed force keys request for single get.

commit 07535d92cd37cc949188434eb7ded2fc8d2e0647
Author: Ilya Lantukh 
Date:   2016-12-28T16:48:15Z

gg-11701 : Added check to multiple get.

commit ff9aa8898445c2a30e80fbc94f668eb5cd29a7d8
Author: Ilya Lantukh 
Date:   2016-12-29T13:04:49Z

Merge branches 'ignite-gg-11701' and 'ignite-gg-8.0.2.ea2' of 
https://github.com/gridgain/apache-ignite into ignite-gg-11701

commit 6cbe8a5a8ea5e4dacb8c5a859cb15aea5b3f38af
Author: Ilya Lantukh 
Date:   2017-01-09T15:22:15Z

gg-11701 : Fixed partition update counters comparison.

commit 3c276c9e092b6f6b4baf0b550ad89cb85ab9c42f
Author: Ilya Lantukh 
Date:   2017-01-10T10:25:09Z

gg-11701 : Implicit lateAffinityAssignment mode when persistence is enabled.

commit b3f7ae3bf903a0a6357163029ed310647877c8fc
Author: Ilya Lantukh 
Date:   2017-01-10T11:25:24Z

gg-11701 : Replaced redundant checks with assertions.

commit 2e55ddb600819dbf4684c0e97cc71a733167a4ce
Author: Ilya Lantukh 
Date:   2017-01-11T15:05:25Z

gg-11701 : Merge with 8.0.2.ea2

commit ecead988090e6a65ffdbb4098252ea26287fe36e
Author: Ilya Lantukh 
Date:   2017-01-11T15:09:25Z

gg-11701 : Merge with 8.0.2.ea2

commit adc0422592a18a7c2635e45185ef17852cd41952
Author: Glukos 
Date:   2017-01-13T17:23:06Z

GG-11595:
Remote exception wrapped on proxy level

commit 4505066481d4fff601a14d344dc8059f5dbe73de
Author: Ivan Rakov 
Date:   2017-01-13T21:32:08Z

GG-11595:
+ serialVersionUid

commit ba847555c86c00a288362e1cfad8c4c30883975c
Author: Ivan Rakov 
Date:   2017-01-16T15:08:35Z

Merge branch 'ignite-gg-8.0.2.ea2#' into ignite-gg-11595

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/DynamicCacheChangeRequest.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheProcessor.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheProxy.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteDynamicCacheStartSelfTest.java

commit 

[jira] [Created] (IGNITE-5405) Null values in comparator for EvictableEntry

[Richa Bali (JIRA)]

Richa Bali created IGNITE-5405:
--

 Summary: Null values in comparator for EvictableEntry
 Key: IGNITE-5405
 URL: https://issues.apache.org/jira/browse/IGNITE-5405
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Richa Bali


EvictableEntry has null value for corresponding key.
We cache an object with key as a unique identifier (member variable of the 
object) and value as the object itself.
EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.

Entry is removed from cache for some keys but those entries are subsequently 
passed to comparator with key but null object.

Sample project is attached.
Details of sample project:
DemoEntry class containing mId and mTimeUTC. mId is the unique identifier used 
as key for cache and mTimeUTC is the member variable used in DemoComparator.
DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
IgniteEvictionListener is the listener to check if the entries are evicted.

Sample run:
DemoProject:
10 entries are added to cache for which the eviction policy used is 
SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
2 of the entries are removed and data in cache is printed.

Note: Removed keys are not used to fetch the data from cache.

Observations:
Sometimes, null value for the key (not null key) is passed to comparator. Since 
the data used in sample project is limited to 10 entries only, it is not 
reproducible in all the runs. It occurs sometimes (may be because of 
asynchronous behavior).
But if we try to retrieve even the removed value by commenting lines 62-64 of 
DemoProject, it is usually reproducible.

Attached are the sample logs where we retrieved only those values that were not 
removed.
"Null value logs.txt": logs when null value scenario occurred.
"No null value logs.txt": logs when null value scenario didn't occur.

Sample project is also attached. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: contention on DataStructure creation/removing

[Mikhail Cherkasov]

Hi all,

Yakov pointed me that I didn't remove Reenrtrant Lock after it use.  Data
Structures'
are stored in HashMap, so serialization and deserialization time depends on
HashMap size
and becomes very expensive without removing unused data structures.

I added removing for unused Reenrtrant Locks and run benchmark again.
Now difference isn't so dramatic as it was : ~1000 op/s vs ~4500 op/s

Also I decided to test it with some number of pre-created Data Structures
in cache:

100 reentrantlock in cache: ~700 op/s vs ~4500 op/s
1000 reentrantlock in cache: ~180 op/s vs ~4500 op/s
1 reentrantlock in cache: ~25 op/s vs ~ 4500 op/s

I've run TC:

http://ci.ignite.apache.org/viewLog.html?buildId=640339=buildResultsDiv=Ignite20Tests_RunAll

it doesn't look very "green", 4 suites failed with timeout, I've re-run
them:

http://ci.ignite.apache.org/viewLog.html?buildId=645487; - green
http://ci.ignite.apache.org/viewLog.html?buildId=645488; - green
http://ci.ignite.apache.org/viewLog.html?buildId=645485=buildResultsDiv=Ignite20Tests_IgniteCacheFailover2
- 1 failed test, I'm checking it.
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteDataGridRestarts_Ignite20Tests=pull%2F2053%2Fhead=buildTypeStatusDiv
- still running

also there're several red tests, but almost all of them are flaky, except 2
test - I'm checking them too.

Thanks,
Mikhail.


On Fri, Jun 2, 2017 at 7:00 PM, Mikhail Cherkasov 
wrote:

> https://github.com/apache/ignite/pull/2053/files
>
> I'm checking TC, now, I'll send it for review as soon as pull request
> passes TC.
>
> On Fri, Jun 2, 2017 at 6:41 PM, Dmitriy Setrakyan 
> wrote:
>
>> Wow, what was patched? Can you provide the code sample being benchmarked?
>>
>> On Fri, Jun 2, 2017 at 8:00 AM, Mikhail Cherkasov <
>> mcherka...@gridgain.com>
>> wrote:
>>
>> > Looks like dev list doesn't allow to include pictures in emails, so
>> there
>> > are links to plots:
>> >
>> > Throughput plot without any changes:
>> > https://www.dropbox.com/s/mc3v5m49u4i2be3/no-changes.png?dl=0
>> >
>> > the same plot with patched ignite:
>> > https://www.dropbox.com/s/cyojw9nz4smew87/with-chages.png?dl=0
>> >
>> > 17000 operations/sec vs 70 operations/sec.
>> >
>> > On Fri, Jun 2, 2017 at 4:57 PM, Mikhail Cherkasov <
>> mcherka...@gridgain.com
>> > > wrote:
>> >
>> >> Hi all,
>> >>
>> >> I prepared a benchmark for ignite reentrant lock, the benchmark updates
>> >> cache values under the reentrant lock.
>> >> The benchmark is based on s real case, when user can't use regular
>> cache
>> >> locks, because they
>> >> prevent partition map exchange and as result don't allow new nodes join
>> >> cluster.
>> >>
>> >> Throughput plot without any changes:
>> >>
>> >> [image: Inline image 1]
>> >>
>> >> the same plot with patched ignite:
>> >>
>> >> [image: Inline image 2]
>> >>
>> >>
>> >> On Thu, Jun 1, 2017 at 1:29 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>> >> wrote:
>> >>
>> >>> Won't it be confusing from a user stand point to have multiple data
>> >>> structures with the same name? Also, what is the performance impact of
>> >>> this
>> >>> change?
>> >>>
>> >>> D.
>> >>>
>> >>> On Wed, May 31, 2017 at 8:23 AM, Semyon Boikov 
>> >>> wrote:
>> >>>
>> >>> > Hi Mikhail,
>> >>> >
>> >>> > As far as I remember for some reason we wanted to guarantee that all
>> >>> data
>> >>> > structures have unique names. But now I don't see why this can be
>> >>> needed
>> >>> > and it seems we do not need this data structures map at all, if
>> nobody
>> >>> have
>> >>> > objection I think you can implement suggested change.
>> >>> >
>> >>> > Thanks!
>> >>> >
>> >>> > On Wed, May 31, 2017 at 3:04 PM, Mikhail Cherkasov <
>> >>> > mcherka...@gridgain.com>
>> >>> > wrote:
>> >>> >
>> >>> > > Hi all,
>> >>> > >
>> >>> > > All DataStructures are stored in one Map which itself is stored in
>> >>> > > utilityCache, this makes high contention on DS creation or
>> removing,
>> >>> it
>> >>> > > requires to acquire Map's lock and manipulation with the Map under
>> >>> the
>> >>> > > lock. So all threads in cluster should wait for this lock to
>> create
>> >>> or
>> >>> > > remove DS.
>> >>> > >
>> >>> > > I don't see any reason to store all DS in one map,  we already
>> have
>> >>> > > utilityCache and can save DSs directly in utilityCache, to
>> >>> distinguish DS
>> >>> > > with other objects in utilityCache I use composite key, the first
>> >>> part of
>> >>> > > which is DATA_STRUCTURES_KEY, second one is DS's name, also DS
>> type
>> >>> can
>> >>> > be
>> >>> > > added, this will allow us to create different DS with the same
>> name.
>> >>> > >
>> >>> > > There is draft implementations, all DSs are stored with unique
>> key in
>> >>> > > utilityCache:
>> >>> > > https://github.com/apache/ignite/pull/2046/files
>> >>> > >
>> >>> > > May be there's some reason to store all DS in one Map that I
>> missed?
>> >>> > > Any thoughts?
>> >>> > >
>> 

[jira] [Created] (IGNITE-5404) SQL temp table join does not work with typed arrays

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5404:
--

 Summary: SQL temp table join does not work with typed arrays
 Key: IGNITE-5404
 URL: https://issues.apache.org/jira/browse/IGNITE-5404
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
 Fix For: 2.1


Reproducer:

{code}
Ignite ignite = Ignition.start();

QueryEntity qe = new QueryEntity("java.lang.Integer", 
"java.lang.String");
Collection qes = new ArrayList();
qes.add(qe);
CacheConfiguration ccfg = new 
CacheConfiguration("foo").setQueryEntities(qes);
IgniteCache cache = ignite.createCache(ccfg);

cache.put(1, "1");
cache.put(2, "2");

// Works
// Object[] queryArgs = {new Object[]{1}};

// Does not work
Object[] queryArgs = {new int[]{1}};

SqlFieldsQuery query = new SqlFieldsQuery(
"select _val from string join table (id bigint = ?) i on _key = 
id")
.setArgs(queryArgs);

List all = cache.query(query).getAll();

for (List l : all) {
System.out.println(l.get(0));
}
{code}

Exception:
{code}
SEVERE: Failed to execute local query.
class org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1226)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1278)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1253)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:610)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:478)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:149)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:147)
at 
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2426)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1308)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:729)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1493)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:113)
at TestLocalJoin.main(TestLocalJoin.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: org.h2.jdbc.JdbcSQLException: Data conversion error converting 
"'[I@6bea52d4' (ID BIGINT)"; SQL statement:
SELECT
__Z0._VAL __C0_0
FROM TABLE(ID BIGINT=?1) I__Z1 
 INNER JOIN "foo".STRING __Z0 
 ON TRUE
WHERE __Z0._KEY = I__Z1.ID [22018-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.table.Column.convert(Column.java:172)
at org.h2.expression.TableFunction.getTable(TableFunction.java:118)
at org.h2.expression.TableFunction.getValue(TableFunction.java:41)
at org.h2.table.FunctionTable.getValueResultSet(FunctionTable.java:218)
at org.h2.table.FunctionTable.getResult(FunctionTable.java:189)
at org.h2.index.FunctionIndex.find(FunctionIndex.java:50)
at org.h2.index.BaseIndex.find(BaseIndex.java:128)
at org.h2.index.IndexCursor.find(IndexCursor.java:169)
at org.h2.table.TableFilter.next(TableFilter.java:468)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1452)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at 

[jira] [Created] (IGNITE-5403) Test flakily fails

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-5403:
--

 Summary: Test flakily fails
 Key: IGNITE-5403
 URL: https://issues.apache.org/jira/browse/IGNITE-5403
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.9
Reporter: Stanilovsky Evgeny
Priority: Critical


simple flaky nodes test fails.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5402) Errors related to multi-version support

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-5402:
--

 Summary: Errors related to multi-version support
 Key: IGNITE-5402
 URL: https://issues.apache.org/jira/browse/IGNITE-5402
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov


1) eviction policy for server and client is the same, but should be different
2) Marshaller on Summary is not changed when version is changed

on Cluster set version 1.x and set OptimizedMarshaller
go to Summary and look at preview - it shows Optimized
change version to 2.0 - look at preview - marshaller is still Optimized





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Request for contributor permissions

[Alexey Ivanov]

Hello everybody,

Please give me contributor permissions.

Alexey Ivanov