need review for PR

[Igor Rudyak]

Hi guys,

Appreciate if somebody can do a review for the PR:
https://github.com/apache/ignite/pull/3940

Igor

Re: missing website info

[Dmitriy Setrakyan]

On Tue, May 8, 2018 at 6:23 PM, Denis Magda  wrote:

> Dmitriy,
>
> Presently this information is scattered and presented under sections named
> differently. Agree with the format proposed by you.
> https://issues.apache.org/jira/browse/IGNITE-8455
>
> In addition, we should cover another mode which is indexes in RAM and data
> on disk to get a better technical cost of ownership of Ignite's cluster. I
> heard it's already possible to set up this kind of configuration.
>

Agree, but we do not have this mode yet. When we do, we should definitely
cover it.

Where is ICache.Removex() in .Net client?

[Raymond Wilson]

I have some code the removes elements from a cache, and I’d like to improve
its performance.



The help for ICache.Remove() states that the element removed will be
returned to the call, and that if the element is not required, then
Removex() should be used to avoid the overhead of returning the element.



In the .Net client Removex() does not appear to be present.



Is there a ticket to have this included in the .Net client?



Thanks,

Raymond.

[GitHub] ignite pull request #3639: IGNITE-7608

[SomeFire]

Github user SomeFire closed the pull request at:

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


---

Re: method arguments code style

[Dmitry Pavlov]

Hi Vyacheslav,

Can we proceed with plugin publishing? I have not seen any objections, so I
propose to complete this task.

Sincerely,
Dmitriy Pavlov

вт, 8 мая 2018 г. в 21:47, Vyacheslav Daradur :

> Hi, Igniters!
>
> After the completion of publishing abbr-plugin [1][2] we will be able
> to automate checking of method arguments code style.
>
> It will be easy to check rules approved by the community during writing
> code.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5698
> [2]
> http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html
>
> On Tue, May 8, 2018 at 8:34 PM, Dmitry Pavlov 
> wrote:
> > Folks, I've messed with another topic, where Vladimir was going to update
> > review check-list.
> >
> > Here I've updated Coding Guidelines:
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-MethodArguments
> >
> > Please review changes, so we can consider it is final.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 8 мая 2018 г. в 20:05, Dmitry Pavlov :
> >
> >> I thought that Vladimir will update.
> >>
> >> By the way, Denis M, I propose to grant access to the wiki to Dmitry G.
> >> WDYT?
> >>
> >> вт, 8 мая 2018 г. в 19:28, Dmitriy Govorukhin <
> >> dmitriy.govoruk...@gmail.com>:
> >>
> >>> Dmitriy,
> >>>
> >>> Сould you please update code style wiki page in accordance with the
> >>> results of the discussion?
> >>> On May 7 2018, at 11:00 am, Vladimir Ozerov 
> wrote:
> >>> >
> >>> > Dmitry,
> >>> > Agree, mixed style when some arguments share the same line and others
> >>> don't
> >>> > looks very bad. My proposal was to allow two styles - first when all
> >>> > arguments are on the same line splitted by 120 char limit, second
> when
> >>> all
> >>> > every arguments is on a separate line.
> >>> > Mixed style should be disallowed.
> >>> >
> >>> > On Mon, May 7, 2018 at 12:35 AM, Dmitriy Govorukhin <
> >>> > dmitriy.govoruk...@gmail.com> wrote:
> >>> >
> >>> > > Vladimir,
> >>> > > My eyes cry when I see this
> >>> > > public double getCost(Session ses, int[] masks, TableFilter[]
> filters,
> >>> > > int filter, SortOrder sortOrder,
> >>> > > HashSet cols) {
> >>> > > return SpatialTreeIndex.getCostRangeIndex(masks,table.
> >>> > > getRowCountApproximation(),
> >>> > > columns) / 10;
> >>> > > }
> >>> > >
> >>> > > Why did arguments split into 3 line?
> >>> > > It is much better readable for me
> >>> > > public double getCost(
> >>> > > Session ses,
> >>> > > int[] masks,
> >>> > > TableFilter[] filters,
> >>> > > int filter,
> >>> > > SortOrder sortOrder,
> >>> > > HashSet cols
> >>> > > ) {
> >>> > > return SpatialTreeIndex.getCostRangeIndex(masks,
> >>> > > able.getRowCountApproximation(),
> >>> > > columns) / 10;
> >>> > > }
> >>> > >
> >>> > > Do we have a serious reason to continue writing code as before?
> >>> > >
> >>> > >
> >>> > > On Thu, May 3, 2018 at 2:24 PM, Vladimir Ozerov <
> voze...@gridgain.com
> >>> >
> >>> > > wrote:
> >>> > >
> >>> > > > My opinion is that we should allow both styles and not enforce
> any
> >>> of
> >>> > > them.
> >>> > > > I hardly can say that this
> >>> > > >
> >>> > > > public double getCost(
> >>> > > > Session ses,
> >>> > > > int[] masks,
> >>> > > > TableFilter[] filters,
> >>> > > > int filter,
> >>> > > > SortOrder sortOrder,
> >>> > > > HashSet cols
> >>> > > > ) {
> >>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
> >>> > > > table.getRowCountApproximation(), columns) / 10;
> >>> > > > }
> >>> > > >
> >>> > > > is better than this
> >>> > > > public double getCost(Session ses, int[] masks, TableFilter[]
> >>> filters,
> >>> > > > int filter, SortOrder sortOrder,
> >>> > > > HashSet cols) {
> >>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
> >>> > > > table.getRowCountApproximation(), columns) / 10;
> >>> > > > }
> >>> > > >
> >>> > > >
> >>> > > > But this
> >>> > > > public CacheLockCandidates doneRemote(
> >>> > > > GridCacheVersion ver,
> >>> > > > Collection pending,
> >>> > > > Collection committed,
> >>> > > > Collection rolledback
> >>> > > > )
> >>> > > >
> >>> > > >
> >>> > > > looks better than this
> >>> > > > public CacheLockCandidates doneRemote(GridCacheVersion ver,
> >>> > > > Collection pending,
> >>> > > > Collection committed,
> >>> > > > Collection rolledback)
> >>> > > >
> >>> > > >
> >>> > > > The very problem is that our eyes feel comfortable when we either
> >>> move
> >>> > > them
> >>> > > > horizontally, or vertically (example 2). But with proposed code
> >>> style you
> >>> > > > have to do zigzag movements in general case because lines are not
> >>> aligned
> >>> > > > (example 1).
> >>> > > > Merge conflicts on multiliners are hardly of major concern for
> us.
> >>> > > >
> >>> > > > Vladimir.
> >>> > > > On Thu, May 3, 2018 at 1:46 PM, Eduard Shangareev <
> >>> > > > eduard.shangar...@gmail.com> wrote:
> >>> > > >
> >>> > > > > 

Re: Service grid redesign

[Vyacheslav Daradur]

Thanks, Denis! I assigned the task to myself.

I going to start work next week.

On Tue, May 8, 2018 at 7:50 PM, Denis Mekhanikov  wrote:
> Hi Vyacheslav!
>
> Thanks for the enthusiasm!
> The first ticket to be implemented here is IGNITE-8361
> .
> I think, until this one is resolved, other tasks can't be started.
>
> Please assign it to yourself, if you feel confident enough.
> Feel free to ask for any help, if you need.
>
> For now it will be enough to perform service deployment and initialization
> in the discovery thread.
> Making it asynchronous will be our next step: IGNITE-8362
> 
>
> Denis
>
> вт, 24 апр. 2018 г. в 15:43, Vyacheslav Daradur :
>
>> Hi, Denis M.,
>>
>> I'd like to pick up a ticket from IEP-17 next week.
>>
>> Could you please advise a ticket to start?
>>
>> On Tue, Apr 24, 2018 at 11:47 AM, Dmitriy Setrakyan
>>  wrote:
>> > On Tue, Apr 24, 2018, 3:59 PM Denis Mekhanikov 
>> > wrote:
>> >
>> >> Dmitriy,
>> >>
>> >> After the proposed changes are made the utility cache won't be needed at
>> >> all.
>> >>
>> >
>> > I was rather talking about prioritization. In my view, first and foremost
>> > we must fix deployment before anything else.
>> >
>> > D.
>>
>>
>>
>> --
>> Best Regards, Vyacheslav D.
>>



-- 
Best Regards, Vyacheslav D.

Re: method arguments code style

[Vyacheslav Daradur]

Hi, Igniters!

After the completion of publishing abbr-plugin [1][2] we will be able
to automate checking of method arguments code style.

It will be easy to check rules approved by the community during writing code.

[1] https://issues.apache.org/jira/browse/IGNITE-5698
[2] 
http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html

On Tue, May 8, 2018 at 8:34 PM, Dmitry Pavlov  wrote:
> Folks, I've messed with another topic, where Vladimir was going to update
> review check-list.
>
> Here I've updated Coding Guidelines:
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-MethodArguments
>
> Please review changes, so we can consider it is final.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 8 мая 2018 г. в 20:05, Dmitry Pavlov :
>
>> I thought that Vladimir will update.
>>
>> By the way, Denis M, I propose to grant access to the wiki to Dmitry G.
>> WDYT?
>>
>> вт, 8 мая 2018 г. в 19:28, Dmitriy Govorukhin <
>> dmitriy.govoruk...@gmail.com>:
>>
>>> Dmitriy,
>>>
>>> Сould you please update code style wiki page in accordance with the
>>> results of the discussion?
>>> On May 7 2018, at 11:00 am, Vladimir Ozerov  wrote:
>>> >
>>> > Dmitry,
>>> > Agree, mixed style when some arguments share the same line and others
>>> don't
>>> > looks very bad. My proposal was to allow two styles - first when all
>>> > arguments are on the same line splitted by 120 char limit, second when
>>> all
>>> > every arguments is on a separate line.
>>> > Mixed style should be disallowed.
>>> >
>>> > On Mon, May 7, 2018 at 12:35 AM, Dmitriy Govorukhin <
>>> > dmitriy.govoruk...@gmail.com> wrote:
>>> >
>>> > > Vladimir,
>>> > > My eyes cry when I see this
>>> > > public double getCost(Session ses, int[] masks, TableFilter[] filters,
>>> > > int filter, SortOrder sortOrder,
>>> > > HashSet cols) {
>>> > > return SpatialTreeIndex.getCostRangeIndex(masks,table.
>>> > > getRowCountApproximation(),
>>> > > columns) / 10;
>>> > > }
>>> > >
>>> > > Why did arguments split into 3 line?
>>> > > It is much better readable for me
>>> > > public double getCost(
>>> > > Session ses,
>>> > > int[] masks,
>>> > > TableFilter[] filters,
>>> > > int filter,
>>> > > SortOrder sortOrder,
>>> > > HashSet cols
>>> > > ) {
>>> > > return SpatialTreeIndex.getCostRangeIndex(masks,
>>> > > able.getRowCountApproximation(),
>>> > > columns) / 10;
>>> > > }
>>> > >
>>> > > Do we have a serious reason to continue writing code as before?
>>> > >
>>> > >
>>> > > On Thu, May 3, 2018 at 2:24 PM, Vladimir Ozerov >> >
>>> > > wrote:
>>> > >
>>> > > > My opinion is that we should allow both styles and not enforce any
>>> of
>>> > > them.
>>> > > > I hardly can say that this
>>> > > >
>>> > > > public double getCost(
>>> > > > Session ses,
>>> > > > int[] masks,
>>> > > > TableFilter[] filters,
>>> > > > int filter,
>>> > > > SortOrder sortOrder,
>>> > > > HashSet cols
>>> > > > ) {
>>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
>>> > > > table.getRowCountApproximation(), columns) / 10;
>>> > > > }
>>> > > >
>>> > > > is better than this
>>> > > > public double getCost(Session ses, int[] masks, TableFilter[]
>>> filters,
>>> > > > int filter, SortOrder sortOrder,
>>> > > > HashSet cols) {
>>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
>>> > > > table.getRowCountApproximation(), columns) / 10;
>>> > > > }
>>> > > >
>>> > > >
>>> > > > But this
>>> > > > public CacheLockCandidates doneRemote(
>>> > > > GridCacheVersion ver,
>>> > > > Collection pending,
>>> > > > Collection committed,
>>> > > > Collection rolledback
>>> > > > )
>>> > > >
>>> > > >
>>> > > > looks better than this
>>> > > > public CacheLockCandidates doneRemote(GridCacheVersion ver,
>>> > > > Collection pending,
>>> > > > Collection committed,
>>> > > > Collection rolledback)
>>> > > >
>>> > > >
>>> > > > The very problem is that our eyes feel comfortable when we either
>>> move
>>> > > them
>>> > > > horizontally, or vertically (example 2). But with proposed code
>>> style you
>>> > > > have to do zigzag movements in general case because lines are not
>>> aligned
>>> > > > (example 1).
>>> > > > Merge conflicts on multiliners are hardly of major concern for us.
>>> > > >
>>> > > > Vladimir.
>>> > > > On Thu, May 3, 2018 at 1:46 PM, Eduard Shangareev <
>>> > > > eduard.shangar...@gmail.com> wrote:
>>> > > >
>>> > > > > Alexey,
>>> > > > > +1.
>>> > > > > I personally also follow this style.
>>> > > > > On Thu, May 3, 2018 at 12:45 PM, Alexey Goncharuk <
>>> > > > > alexey.goncha...@gmail.com> wrote:
>>> > > > >
>>> > > > > > Actually, I've been following the suggested code style for
>>> quite a
>>> > > > while.
>>> > > > > > I'm ok to add this to coding guidelines, however, I think we
>>> should
>>> > > > >
>>> > > >
>>> > > > allow
>>> > > > > > the old style when the method signature (without throws clause)
>>> fits
>>> > > > >

[jira] [Created] (IGNITE-8459) Searching checkpoint history for WAL rebalance is broken

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8459:
---

 Summary: Searching checkpoint history for WAL rebalance is broken
 Key: IGNITE-8459
 URL: https://issues.apache.org/jira/browse/IGNITE-8459
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko


Currently the mechanism to search available checkpoint records in WAL to have 
history for WAL rebalance is broken. It means that WAL (Historical) rebalance 
will never find history for rebalance and full rebalance will be always used.

This mechanism was broken in 
https://github.com/apache/ignite/commit/ec04cd174ed5476fba83e8682214390736321b37
 by unclear reasons.

If we swap the following two code blocks (database().beforeExchange() and 
exchCtx if block):

{noformat}
/* It is necessary to run database callback before all topology 
callbacks.
   In case of persistent store is enabled we first restore partitions 
presented on disk.
   We need to guarantee that there are no partition state changes 
logged to WAL before this callback
   to make sure that we correctly restored last actual states. */
cctx.database().beforeExchange(this);

if (!exchCtx.mergeExchanges()) {
for (CacheGroupContext grp : cctx.cache().cacheGroups()) {
if (grp.isLocal() || cacheGroupStopping(grp.groupId()))
continue;

// It is possible affinity is not initialized yet if node joins 
to cluster.
if (grp.affinity().lastVersion().topologyVersion() > 0)
grp.topology().beforeExchange(this, !centralizedAff && 
!forceAffReassignment, false);
}
}
{noformat}

the searching mechanism will start to work correctly. Currently it's unclear 
why it's happened.



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

Re: Postpone Apache Ignite 2.5 release to fix baseline topology

[Andrey Gura]

Dmitry,

additional BLT related logging is already added. I hope it will help
users to understand BLT better.

On Tue, May 8, 2018 at 3:36 PM, Dmitriy Setrakyan  wrote:
> Completely support the decision to move any BLT behavior changes to 2.6.
> However, in 2.5 we need to add usability log messages, which I believe we
> already have.
>
> D.
>
> On Tue, May 8, 2018 at 2:15 PM, Andrey Gura  wrote:
>
>> Igniters,
>>
>> I believe BLT is serious usability problem but rush isn't good idea
>> because can lead to new bugs. As release manager I think that we
>> should move BLT fix to Apache Ignite 2.6 release and focus on issues
>> included to the AI 2.5 release scope.
>> I also want inform you that code freeze is planned for Friday, May 11.
>>
>> Thanks!
>>
>> On Sun, Apr 29, 2018 at 8:44 PM, Dmitry Pavlov 
>> wrote:
>> > Hi Dmitriy,
>> >
>> > As far as I understand manual activation will not be required for
>> in-memory
>> > mode (same for persistence). Change means we will change node state from
>> > 'joined-inactive' to 'joined-active' according to that user defined in
>> > policy (cluster grow policy).
>> >
>> > Default will be allow to rebalance data to joined node, probably, with
>> some
>> > delay. This detail will be defenetely discussed at dev list before
>> > implementation.
>> >
>> > Pros: Persistent users will not be facing with disabled rebalancing in
>> case
>> > of node left - (BL)AT will be changed automatically. This also be handled
>> > by cluster shrink policy for both in-memory and durable cases.
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > сб, 28 апр. 2018 г. в 21:10, Dmitriy Setrakyan :
>> >
>> >> Can someone explain what is the before and after effect for this change
>> >> from the usability standpoint. If we are changing BLT for the in-memory
>> >> mode, which is the default, then we must think through all the usability
>> >> consequences ahead of time. Otherwise, the perception will be that the
>> >> product stopped working because someone did not know to activate the
>> >> cluster.
>> >>
>> >> D.
>> >>
>> >> On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda  wrote:
>> >>
>> >> > I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's
>> not
>> >> > time-consuming. To give you a bit more context on the subj, here is
>> why
>> >> we
>> >> > should have the fix to be delivered in 2.5:
>> >> > http://apache-ignite-users.70518.x6.nabble.com/Problems-
>> >> > with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
>> >> >
>> >> > Frankly, it's not the first time I see similar complaints from those
>> who
>> >> > are on 2.4.
>> >> >
>> >> > Alex G., Vovan, how hard is it to fix this?
>> >> >
>> >> > --
>> >> > Denis
>> >> >
>> >> >
>> >> > On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <
>> voze...@gridgain.com>
>> >> > wrote:
>> >> >
>> >> > > Yakov,
>> >> > >
>> >> > > Messages would help users understand what is wrong earlier, but will
>> >> not
>> >> > > protect them from additional maintenance which is required in AI 2.4
>> >> and
>> >> > is
>> >> > > supposed to be removed in next AI releases.
>> >> > > Please note that in IEP-4 topic I proposed alternative solution -
>> >> release
>> >> > > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
>> >> > would
>> >> > > be emergency release.
>> >> > >
>> >> > > Both approaches works for me, the main goal is to deliver original
>> >> > defaults
>> >> > > ASAP. However, approach with a single release looks better to me
>> >> because
>> >> > it
>> >> > > will minimize number of migrations for users.
>> >> > >
>> >> > > Vladimir.
>> >> > >
>> >> > >
>> >> > > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov > >
>> >> > > wrote:
>> >> > >
>> >> > > > Guys, how about we release 2.5 in the nearest future after adding
>> >> > proper
>> >> > > > usability log messages that will explain user what to do and also
>> >> > output
>> >> > > > link to readme.io with the first BLT related message during node
>> >> > uptime.
>> >> > > > This should not take much time and we can use the same messages
>> when
>> >> we
>> >> > > > have (BL)AT modes in 2.6. I think that adding messages makes sense
>> >> and
>> >> > > > should be clear for users which is not the case for 2.4.
>> >> > > >
>> >> > > > --Yakov
>> >> > > >
>> >> > >
>> >> >
>> >>
>>

Re: method arguments code style

[Dmitry Pavlov]

Folks, I've messed with another topic, where Vladimir was going to update
review check-list.

Here I've updated Coding Guidelines:
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-MethodArguments

Please review changes, so we can consider it is final.

Sincerely,
Dmitriy Pavlov

вт, 8 мая 2018 г. в 20:05, Dmitry Pavlov :

> I thought that Vladimir will update.
>
> By the way, Denis M, I propose to grant access to the wiki to Dmitry G.
> WDYT?
>
> вт, 8 мая 2018 г. в 19:28, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com>:
>
>> Dmitriy,
>>
>> Сould you please update code style wiki page in accordance with the
>> results of the discussion?
>> On May 7 2018, at 11:00 am, Vladimir Ozerov  wrote:
>> >
>> > Dmitry,
>> > Agree, mixed style when some arguments share the same line and others
>> don't
>> > looks very bad. My proposal was to allow two styles - first when all
>> > arguments are on the same line splitted by 120 char limit, second when
>> all
>> > every arguments is on a separate line.
>> > Mixed style should be disallowed.
>> >
>> > On Mon, May 7, 2018 at 12:35 AM, Dmitriy Govorukhin <
>> > dmitriy.govoruk...@gmail.com> wrote:
>> >
>> > > Vladimir,
>> > > My eyes cry when I see this
>> > > public double getCost(Session ses, int[] masks, TableFilter[] filters,
>> > > int filter, SortOrder sortOrder,
>> > > HashSet cols) {
>> > > return SpatialTreeIndex.getCostRangeIndex(masks,table.
>> > > getRowCountApproximation(),
>> > > columns) / 10;
>> > > }
>> > >
>> > > Why did arguments split into 3 line?
>> > > It is much better readable for me
>> > > public double getCost(
>> > > Session ses,
>> > > int[] masks,
>> > > TableFilter[] filters,
>> > > int filter,
>> > > SortOrder sortOrder,
>> > > HashSet cols
>> > > ) {
>> > > return SpatialTreeIndex.getCostRangeIndex(masks,
>> > > able.getRowCountApproximation(),
>> > > columns) / 10;
>> > > }
>> > >
>> > > Do we have a serious reason to continue writing code as before?
>> > >
>> > >
>> > > On Thu, May 3, 2018 at 2:24 PM, Vladimir Ozerov > >
>> > > wrote:
>> > >
>> > > > My opinion is that we should allow both styles and not enforce any
>> of
>> > > them.
>> > > > I hardly can say that this
>> > > >
>> > > > public double getCost(
>> > > > Session ses,
>> > > > int[] masks,
>> > > > TableFilter[] filters,
>> > > > int filter,
>> > > > SortOrder sortOrder,
>> > > > HashSet cols
>> > > > ) {
>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
>> > > > table.getRowCountApproximation(), columns) / 10;
>> > > > }
>> > > >
>> > > > is better than this
>> > > > public double getCost(Session ses, int[] masks, TableFilter[]
>> filters,
>> > > > int filter, SortOrder sortOrder,
>> > > > HashSet cols) {
>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
>> > > > table.getRowCountApproximation(), columns) / 10;
>> > > > }
>> > > >
>> > > >
>> > > > But this
>> > > > public CacheLockCandidates doneRemote(
>> > > > GridCacheVersion ver,
>> > > > Collection pending,
>> > > > Collection committed,
>> > > > Collection rolledback
>> > > > )
>> > > >
>> > > >
>> > > > looks better than this
>> > > > public CacheLockCandidates doneRemote(GridCacheVersion ver,
>> > > > Collection pending,
>> > > > Collection committed,
>> > > > Collection rolledback)
>> > > >
>> > > >
>> > > > The very problem is that our eyes feel comfortable when we either
>> move
>> > > them
>> > > > horizontally, or vertically (example 2). But with proposed code
>> style you
>> > > > have to do zigzag movements in general case because lines are not
>> aligned
>> > > > (example 1).
>> > > > Merge conflicts on multiliners are hardly of major concern for us.
>> > > >
>> > > > Vladimir.
>> > > > On Thu, May 3, 2018 at 1:46 PM, Eduard Shangareev <
>> > > > eduard.shangar...@gmail.com> wrote:
>> > > >
>> > > > > Alexey,
>> > > > > +1.
>> > > > > I personally also follow this style.
>> > > > > On Thu, May 3, 2018 at 12:45 PM, Alexey Goncharuk <
>> > > > > alexey.goncha...@gmail.com> wrote:
>> > > > >
>> > > > > > Actually, I've been following the suggested code style for
>> quite a
>> > > > while.
>> > > > > > I'm ok to add this to coding guidelines, however, I think we
>> should
>> > > > >
>> > > >
>> > > > allow
>> > > > > > the old style when the method signature (without throws clause)
>> fits
>> > > > >
>> > > >
>> > > > the
>> > > > > > line.
>> > > > > >
>> > > > > > Thoughts?
>> > > > > > 2018-05-03 12:09 GMT+03:00 Dmitry Pavlov > >:
>> > > > > > > Hi Dmitriy,
>> > > > > > > I like your proposal, so +1 from me.
>> > > > > > > I think it would make code more readable and easy to
>> understand.
>> > > > > > > Sincerely,
>> > > > > > > Dmitriy Pavlov
>> > > > > > >
>> > > > > > > чт, 3 мая 2018 г. в 11:31, Dmitriy Govorukhin <
>> > > > > > > dmitriy.govoruk...@gmail.com
>> > > > > > > > :
>> > > > > > >
>> > > > > > >
>> > > > > > > > Hi folks,
>> > > > > > > > I read

Re: method arguments code style

[Dmitry Pavlov]

I thought that Vladimir will update.

By the way, Denis M, I propose to grant access to the wiki to Dmitry G.
WDYT?

вт, 8 мая 2018 г. в 19:28, Dmitriy Govorukhin :

> Dmitriy,
>
> Сould you please update code style wiki page in accordance with the
> results of the discussion?
> On May 7 2018, at 11:00 am, Vladimir Ozerov  wrote:
> >
> > Dmitry,
> > Agree, mixed style when some arguments share the same line and others
> don't
> > looks very bad. My proposal was to allow two styles - first when all
> > arguments are on the same line splitted by 120 char limit, second when
> all
> > every arguments is on a separate line.
> > Mixed style should be disallowed.
> >
> > On Mon, May 7, 2018 at 12:35 AM, Dmitriy Govorukhin <
> > dmitriy.govoruk...@gmail.com> wrote:
> >
> > > Vladimir,
> > > My eyes cry when I see this
> > > public double getCost(Session ses, int[] masks, TableFilter[] filters,
> > > int filter, SortOrder sortOrder,
> > > HashSet cols) {
> > > return SpatialTreeIndex.getCostRangeIndex(masks,table.
> > > getRowCountApproximation(),
> > > columns) / 10;
> > > }
> > >
> > > Why did arguments split into 3 line?
> > > It is much better readable for me
> > > public double getCost(
> > > Session ses,
> > > int[] masks,
> > > TableFilter[] filters,
> > > int filter,
> > > SortOrder sortOrder,
> > > HashSet cols
> > > ) {
> > > return SpatialTreeIndex.getCostRangeIndex(masks,
> > > able.getRowCountApproximation(),
> > > columns) / 10;
> > > }
> > >
> > > Do we have a serious reason to continue writing code as before?
> > >
> > >
> > > On Thu, May 3, 2018 at 2:24 PM, Vladimir Ozerov 
> > > wrote:
> > >
> > > > My opinion is that we should allow both styles and not enforce any of
> > > them.
> > > > I hardly can say that this
> > > >
> > > > public double getCost(
> > > > Session ses,
> > > > int[] masks,
> > > > TableFilter[] filters,
> > > > int filter,
> > > > SortOrder sortOrder,
> > > > HashSet cols
> > > > ) {
> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
> > > > table.getRowCountApproximation(), columns) / 10;
> > > > }
> > > >
> > > > is better than this
> > > > public double getCost(Session ses, int[] masks, TableFilter[]
> filters,
> > > > int filter, SortOrder sortOrder,
> > > > HashSet cols) {
> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
> > > > table.getRowCountApproximation(), columns) / 10;
> > > > }
> > > >
> > > >
> > > > But this
> > > > public CacheLockCandidates doneRemote(
> > > > GridCacheVersion ver,
> > > > Collection pending,
> > > > Collection committed,
> > > > Collection rolledback
> > > > )
> > > >
> > > >
> > > > looks better than this
> > > > public CacheLockCandidates doneRemote(GridCacheVersion ver,
> > > > Collection pending,
> > > > Collection committed,
> > > > Collection rolledback)
> > > >
> > > >
> > > > The very problem is that our eyes feel comfortable when we either
> move
> > > them
> > > > horizontally, or vertically (example 2). But with proposed code
> style you
> > > > have to do zigzag movements in general case because lines are not
> aligned
> > > > (example 1).
> > > > Merge conflicts on multiliners are hardly of major concern for us.
> > > >
> > > > Vladimir.
> > > > On Thu, May 3, 2018 at 1:46 PM, Eduard Shangareev <
> > > > eduard.shangar...@gmail.com> wrote:
> > > >
> > > > > Alexey,
> > > > > +1.
> > > > > I personally also follow this style.
> > > > > On Thu, May 3, 2018 at 12:45 PM, Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com> wrote:
> > > > >
> > > > > > Actually, I've been following the suggested code style for quite
> a
> > > > while.
> > > > > > I'm ok to add this to coding guidelines, however, I think we
> should
> > > > >
> > > >
> > > > allow
> > > > > > the old style when the method signature (without throws clause)
> fits
> > > > >
> > > >
> > > > the
> > > > > > line.
> > > > > >
> > > > > > Thoughts?
> > > > > > 2018-05-03 12:09 GMT+03:00 Dmitry Pavlov  >:
> > > > > > > Hi Dmitriy,
> > > > > > > I like your proposal, so +1 from me.
> > > > > > > I think it would make code more readable and easy to
> understand.
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > чт, 3 мая 2018 г. в 11:31, Dmitriy Govorukhin <
> > > > > > > dmitriy.govoruk...@gmail.com
> > > > > > > > :
> > > > > > >
> > > > > > >
> > > > > > > > Hi folks,
> > > > > > > > I read
> > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > Coding+Guidelines
> > > > > ,
> > > > > > > > but did not find anything about code style for method
> arguments.
> > > > > > > >
> > > > > > > > In many places in the code, I see different code style, this
> > > > creates
> > > > > > > > difficulties for reading.
> > > > > > > >
> > > > > > > > It seems to me an example below is rather difficult to
> perceive.
> > > > > > > > ```java
> > > > > > > > public void foo(Object 

Re: IGNITE-3999 review

[Dmitry Pavlov]

Hi Amir,

I've updated How To Contribute (
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute )
section 'beginning work':

(OPTIONAL) It is recommended to clarify the relevance and correctness of
the ticket in the community before doing actual implementation. To do this,
you can write a letter to the dev.list  and wait
for answer.

This article has one note in 'tickets' section related to dev list:
"... unassigned
and unscheduled tickets after discussion on project's dev list. " ,- but it
is not so obivious that it is good practice.

I've used optional because some of contributors can be quite sure ticket is
actual, so I think it is not required to mandate everyone to start
discussion.

Sincerely,
Dmitriy Pavlov

вт, 8 мая 2018 г. в 19:43, Amir Akhmedov :

> Hi All,
> It's definitely my bad, I had to synch up with community on ticket's
> relevance.
> Would be nice for future contributors to mention "do get updates on
> ticket's relevance for outdated tickets" in Ignite's "How to contribute"
> webpage.
>
> Thanks,
> Amir
>
> On Tue, May 8, 2018 at 8:39 AM, Dmitriy Setrakyan 
> wrote:
>
> > Igniters, let's make sure we add ticket description to the email subject
> in
> > future, so the community will know what the ticket is about. Not everyone
> > has time to look for the ticket, especially when the link is not even
> > provided in the email.
> >
> > For example, the subject of this thread should have been: "IGNITE-3999:
> > Support case insensitive search in SQL"
> >
> > D.
> >
> > On Tue, May 8, 2018 at 2:28 PM, Dmitry Pavlov 
> > wrote:
> >
> > > Hi Vladimir, thank you for stepping in.
> > >
> > > This case confirms the usefulness of the practice of discussing the
> > problem
> > > at the devlist before implementation.
> > >
> > > вт, 8 мая 2018 г. в 10:12, Vladimir Ozerov :
> > >
> > > > Hi,
> > > >
> > > > I provided my comments in the ticket.
> > > >
> > > > On Tue, May 8, 2018 at 5:54 AM, Amir Akhmedov <
> amir.akhme...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Nikolay, Dmitry Pavlov,
> > > > > Can you take a look at this PR or maybe you have an idea when it
> > > probably
> > > > > can be reviewed?
> > > > >
> > > > > Thanks,
> > > > > Amir
> > > > >
> > > > > On Wed, Apr 11, 2018 at 10:57 AM, Nikolay Izhikov <
> > nizhi...@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hello, Amir.
> > > > > >
> > > > > > Sorry, but no.
> > > > > >
> > > > > > I will take a look in a next few days.
> > > > > >
> > > > > >
> > > > > > В Ср, 11/04/2018 в 14:51 +, Amir Akhmedov пишет:
> > > > > > > Hi Nikolay,
> > > > > > >
> > > > > > > Did you have a chance to check my changes?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Amir
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-8458) AffinityAssigment absorbs a lot of java heap

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8458:
-

 Summary: AffinityAssigment absorbs a lot of java heap
 Key: IGNITE-8458
 URL: https://issues.apache.org/jira/browse/IGNITE-8458
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


For the more hundred caches and several thousand partitions the size can grow 
out of 10 Gb.
In my case heap stored ~5К {{HistoryAffinityAssigment}}



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

[jira] [Created] (IGNITE-8457) Typo in MarshallerUtils.jdkMarshaller() method

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8457:


 Summary: Typo in MarshallerUtils.jdkMarshaller() method
 Key: IGNITE-8457
 URL: https://issues.apache.org/jira/browse/IGNITE-8457
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.6


{code}

public static JdkMarshaller jdkMarshaller(@Nullable String nodeName) {
 JdkMarshaller marsh = new JdkMarshaller();

 setNodeName(new JdkMarshaller(), nodeName); // <<< BUG !!! 

 return marsh;
}

{code}



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

Re: Service grid redesign

[Denis Mekhanikov]

Hi Vyacheslav!

Thanks for the enthusiasm!
The first ticket to be implemented here is IGNITE-8361
.
I think, until this one is resolved, other tasks can't be started.

Please assign it to yourself, if you feel confident enough.
Feel free to ask for any help, if you need.

For now it will be enough to perform service deployment and initialization
in the discovery thread.
Making it asynchronous will be our next step: IGNITE-8362


Denis

вт, 24 апр. 2018 г. в 15:43, Vyacheslav Daradur :

> Hi, Denis M.,
>
> I'd like to pick up a ticket from IEP-17 next week.
>
> Could you please advise a ticket to start?
>
> On Tue, Apr 24, 2018 at 11:47 AM, Dmitriy Setrakyan
>  wrote:
> > On Tue, Apr 24, 2018, 3:59 PM Denis Mekhanikov 
> > wrote:
> >
> >> Dmitriy,
> >>
> >> After the proposed changes are made the utility cache won't be needed at
> >> all.
> >>
> >
> > I was rather talking about prioritization. In my view, first and foremost
> > we must fix deployment before anything else.
> >
> > D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

[GitHub] ignite pull request #3966: IGNITE-8452: ML module compilation failure under ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: IGNITE-3999 review

[Amir Akhmedov]

Hi All,
It's definitely my bad, I had to synch up with community on ticket's
relevance.
Would be nice for future contributors to mention "do get updates on
ticket's relevance for outdated tickets" in Ignite's "How to contribute"
webpage.

Thanks,
Amir

On Tue, May 8, 2018 at 8:39 AM, Dmitriy Setrakyan 
wrote:

> Igniters, let's make sure we add ticket description to the email subject in
> future, so the community will know what the ticket is about. Not everyone
> has time to look for the ticket, especially when the link is not even
> provided in the email.
>
> For example, the subject of this thread should have been: "IGNITE-3999:
> Support case insensitive search in SQL"
>
> D.
>
> On Tue, May 8, 2018 at 2:28 PM, Dmitry Pavlov 
> wrote:
>
> > Hi Vladimir, thank you for stepping in.
> >
> > This case confirms the usefulness of the practice of discussing the
> problem
> > at the devlist before implementation.
> >
> > вт, 8 мая 2018 г. в 10:12, Vladimir Ozerov :
> >
> > > Hi,
> > >
> > > I provided my comments in the ticket.
> > >
> > > On Tue, May 8, 2018 at 5:54 AM, Amir Akhmedov  >
> > > wrote:
> > >
> > > > Hi Nikolay, Dmitry Pavlov,
> > > > Can you take a look at this PR or maybe you have an idea when it
> > probably
> > > > can be reviewed?
> > > >
> > > > Thanks,
> > > > Amir
> > > >
> > > > On Wed, Apr 11, 2018 at 10:57 AM, Nikolay Izhikov <
> nizhi...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Hello, Amir.
> > > > >
> > > > > Sorry, but no.
> > > > >
> > > > > I will take a look in a next few days.
> > > > >
> > > > >
> > > > > В Ср, 11/04/2018 в 14:51 +, Amir Akhmedov пишет:
> > > > > > Hi Nikolay,
> > > > > >
> > > > > > Did you have a chance to check my changes?
> > > > > >
> > > > > > Thanks,
> > > > > > Amir
> > > > >
> > > >
> > >
> >
>

Re: Optimize GridLongList serialization

[Dmitry Pavlov]

Hi Alexander,

Would new implementation of GridLongList be able to read value serialized
by old implementation?

Is it possible old implementation would not be able to read value from new?

Sincerely,
Dmitriy Pavlov

пн, 7 мая 2018 г. в 11:30, Александр Меньшиков :

> Hi.
> I have finished this task. Just replaced
>
> `writer.writeLongArray("arr", arr)`
> with
> `writer.writeLongArray("arr", arr, idx)`
>
> Please review and merge if okay.
>
> Jira: https://issues.apache.org/jira/browse/IGNITE-8054
> PR: https://github.com/apache/ignite/pull/3748
> CI:
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F3748%2Fhead=buildTypeStatusDiv
>
> 2018-03-27 11:50 GMT+03:00 Александр Меньшиков :
>
>> The ticket is created:
>> https://issues.apache.org/jira/browse/IGNITE-8054
>>
>> 2018-03-27 10:04 GMT+03:00 Dmitriy Setrakyan :
>>
>>> Sorry, Dmitiry, I meant Ignite, not GridGain (memories of pre-apache
>>> coding). I am assuming that Alex Menshikov was referring to GridLongList
>>> class in Ignite.
>>>
>>> D.
>>>
>>> On Mon, Mar 26, 2018 at 11:52 PM, Dmitry Pavlov 
>>> wrote:
>>>
>>> > Hi Dmitriy, did you mean GridList?
>>> >
>>> > I don't understand what does it mean GridGain compress.
>>> >
>>> > вт, 27 мар. 2018 г. в 3:06, Dmitriy Setrakyan :
>>> >
>>> > > Thanks, Alex.
>>> > >
>>> > > GridGain automatically compresses all the internal types. Somehow it
>>> > looks
>>> > > like the GridLongList may have been mixed. Can you please file a
>>> ticket
>>> > for
>>> > > 2.5 release?
>>> > >
>>> > > D.
>>> > >
>>> > > On Mon, Mar 26, 2018 at 4:55 AM, Александр Меньшиков <
>>> > sharple...@gmail.com
>>> > > >
>>> > > wrote:
>>> > >
>>> > > > I investigated network loading and found that a big part of
>>> internal
>>> > data
>>> > > > inside messages is `GridLongList`.
>>> > > > It is a part of `GridDhtTxFinishRequest`,
>>> > > > `GridDhtAtomicDeferredUpdateResponse`,
>>> `GridDhtAtomicUpdateRequest`,
>>> > > > `GridNearAtomicFullUpdateRequest` and `NearCacheUpdates`.
>>> > > >
>>> > > > So I think it has the sense to optimize `GridLongList`
>>> serialization.
>>> > > >
>>> > > >
>>> > > > Here we serialize all elements and don't take into account `idx`
>>> value:
>>> > > >
>>> > > > ```
>>> > > >
>>> > > > @Override public boolean writeTo(ByteBuffer buf, MessageWriter
>>> writer)
>>> > {
>>> > > >
>>> > > > writer.setBuffer(buf);
>>> > > >
>>> > > >
>>> > > >
>>> > > > if (!writer.isHeaderWritten()) {
>>> > > >
>>> > > > if (!writer.writeHeader(directType(), fieldsCount()))
>>> > > >
>>> > > > return false;
>>> > > >
>>> > > >
>>> > > >
>>> > > > writer.onHeaderWritten();
>>> > > >
>>> > > > }
>>> > > >
>>> > > >
>>> > > >
>>> > > > switch (writer.state()) {
>>> > > >
>>> > > > case 0:
>>> > > >
>>> > > > if (!writer.writeLongArray("arr", arr))
>>> > > >
>>> > > > return false;
>>> > > >
>>> > > >
>>> > > >
>>> > > > writer.incrementState();
>>> > > >
>>> > > >
>>> > > >
>>> > > > case 1:
>>> > > >
>>> > > > if (!writer.writeInt("idx", idx))
>>> > > >
>>> > > > return false;
>>> > > >
>>> > > >
>>> > > >
>>> > > > writer.incrementState();
>>> > > >
>>> > > >
>>> > > >
>>> > > > }
>>> > > >
>>> > > >
>>> > > >
>>> > > > return true;
>>> > > >
>>> > > > }
>>> > > >
>>> > > > ```
>>> > > >
>>> > > >
>>> > > >
>>> > > > Which is not happening in another serialization method in the same
>>> > class:
>>> > > >
>>> > > >
>>> > > >
>>> > > > ```
>>> > > >
>>> > > > public static void writeTo(DataOutput out, @Nullable GridLongList
>>> list)
>>> > > > throws IOException {
>>> > > >
>>> > > > out.writeInt(list != null ? list.idx : -1);
>>> > > >
>>> > > >
>>> > > >
>>> > > > if (list != null) {
>>> > > >
>>> > > > for (int i = 0; i < list.idx; i++)
>>> > > >
>>> > > > out.writeLong(list.arr[i]);
>>> > > >
>>> > > > }
>>> > > >
>>> > > > }
>>> > > >
>>> > > > ```
>>> > > >
>>> > > >
>>> > > > So, we can simply reduce messages size by sending only a valuable
>>> part
>>> > of
>>> > > > the array.
>>> > > > If you don't mind I will create an issue in Jira for this.
>>> > > >
>>> > > >
>>> > > > By the way, `long` is a huge type. As I see in most cases
>>> > `GridLongList`
>>> > > > uses for counters.
>>> > > > And I have checked the possibility of compress `long` into smaller
>>> > types
>>> > > as
>>> > > > `int`, `short` or `byte` in test
>>> > > > `GridCacheInterceptorAtomicRebalanceTest` (took it by random).
>>> > > > And found out that all `long` in`GridLongList` can be cast to
>>> `int` and
>>> > > 70%
>>> > > > of them to shorts.
>>> > > > Such conversion is quite fast about 1.1 (ns) per 

Re: IGNITE_HOME for persistence

[Dmitry Pavlov]

Hi Dmitriy, Igniters,

I've created https://issues.apache.org/jira/browse/IGNITE-8456

I hope that someone in community can pick up this ticket. I've marked
ticket as newbie.

Sincerely,
Dmitriy Pavlov

ср, 14 мар. 2018 г. в 2:12, Dmitriy Setrakyan :

> On Tue, Mar 13, 2018 at 7:01 PM, Dmitry Pavlov 
> wrote:
>
> > Hi,
> >
> > do we have a task to print this warning message?
> >
> > It seems we don't print warning currently.
> >
>
> I do not think we have a ticket. As AG mentioned, this is an issue for
> cases when persistence is disabled as well. Dmitriy, do you mind creating
> one and assigning it to 2.5 release?
>

Re: method arguments code style

[Dmitriy Govorukhin]

Dmitriy,

Сould you please update code style wiki page in accordance with the results of 
the discussion?
On May 7 2018, at 11:00 am, Vladimir Ozerov  wrote:
>
> Dmitry,
> Agree, mixed style when some arguments share the same line and others don't
> looks very bad. My proposal was to allow two styles - first when all
> arguments are on the same line splitted by 120 char limit, second when all
> every arguments is on a separate line.
> Mixed style should be disallowed.
>
> On Mon, May 7, 2018 at 12:35 AM, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com> wrote:
>
> > Vladimir,
> > My eyes cry when I see this
> > public double getCost(Session ses, int[] masks, TableFilter[] filters,
> > int filter, SortOrder sortOrder,
> > HashSet cols) {
> > return SpatialTreeIndex.getCostRangeIndex(masks,table.
> > getRowCountApproximation(),
> > columns) / 10;
> > }
> >
> > Why did arguments split into 3 line?
> > It is much better readable for me
> > public double getCost(
> > Session ses,
> > int[] masks,
> > TableFilter[] filters,
> > int filter,
> > SortOrder sortOrder,
> > HashSet cols
> > ) {
> > return SpatialTreeIndex.getCostRangeIndex(masks,
> > able.getRowCountApproximation(),
> > columns) / 10;
> > }
> >
> > Do we have a serious reason to continue writing code as before?
> >
> >
> > On Thu, May 3, 2018 at 2:24 PM, Vladimir Ozerov 
> > wrote:
> >
> > > My opinion is that we should allow both styles and not enforce any of
> > them.
> > > I hardly can say that this
> > >
> > > public double getCost(
> > > Session ses,
> > > int[] masks,
> > > TableFilter[] filters,
> > > int filter,
> > > SortOrder sortOrder,
> > > HashSet cols
> > > ) {
> > > return SpatialTreeIndex.getCostRangeIndex(masks,
> > > table.getRowCountApproximation(), columns) / 10;
> > > }
> > >
> > > is better than this
> > > public double getCost(Session ses, int[] masks, TableFilter[] filters,
> > > int filter, SortOrder sortOrder,
> > > HashSet cols) {
> > > return SpatialTreeIndex.getCostRangeIndex(masks,
> > > table.getRowCountApproximation(), columns) / 10;
> > > }
> > >
> > >
> > > But this
> > > public CacheLockCandidates doneRemote(
> > > GridCacheVersion ver,
> > > Collection pending,
> > > Collection committed,
> > > Collection rolledback
> > > )
> > >
> > >
> > > looks better than this
> > > public CacheLockCandidates doneRemote(GridCacheVersion ver,
> > > Collection pending,
> > > Collection committed,
> > > Collection rolledback)
> > >
> > >
> > > The very problem is that our eyes feel comfortable when we either move
> > them
> > > horizontally, or vertically (example 2). But with proposed code style you
> > > have to do zigzag movements in general case because lines are not aligned
> > > (example 1).
> > > Merge conflicts on multiliners are hardly of major concern for us.
> > >
> > > Vladimir.
> > > On Thu, May 3, 2018 at 1:46 PM, Eduard Shangareev <
> > > eduard.shangar...@gmail.com> wrote:
> > >
> > > > Alexey,
> > > > +1.
> > > > I personally also follow this style.
> > > > On Thu, May 3, 2018 at 12:45 PM, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com> wrote:
> > > >
> > > > > Actually, I've been following the suggested code style for quite a
> > > while.
> > > > > I'm ok to add this to coding guidelines, however, I think we should
> > > >
> > >
> > > allow
> > > > > the old style when the method signature (without throws clause) fits
> > > >
> > >
> > > the
> > > > > line.
> > > > >
> > > > > Thoughts?
> > > > > 2018-05-03 12:09 GMT+03:00 Dmitry Pavlov :
> > > > > > Hi Dmitriy,
> > > > > > I like your proposal, so +1 from me.
> > > > > > I think it would make code more readable and easy to understand.
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > чт, 3 мая 2018 г. в 11:31, Dmitriy Govorukhin <
> > > > > > dmitriy.govoruk...@gmail.com
> > > > > > > :
> > > > > >
> > > > > >
> > > > > > > Hi folks,
> > > > > > > I read
> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/
> > > > > >
> > > > >
> > > >
> > >
> > > Coding+Guidelines
> > > > ,
> > > > > > > but did not find anything about code style for method arguments.
> > > > > > >
> > > > > > > In many places in the code, I see different code style, this
> > > creates
> > > > > > > difficulties for reading.
> > > > > > >
> > > > > > > It seems to me an example below is rather difficult to perceive.
> > > > > > > ```java
> > > > > > > public void foo(Object obj1,
> > > > > > > Object obj2, Object obj3,... ,Object objN){
> > > > > > > 
> > > > > > > }
> > > > > > > ```
> > > > > > > An example GridCacheProcessor.addCacheOnJoin(...)
> > > > > > >
> > > > > > > ```java
> > > > > > > private void addCacheOnJoin(CacheConfiguration cfg,
> > > > > >
> > > > >
> > > >
> > > > boolean
> > > > > > sql,
> > > > > > > Map caches,
> > > > > > > Map templates)
> > > > > > > ```
> > > > > > > I suggest two options for writing arguments.
> 

[jira] [Created] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8456:
--

 Summary: Print warning if IGNITE_HOME & WORK and 
persistentStoreDir is not set, but persistence enabled
 Key: IGNITE-8456
 URL: https://issues.apache.org/jira/browse/IGNITE-8456
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Reporter: Dmitriy Pavlov
 Fix For: 2.6


In method org.apache.ignite.internal.util.IgniteUtils#workDirectory

Ignite determine Work dir to be set, same value may be used in case persistence 
Store Folder is not set and IGNITE_HOME is not specified.

In case work dir is not specified, temp directory is used for Ignite Work. But 
for persistence enabled case this means user DB goes to temp folder and may be 
removed later.

User may be confused by this behaviour. See:

[https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]

and related Dev.List discussion

[http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]

 



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

Re: missing website info

[Denis Magda]

Dmitriy,

Presently this information is scattered and presented under sections named
differently. Agree with the format proposed by you.
https://issues.apache.org/jira/browse/IGNITE-8455

In addition, we should cover another mode which is indexes in RAM and data
on disk to get a better technical cost of ownership of Ignite's cluster. I
heard it's already possible to set up this kind of configuration.

--
Denis

On Fri, May 4, 2018 at 6:01 PM, Dmitriy Setrakyan 
wrote:

> I have been going through the Ignite website today, and I have noticed that
> nowhere on the website we mention various modes on how Ignite native
> persistence can be used:
>
> - no disk, data is in memory-only (potentially over a 3rd-party database)
> - disk is a copy of the memory (only for recovery purposes)
> - disk is a data storage with memory used as a performant caching layer
>
> I believe we should put it in a table and explain it somewhere (homepage?).
>
> Denis, Prachi, what do you think?
>
> D.
>

[jira] [Created] (IGNITE-8455) Cover main Ignite memory modes

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8455:
---

 Summary: Cover main Ignite memory modes
 Key: IGNITE-8455
 URL: https://issues.apache.org/jira/browse/IGNITE-8455
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.6


Ignite website doesn't mention various modes on how Ignite native persistence 
can be used:

- no disk, data is in memory-only (potentially over a 3rd-party database)
- disk is a copy of the memory (only for recovery purposes)
- disk is a data storage with memory used as a performant caching layer
- indexes in memory and data on disk for better technical cost of ownership.

I believe we should put it in a table and explain it on the memory-centric page.

More details: 
http://apache-ignite-developers.2346864.n4.nabble.com/missing-website-info-td30145.html




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

[GitHub] ignite pull request #3966: IGNITE-8452: ML module compilation failure under ...

[ybabak]

GitHub user ybabak opened a pull request:

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

IGNITE-8452: ML module compilation failure under Java 9

fixed

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

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

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

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


commit 10011cceda916df52afb073821337acf706c4e1f
Author: YuriBabak 
Date:   2018-05-08T16:16:33Z

IGNITE-8452: ML module compilation failure under Java 9

fixed




---

Re: Migration guide

[Denis Magda]

Vladimir,

Here is you can find a short summary on the planned migration:
https://issues.apache.org/jira/browse/IGNITE-7595

This discussion goes with more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html

--
Denis

On Mon, May 7, 2018 at 12:22 PM, Vladimir Ozerov 
wrote:

> Denis,
>
> Sounds good. Could you please share more info about new engine?
>
> пн, 7 мая 2018 г. в 21:00, Denis Magda :
>
> > Guys,
> >
> > It's planned to migrate to new documentation engine within 2.6 timeframe,
> > thus, I would suggest us storing migration guides in Github (together
> with
> > doc sources) and publish as a part of the docs on Ignite web site.
> >
> > What do you think about this approach?
> >
> > -
> > Denis
> >
> > On Mon, May 7, 2018 at 6:20 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Igor,
> > >
> > > WIKI is the way to go. In addition we are discussing ticket review
> > > guidelines in separate thread at the moment. May be we will be able to
> > > include Migration Guide update there as well.
> > >
> > > On Mon, May 7, 2018 at 3:46 PM, Igor Sapego 
> wrote:
> > >
> > > > Looks like a good idea to me.
> > > >
> > > > But I believe, if we decide to adopt this idea, then we
> > > > need to think how to enforce adding notes to migration
> > > > guide.
> > > >
> > > > The only way I can currently think of is a pretty obvious
> > > > one - adding corresponding instructions to a wiki [1].
> > > >
> > > > Is there anything else we can do here?
> > > >
> > > > [1] - https://cwiki.apache.org/confluence/display/IGNITE/How+
> > > to+Contribute
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Mon, May 7, 2018 at 11:22 AM, Vladimir Ozerov <
> voze...@gridgain.com
> > >
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > We try to maintain API compatibility and keep default behavior
> > > unchanged
> > > > > between minor releases. But as product evolves, some APIs become
> > > > > deprecated, new best practices appear, and some defaults are
> changed.
> > > > >
> > > > > We had a talk with Andrey Gura and he suggested to add *"Migration
> > > > Guide"*
> > > > > to our release cycle. This is a document where we will list all
> > > important
> > > > > changes since the last version and our recommendations how to use
> > them.
> > > > If
> > > > > done properly this should speedup adoption of new features and
> > > migration
> > > > to
> > > > > newer versions.
> > > > >
> > > > > Here are several examples from other vendors:
> > > > > 1) Hibernate -
> > > > >
> > https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2
> > > > > 2) Play - https://www.playframework.com/documentation/2.6.x/
> > > Migration26
> > > > >
> > > > > I propose to start creating migration guides since the next
> release,
> > > > Apache
> > > > > Ignite 2.6.
> > > > >
> > > > > For now let's decide whether community supports this idea, and if
> > yes -
> > > > how
> > > > > to publish it. I would propose to do it as follows:
> > > > > 1) Add MIGRATION_GUIDE document next to RELEASE_NOTES. This
> document
> > > > should
> > > > > be updated by contributors during development.
> > > > > 2) After release: publish separate page next to release notes [1]
> > > > > 3) Add links to migration guide to download page [2]
> > > > >
> > > > > Please share your thoughts.
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > [1] https://ignite.apache.org/releases/2.4.0/release_notes.html
> > > > > [2] https://ignite.apache.org/download.cgi
> > > > >
> > > >
> > >
> >
>

Re: Apache Ignite 2.5 release

[Andrey Gura]

Thanks for fast update, Ivan.

On Tue, May 8, 2018 at 5:59 PM, Ivan Rakov  wrote:
> Andrey,
>
> Sorry to disturb you again. I have a follow up fix for IGNITE-8429 -
> https://issues.apache.org/jira/browse/IGNITE-8453.
> Please merge it to master and ignite-2.5.
>
> Best Regards,
> Ivan Rakov
>
>
> On 08.05.2018 15:29, Vladimir Ozerov wrote:
>>
>> H2 version updated is moved to AI 2.6. There are several serious problems,
>> main - spatial dependency replacement which is a breaking change.
>>
>> On Tue, May 8, 2018 at 10:17 AM, Pavel Tupitsyn 
>> wrote:
>>
>>> IGNITE-8434 merged to master, cherry-picked to ignite-2.5.
>>>
>>> Thank you, Andrey!
>>>
>>> On Mon, May 7, 2018 at 10:46 PM, Andrey Gura  wrote:
>>>
 Pavel,

 issue is targeted to release 2.5 now. Thanks!

 On Mon, May 7, 2018 at 10:40 PM, Pavel Tupitsyn 
 wrote:
>
> Igniters,
>
> There is an unpleasant bug in .NET [1]:
> Services do not work at all on .NET Core and sometimes on classic .NET.
>
> I'm almost done with the fix and I think we should include it in 2.5.

 Users
>
> are complaining [2].
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8434
> [2]
> http://apache-ignite-users.70518.x6.nabble.com/Re-

 Service-Grid-and-net-core-2-td21318.html
>
> On Mon, May 7, 2018 at 6:44 PM, Vladimir Ozerov 
> wrote:
>
>> Andrey,
>>
>> I realized that we missed one very important thing - H2 version
>>>
>>> upgrade
>>
>> [1]. This is very important thing because new version contain

 optimization
>>
>> to IN clause processing. All we need is to upgrade H2 vesion from

 1.4.196
>>
>> to 1.4.197 and re-run tests. Can we target it to 2.5 release?
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-4150
>>
>> On Mon, May 7, 2018 at 6:07 PM, Andrey Gura  wrote:
>>
>>> Ivan,
>>>
>>> ok, targeted to 2.5. Thanks!
>>>
>>> On Mon, May 7, 2018 at 5:24 PM, Dmitry Pavlov <
>>>
>>> dpavlov@gmail.com>
>>>
>>> wrote:

 Thank you, Andrey,

 I saw 1 more proposal in separate topic
 http://apache-ignite-developers.2346864.n4.nabble.
>>>
>>> com/RE-Hi-can-we-squeeze-this-into-2-5-https-issues-apache-
>>> org-jira-browse-IGNITE-8439-td30161.html

 and 1 proposal here related to ML:
 http://apache-ignite-developers.2346864.n4.nabble.
>>>
>>> com/Apache-Ignite-2-5-release-td28927i20.html#a30155

 but here Yuriy Babak probably should share his opinion.

 Sincerely,
 Dmitriy Pavlov

 пн, 7 мая 2018 г. в 17:09, Andrey Gura :
>
> Sergey, Dmitry,
>
> I've targeted your issues to 2.5 release.
>
> Thanks!
>
> On Fri, May 4, 2018 at 5:51 PM, Dmitry Pavlov <

 dpavlov@gmail.com>
>
> wrote:
>>
>> I did not understand process.
>>
>> Is it required to receive someone reply that issue is agreed to

 be
>>
>> included
>> into release?
>>
>> Or because there is no response I can cherry-pick anything to
>>>
>>> 2.5
>>>
>>> hoping
>>
>> it
>> is lazy consensus; no one objected.
>>
>> пт, 4 мая 2018 г. в 17:44, Denis Magda :
>>
>>> Igniters,
>>>
>>> I got lost. Were all the bugs reported in this thread fixed
>>>
>>> and
>>>
>>> merged
>>>
>>> into
>>> 2.5 branch? Is there any bug which fix is still in progress?
>>>
>>> Just want to know when the QA and bugs fixing stage is over.
>>>
>>> --
>>> Denis
>>>
>>> On Thu, May 3, 2018 at 9:14 AM, Dmitry Pavlov <
>>
>> dpavlov@gmail.com
>>>
>>> wrote:
>>>
 Hi Andrey, Igniters,

 I propose to include
 https://issues.apache.org/jira/browse/IGNITE-8347
>>>
>>> fix

 to 2.5. It is quite isolated.

 Memory leak can be reproduced if node in embedded mode is
>>
>> restarted

 under
 the same process (thread is alive and cleanup is not

 performed).

 Sincerely,
 Dmitriy Pavlov

 сб, 28 апр. 2018 г. в 19:49, Sergey Chugunov
  Igniters,
>
> I would like to include into release another critical bug

 found
>>>
>>> in
>

Re: IGNITE-6879: Support Spring Data 2.0

[Dmitry Pavlov]

Hi Roman, Igniters,

I've merged these changes to master and it goes to 2.6.

Roman, thank you for contribution and your reminders about review.

Peter Ivanov, thank you for setting up tests.

Alexey Kukushkin, Dmitriy Ryabov, thank you for review.

Igniters, please note Spring Data suite may fail for PRs because
of ignite-spring-data_2.0 module is absent in these branches.

Sincerely,
Dmitriy Pavlov

вт, 8 мая 2018 г. в 15:55, Dmitry Pavlov :

> Hi Roman,
>
> now TC passes for 1.0. In the same time new suite is not executed on TC.
>
> I've asked Peter Ivanov to assist in TC run set up for Spring Data 2.0.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 7 мая 2018 г. в 18:23, Роман Меерсон :
>
>> Dmitry, I leave comment at issue. As i may see localy problem with tests
>> was fixed
>>
>> пн, 7 мая 2018 г. в 17:24, Dmitry Pavlov :
>>
>>> Hi, I've replied to ticket, seems old tests are now failing after
>>> applying patch locally.
>>>
>>> I've also added 2 suites to TC
>>> TEST_SUITE =IgniteSpringDataTestSuite,IgniteSpringData2TestSuite
>>> to
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SpringData
>>>
>>> so this suite will check both integrations. Ideally we could run this
>>> suite one more time before merge.
>>>
>>> Sincerely,
>>> Dmitriy Pavlov
>>>
>>> пн, 7 мая 2018 г. в 15:46, Dmitry Pavlov :
>>>
 Hi Roman,

 Currently I'm checking the changes. Because of applying idea to copy
 all changes and upsource problem with this branch it is quite complex to
 locate actual changes. It is now required to check all copied files before
 merge.

 Sincerely,
 Dmitriy Pavlov

 пн, 7 мая 2018 г. в 11:07, Роман Меерсон :

> Hello Dmitry!
>
> was review successfull? Or there are any points to change?
>
> сб, 28 апр. 2018 г. в 19:32, Роман Меерсон :
>
>> Ok! I believe in community and that things would change!
>> Looking forward for news
>> сб, 28 апр. 2018 г. в 19:29, Dmitry Pavlov :
>>
>>> I hope so!
>>>
>>> There was several posts related to review time, and AI community is
>>> now trying to reduce it. Now it is about 70 tickets waiting to be merged
>>> more than 1month. This defenetely should be changed. And I hope all 
>>> Ignite
>>> committers and maintainters would continue to assist in this.
>>>
>>> сб, 28 апр. 2018 г. в 18:24, Роман Меерсон :
>>>
 Hi all!

 Soon we'll celebrate 2 months of my PR :)
 Maybe it could be merged?
 пн, 23 апр. 2018 г. в 18:52, Dmitry Pavlov :

> No, nothing yet. I'm going to look to new version.
>
> пн, 23 апр. 2018 г. в 17:43, Роман Меерсон :
>
>> Hi all!
>>
>> Are there any news about PR merging?
>>
>> пн, 16 апр. 2018 г. в 19:43, Роман Меерсон > >:
>>
>>> Denis,
>>>
>>> module naming fixed
>>>
>>> пн, 16 апр. 2018 г. в 19:24, Denis Magda :
>>>
 Roman,

 In my last reply, I voted for your approach - using
 "spring-data*_*2.0" for
 the new Spring version. However, please note that we use "_"
 symbol instead
 of "-" to separate a version from the package name.

 --
 Denis

 On Sun, Apr 15, 2018 at 8:17 AM, Роман Меерсон <
 homich1...@gmail.com> wrote:

 > Hi all!
 >
 > So guys let’s make a decision. We leave code in current state
 as I suggest
 > or change module naming according Dmitry’s suggestion.
 > ср, 11 апр. 2018 г. в 1:54, Denis Magda :
 >
 > > Roman,
 > >
 > > Your suggestion sounds reasonable to me. Backing it up.
 > >
 > > --
 > > Denis
 > >
 > > On Tue, Apr 10, 2018 at 2:50 PM, Роман Меерсон <
 homich1...@gmail.com>
 > > wrote:
 > >
 > > > Hi all!
 > > >
 > > > IMHO if we do so we'll produce big pain for everybody
 while migrating
 > on
 > > > new version, because ones should change method and others
 should change
 > > > their poms. This change would be backward incompatible so
 it probably
 > > > should follow with major version upgrade, but I'm not
 sure about it.
 > > >
 > > > Otherwise if we leave current state( spring-data 

[GitHub] ignite pull request #3965: IGNITE-7912

[DmitriyGovorukhin]

GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-7912



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

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

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

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


commit 578a49689cefbcf94ab999c2837a5324fdd069c5
Author: Ivan Daschinskiy 
Date:   2018-03-14T17:43:34Z

IGNITE-7912 Add Visor WAL command to safely truncate WAL archives and
print list of files that is safe to truncate. Perform these task clusterwide
and per nodes that are specified.

commit 7b591d61c114ee24ef520480591ee1371d4f24ef
Author: Ivan Daschinskiy 
Date:   2018-03-20T16:46:36Z

IGNITE-7912 Rewrote code for preventing abstraction leaks, and added 
additional tests for CommandHandler.

commit 5f19e13b180ac346ad3d6886f7b37ad595c706dc
Author: Ivan Daschinskiy 
Date:   2018-03-21T10:35:27Z

IGNITE-7912 Merged with master and rewrote wal logic in CommandHandler 
according to new changes

commit 90daba6df7db6be0e42e07b20fa78bd4ce1c129e
Author: Ivan Daschinskiy 
Date:   2018-03-21T10:36:29Z

IGNITE-7912 Merged with master and rewrote wal logic in CommandHandler 
according to new changes

commit 4093e89e1c1fb58123db2b1a863c82e9e07bdbca
Author: Ivan Daschinskiy 
Date:   2018-03-23T14:03:36Z

Merge branch 'master' into ignite-7912

commit 680fe97ecb23bd13b4daa14d5723c112db5bc7fc
Author: Ivan Daschinskiy 
Date:   2018-03-23T14:04:43Z

IGNITE-7912 Merging master and revert GridDhtPartitionExchangeId

commit f3b46c1af07a73913dca2b0f9173fb23280d13f8
Author: Ivan Daschinskiy 
Date:   2018-03-31T09:13:11Z

IGNITE-7912 merge with master

commit 5478ca0454e83127f8a923e9e3da1e0bafb0424f
Author: Ivan Daschinskiy 
Date:   2018-04-03T08:33:21Z

IGNITE-7912 Simplified tests and corrected formatting issues

commit 012b9b43df19abe7a3e6c4cc7371cc506f29a93a
Author: Ivan Daschinskiy 
Date:   2018-04-04T13:12:41Z

IGNITE-7912 Code review reaction

commit 2c35061b2cba570d75231ae2addb6b1c6ef84ae8
Author: Ivan Daschinskiy 
Date:   2018-04-05T11:05:44Z

IGNITE-7912 Add test that checks whether reserved WAL segment
is not affected

commit 93014eea3402d216880c1f574285a53eb66999ab
Author: Ivan Daschinskiy 
Date:   2018-04-05T15:18:10Z

IGNITE-7912 Reworking test, part 1.

commit 0b94a1cdfc119577fe150a3d9094c897f9031537
Author: Ivan Daschinskiy 
Date:   2018-04-05T16:34:28Z

IGNITE-7912 Reworking test, part 2.

commit 4e09ed087b73e1887f49aa3242f64e1672c507e7
Author: Ivan Daschinskiy 
Date:   2018-04-06T14:57:16Z

IGNITE-7912 Small refactoring.

commit 4637e9f022af5c7fd101daf8c039d9f01d876988
Author: Ivan Daschinskiy 
Date:   2018-04-09T09:42:14Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-7912

commit be6dc1bcc256d7a94834f63873520103846d3797
Author: Ivan Daschinskiy 
Date:   2018-04-09T09:49:13Z

IGNITE-7912 Small refactoring.

commit f6e4206dc8dcef1792bf9e25c204f0ce9732c209
Author: Ivan Daschinskiy 
Date:   2018-04-12T10:44:12Z

Merge branch 'master' into ignite-7912

commit 12f89a6458228b7163a032177812d476473ee8d0
Author: Ivan Daschinskiy 
Date:   2018-04-12T11:22:52Z

IGNITE-7912 Introduce IGNITE_ENABLE_EXPERIMENTAL_COMMAND system property
to hide WAL command by default.

commit 10d1ff6f8fab3239706da15d2ea63e894cb24385
Author: Ivan Daschinskiy 
Date:   2018-05-02T11:41:37Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-7912

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/commandline/Arguments.java
#   
modules/core/src/main/java/org/apache/ignite/internal/commandline/Command.java
#   
modules/core/src/main/java/org/apache/ignite/internal/commandline/CommandHandler.java
#   
modules/core/src/test/java/org/apache/ignite/internal/commandline/CommandHandlerParsingTest.java
#   
modules/core/src/test/java/org/apache/ignite/util/GridCommandHandlerTest.java

commit 895bb93ca5365d8d54c15853b0a2fb92d888f2a1
Author: Ivan Daschinskiy 
Date:   2018-05-02T14:15:22Z

IGNITE-7912 wip.

commit c01ceddc697202e3c774383ac473db428015f838
Author: Ivan Daschinskiy 
Date:   2018-05-07T09:30:19Z

Merge remote-tracking branch 'origin/master' into ignite-7912

commit b19be66f9938fcc0314f3584cb8f5dd3071c6836
Author: Ivan Daschinskiy 
Date:   2018-05-07T09:42:44Z

IGNITE-7912 wip.

commit 

[GitHub] ignite pull request #3964: IGNITE-8443 Transaction hangs when some error occ...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8443 Transaction hangs when some error occurs during processig of 
GridNearLockRequest



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

$ git pull https://github.com/alex-plekhanov/ignite ignite-8443

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

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


commit 5e97fd54d3f37e2a49866931b71caac4ed462307
Author: Aleksey Plekhanov 
Date:   2018-05-08T15:36:32Z

IGNITE-8443 Transaction hangs when some error occurs during processing of 
GridNearLockRequest




---

[GitHub] ignite pull request #3963: IGNITE-8443 Transaction hangs when some error occ...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8443 Transaction hangs when some error occurs during processing of 
GridNearLockRequest (TC run)



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

$ git pull https://github.com/alex-plekhanov/ignite ignite-8443-debug

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

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


commit 5e97fd54d3f37e2a49866931b71caac4ed462307
Author: Aleksey Plekhanov 
Date:   2018-05-08T15:36:32Z

IGNITE-8443 Transaction hangs when some error occurs during processing of 
GridNearLockRequest

commit 4f4f2f588aa2b172d33d1efd1d9b77fcd3667bf7
Author: Aleksey Plekhanov 
Date:   2018-05-08T15:43:04Z

IGNITE-8443 TC run




---

[GitHub] ignite pull request #3704: IGNITE-6879 and migration to spring-data 2.0.5.RE...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8454) Hadoop module compilation failure under JDK9

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8454:


 Summary: Hadoop module compilation failure under JDK9
 Key: IGNITE-8454
 URL: https://issues.apache.org/jira/browse/IGNITE-8454
 Project: Ignite
  Issue Type: Task
Reporter: Peter Ivanov


Reproduced on Linux (Mac is OK)
{code}
[16:38:27][Step 4/5] [ERROR] Failed to execute goal on project ignite-hadoop: 
Could not resolve dependencies for project 
org.apache.ignite:ignite-hadoop:jar:2.5.0-SNAPSHOT: Could not find artifact 
jdk.tools:jdk.tools:jar:1.6 at specified path 
/usr/lib/jvm/java-9-oracle/../lib/tools.jar
{code}
Possibly relates to Scala 2.10-2.11: 
https://lists.apache.org/thread.html/%3caf9b21681d3ee94aa935901747be4b813a3b4...@shsmsx101.ccr.corp.intel.com%3E



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

[GitHub] ignite pull request #3962: IGNITE-8037 DynamicColumnsConcurrentTransactional...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-8037  
DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
 is flaky



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

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

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

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


commit 741e07220470190177cc1daa6668900295e3e0bb
Author: tledkov-gridgain 
Date:   2018-05-08T14:41:38Z

IGNITE-8037: holds H2 JDBC connection until node is stopped

commit 6d34a41fbb51c6c49f9a9e532cac712322ad06a5
Author: tledkov-gridgain 
Date:   2018-05-08T14:58:02Z

Merge branch '_master' into ignite-8037




---

Re: Apache Ignite 2.5 release

[Ivan Rakov]

Andrey,

Sorry to disturb you again. I have a follow up fix for IGNITE-8429 - 
https://issues.apache.org/jira/browse/IGNITE-8453.

Please merge it to master and ignite-2.5.

Best Regards,
Ivan Rakov

On 08.05.2018 15:29, Vladimir Ozerov wrote:

H2 version updated is moved to AI 2.6. There are several serious problems,
main - spatial dependency replacement which is a breaking change.

On Tue, May 8, 2018 at 10:17 AM, Pavel Tupitsyn 
wrote:


IGNITE-8434 merged to master, cherry-picked to ignite-2.5.

Thank you, Andrey!

On Mon, May 7, 2018 at 10:46 PM, Andrey Gura  wrote:


Pavel,

issue is targeted to release 2.5 now. Thanks!

On Mon, May 7, 2018 at 10:40 PM, Pavel Tupitsyn 
wrote:

Igniters,

There is an unpleasant bug in .NET [1]:
Services do not work at all on .NET Core and sometimes on classic .NET.

I'm almost done with the fix and I think we should include it in 2.5.

Users

are complaining [2].


[1] https://issues.apache.org/jira/browse/IGNITE-8434
[2]
http://apache-ignite-users.70518.x6.nabble.com/Re-

Service-Grid-and-net-core-2-td21318.html

On Mon, May 7, 2018 at 6:44 PM, Vladimir Ozerov 
wrote:


Andrey,

I realized that we missed one very important thing - H2 version

upgrade

[1]. This is very important thing because new version contain

optimization

to IN clause processing. All we need is to upgrade H2 vesion from

1.4.196

to 1.4.197 and re-run tests. Can we target it to 2.5 release?

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

On Mon, May 7, 2018 at 6:07 PM, Andrey Gura  wrote:


Ivan,

ok, targeted to 2.5. Thanks!

On Mon, May 7, 2018 at 5:24 PM, Dmitry Pavlov <

dpavlov@gmail.com>

wrote:

Thank you, Andrey,

I saw 1 more proposal in separate topic
http://apache-ignite-developers.2346864.n4.nabble.

com/RE-Hi-can-we-squeeze-this-into-2-5-https-issues-apache-
org-jira-browse-IGNITE-8439-td30161.html

and 1 proposal here related to ML:
http://apache-ignite-developers.2346864.n4.nabble.

com/Apache-Ignite-2-5-release-td28927i20.html#a30155

but here Yuriy Babak probably should share his opinion.

Sincerely,
Dmitriy Pavlov

пн, 7 мая 2018 г. в 17:09, Andrey Gura :

Sergey, Dmitry,

I've targeted your issues to 2.5 release.

Thanks!

On Fri, May 4, 2018 at 5:51 PM, Dmitry Pavlov <

dpavlov@gmail.com>

wrote:

I did not understand process.

Is it required to receive someone reply that issue is agreed to

be

included
into release?

Or because there is no response I can cherry-pick anything to

2.5

hoping

it
is lazy consensus; no one objected.

пт, 4 мая 2018 г. в 17:44, Denis Magda :


Igniters,

I got lost. Were all the bugs reported in this thread fixed

and

merged

into
2.5 branch? Is there any bug which fix is still in progress?

Just want to know when the QA and bugs fixing stage is over.

--
Denis

On Thu, May 3, 2018 at 9:14 AM, Dmitry Pavlov <

dpavlov@gmail.com

wrote:


Hi Andrey, Igniters,

I propose to include
https://issues.apache.org/jira/browse/IGNITE-8347

fix

to 2.5. It is quite isolated.

Memory leak can be reproduced if node in embedded mode is

restarted

under
the same process (thread is alive and cleanup is not

performed).

Sincerely,
Dmitriy Pavlov

сб, 28 апр. 2018 г. в 19:49, Sergey Chugunov
 wrote:


Guys,

Consider including this [1] to release.

It's major usability issue and if not fixed now will

lead

to

compatibility

issues in subsequent release.

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

пт, 27 апр. 2018 г. в 21:34, Andrey Gura <

ag...@apache.org>:

Of course I meant bug fixes, not bugs :)

On Fri, Apr 27, 2018 at 9:28 PM, Andrey Gura <

ag...@apache.org>

wrote:

Eduard, Pavel,

mentioned bugs are good candidates for including to

release.

Targeted to 2.5.

Thanks!

On Fri, Apr 27, 2018 at 5:06 PM, Pavel Kovalenko <

jokse...@gmail.com

wrote:

Igniters,

I would like to add this issue
https://issues.apache.org/jira/browse/IGNITE-8405

to

2.5

scope.


2018-04-27 16:59 GMT+03:00 Eduard Shangareev <

eshangar...@gridgain.com

:

Guys,
I have finished
ttps://issues.apache.org/jira/browse/IGNITE-7628.

It looks like a good candidate to merge to 2.5.

On Fri, Apr 27, 2018 at 1:32 PM, Ivan Rakov <

ivan.glu...@gmail.com

wrote:

Dmitriy,

There are some notes about WAL compaction in

"Persistence

Under

the

Hood"

article:

https://cwiki.apache.org/confluence/display/IGNITE/

Ignite+

Persistent+Store+-+under+the+

[GitHub] ignite pull request #3961: IGNITE-8453 FileDecompressor may access HashMap w...

[glukos]

GitHub user glukos opened a pull request:

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

IGNITE-8453 FileDecompressor may access HashMap without proper synchr…

…onizationcommit 7037022)

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

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

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

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


commit 2a735095f13de156533dd0488910906474dd9850
Author: Ivan Rakov 
Date:   2018-05-08T14:55:34Z

IGNITE-8453 FileDecompressor may access HashMap without proper 
synchronizationcommit 7037022)




---

[jira] [Created] (IGNITE-8453) FileDecompressor may access HashMap without proper synchronization

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8453:
--

 Summary: FileDecompressor may access HashMap without proper 
synchronization
 Key: IGNITE-8453
 URL: https://issues.apache.org/jira/browse/IGNITE-8453
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.5


Caused by IGNITE-8429.
FileDecompressor performs a remove from regular HashMap (which is shared to 
other threads) without synchronization.



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

[GitHub] ignite pull request #3960: GG-13763 backport IGNITE-8390

[ivandasch]

GitHub user ivandasch opened a pull request:

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

GG-13763 backport IGNITE-8390



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

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

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

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


commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

Merge remote-tracking branch 'professional/ignite-2.4.1' into ignite-2.4.1

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline test to suite
-fixing issues with baseline

commit edae228c8f55990c15ef3044be987dcb00d6c81a
Author: EdShangGG 
Date:   2017-11-18T10:36:41Z

hack with sleep

commit b5bffc7580a4a8ffbcc06f60c282e73979179578
Author: Ilya Lantukh 
Date:   2017-11-18T12:39:19Z

Fixed Ignite.active(true) returning control too early.

commit 1bcdd76aae78665e2bbd49034fb46a1b91ef8389
Author: Ilya Lantukh 
Date:   2017-11-18T13:33:01Z

Fixed baseline topology changes from client/daemon nodes.

commit e3bbecd9f133251818a4b43afa44f46e66dd0325
Author: Alexey Goncharuk 
Date:   2017-11-18T14:16:39Z

Fixed licenses

commit b0d73fe45a8bb89ef82fce561f702095241c0405
Author: Alexey Goncharuk 
Date:   2017-11-18T14:33:49Z

Do not dump entries to log

commit a822e78e2ab7b4dc2b9477f3b6a966b1fd46df54
Author: EdShangGG 
Date:   2017-11-18T16:31:32Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-commenting index restore
-fixing bug with searching in map by consistentId

commit a4c7b693e17378da9980a9049d00bdeeefdc569d
Author: EdShangGG 
Date:   2017-11-18T17:49:57Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced

commit f6ac26baadd160384a7364ce309d6b7102e4119c
Author: Ilya Lantukh 
Date:   2017-11-18T17:59:41Z

Fixed Ignite.active(true) 

[GitHub] ignite pull request #3957: IGNITE-8430 implemented getCurrentCoordinatorForm...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite 2.5 release: Can IGNITE-8041 be included?

[Yury Babak]

Turik,

This pull request looks good to me. So I reviewed and merged this example
into master and 2.5 branches.

Regards,
Yury



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

[GitHub] ignite pull request #3947: IGNITE-8041: Add a GA Grid example that solves 'K...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: IGNITE-6879

[Dmitry Pavlov]

Hi Roman,

now TC passes for 1.0. In the same time new suite is not executed on TC.

I've asked Peter Ivanov to assist in TC run set up for Spring Data 2.0.

Sincerely,
Dmitriy Pavlov

пн, 7 мая 2018 г. в 18:23, Роман Меерсон :

> Dmitry, I leave comment at issue. As i may see localy problem with tests
> was fixed
>
> пн, 7 мая 2018 г. в 17:24, Dmitry Pavlov :
>
>> Hi, I've replied to ticket, seems old tests are now failing after
>> applying patch locally.
>>
>> I've also added 2 suites to TC
>> TEST_SUITE =IgniteSpringDataTestSuite,IgniteSpringData2TestSuite
>> to
>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SpringData
>>
>> so this suite will check both integrations. Ideally we could run this
>> suite one more time before merge.
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> пн, 7 мая 2018 г. в 15:46, Dmitry Pavlov :
>>
>>> Hi Roman,
>>>
>>> Currently I'm checking the changes. Because of applying idea to copy all
>>> changes and upsource problem with this branch it is quite complex to locate
>>> actual changes. It is now required to check all copied files before merge.
>>>
>>> Sincerely,
>>> Dmitriy Pavlov
>>>
>>> пн, 7 мая 2018 г. в 11:07, Роман Меерсон :
>>>
 Hello Dmitry!

 was review successfull? Or there are any points to change?

 сб, 28 апр. 2018 г. в 19:32, Роман Меерсон :

> Ok! I believe in community and that things would change!
> Looking forward for news
> сб, 28 апр. 2018 г. в 19:29, Dmitry Pavlov :
>
>> I hope so!
>>
>> There was several posts related to review time, and AI community is
>> now trying to reduce it. Now it is about 70 tickets waiting to be merged
>> more than 1month. This defenetely should be changed. And I hope all 
>> Ignite
>> committers and maintainters would continue to assist in this.
>>
>> сб, 28 апр. 2018 г. в 18:24, Роман Меерсон :
>>
>>> Hi all!
>>>
>>> Soon we'll celebrate 2 months of my PR :)
>>> Maybe it could be merged?
>>> пн, 23 апр. 2018 г. в 18:52, Dmitry Pavlov :
>>>
 No, nothing yet. I'm going to look to new version.

 пн, 23 апр. 2018 г. в 17:43, Роман Меерсон :

> Hi all!
>
> Are there any news about PR merging?
>
> пн, 16 апр. 2018 г. в 19:43, Роман Меерсон :
>
>> Denis,
>>
>> module naming fixed
>>
>> пн, 16 апр. 2018 г. в 19:24, Denis Magda :
>>
>>> Roman,
>>>
>>> In my last reply, I voted for your approach - using
>>> "spring-data*_*2.0" for
>>> the new Spring version. However, please note that we use "_"
>>> symbol instead
>>> of "-" to separate a version from the package name.
>>>
>>> --
>>> Denis
>>>
>>> On Sun, Apr 15, 2018 at 8:17 AM, Роман Меерсон <
>>> homich1...@gmail.com> wrote:
>>>
>>> > Hi all!
>>> >
>>> > So guys let’s make a decision. We leave code in current state
>>> as I suggest
>>> > or change module naming according Dmitry’s suggestion.
>>> > ср, 11 апр. 2018 г. в 1:54, Denis Magda :
>>> >
>>> > > Roman,
>>> > >
>>> > > Your suggestion sounds reasonable to me. Backing it up.
>>> > >
>>> > > --
>>> > > Denis
>>> > >
>>> > > On Tue, Apr 10, 2018 at 2:50 PM, Роман Меерсон <
>>> homich1...@gmail.com>
>>> > > wrote:
>>> > >
>>> > > > Hi all!
>>> > > >
>>> > > > IMHO if we do so we'll produce big pain for everybody
>>> while migrating
>>> > on
>>> > > > new version, because ones should change method and others
>>> should change
>>> > > > their poms. This change would be backward incompatible so
>>> it probably
>>> > > > should follow with major version upgrade, but I'm not sure
>>> about it.
>>> > > >
>>> > > > Otherwise if we leave current state( spring-data for old
>>> and
>>> > > > spring-data-2.0 for new) we could support old users who
>>> probably use
>>> > > spring
>>> > > > data 1.0 (because spring data 2.0 release was not so long
>>> ago) and
>>> > > provide
>>> > > > new functionality for users who want to use new spring
>>> data.
>>> > > > In this case old users wouldn't change any in their code
>>> except ignite
>>> > > > version, and new users would include ignite in their Pom
>>> anyway and
>>> > could
>>> > > > choose which module of spring 

Re: memory-only mode for Ignite indexes

[Dmitry Pavlov]

Hi Igniters,

I may repeat what was said early, but still: I prefer way of speeding up
indexes proposed by Vladimir in addition to page replacement optimizations
related to index pages.

Also recently Ivan Rakov created issue intended to optimize
findPageForReplacement method, it can also help with performance. End user
can see results as index speedup, but internally it is about page
replacement process.

Sincerely,
Dmitriy Pavlov

вт, 8 мая 2018 г. в 1:12, Vladimir Ozerov :

> Dima, Denis,
>
> Please stp wanting this! :-)
>
> Guys, there are no in-memory indexes just to be in-memory. Let me briefly
> explain what other vendors do and why. There are three approaches:
> 1) You may create *skip-list* based in-memory index. Goal - speedup
> *READS*, not writes. Examples: MS SQL, Couchbase
> 2) You may create *columnar* in-memory index. Goal - speedup *SCANS* in
> OLAP cases, not writes. Example: Oracle [1]
> 3) You may drop my beloved cache groups and introduce
> *tablespaces*.instead.
> Then you assign data and indexes to different tablespaces and assign them
> to *different disks*. Goal - speedup index *WRITES* [2]. Example: all major
> vendors. E.g. putting data and indexes on different disks is one of the
> main Oracle recommendation in their capacity planning documents.
>
> As you see, nobody afraid of writes. Neither should we do.
>
> Vladimir.
>
> [1]
>
> http://www.oracle.com/technetwork/database/in-memory/overview/twp-oracle-database-in-memory-2245633.pdf
> [2] This is one of the reasons why I want to kill cache groups so
> desperately.
>
> On Mon, May 7, 2018 at 9:03 PM, Denis Magda  wrote:
>
> > Truly like the idea of having a separate "indexes in memory only mode"
> > regardless of the optimizations Vladimir keeps track of.
> >
> > In my observations, some database vendors support this as the only mode
> > requiring to rebuild the indexes on a restart which confirms that there
> is
> > a demand for this configuration in the industry.
> >
> > --
> > Denis
> >
> > On Mon, May 7, 2018 at 7:42 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Agree.
> > >
> > > On Mon, May 7, 2018 at 5:20 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > > wrote:
> > >
> > > > On Mon, May 7, 2018 at 2:09 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > > wrote:
> > > >
> > > > > Hi Dima,
> > > > >
> > > > > Update with indexes would definitely be slower than update without
> > > them.
> > > > > The question is how much slower. For now the slowdown comes mostly
> > from
> > > > > excessive data page reads ([1] and [2] in my previous email)
> leading
> > to
> > > > > page evictions and additional IO. To the contrast, usually only a
> > > single
> > > > > page write is needed to update an index. Correct index
> implementation
> > > > ([1]
> > > > > and [2] from previous email) would eliminate data page reads
> > altogether
> > > > and
> > > > > should give dramatic speedup.
> > > > >
> > > >
> > > > Sounds great. The changes you are suggesting should give us a great
> > > > performance boost. Hopefully they should not take too long to
> > implement.
> > > >
> > > > Regardless, once you are done, we should still perform a benchmark
> with
> > > > persistence indexes vs memory-only indexes. If memory-only will be
> more
> > > > than 20% faster, we should still implement it.
> > > >
> > > > D.
> > > >
> > >
> >
>

RE: Apache Ignite 2.4+ Go language client

[Aleksandr Sokolovskii]

Hi Alexey,

I spent some time and fully implemented OP_QUERY_SQL and 
OP_QUERY_SQL_CURSOR_GET_PAGE including unit tests.
The OP_QUERY_SQL returns value as complex object (code=103) wrapped by array 
(code=27).
But it’s not the end of the story. )))
Complex object is marshalled in different way than described in documentation.

Example how to unmarshall complex object of several formats:
https://github.com/amsokol/ignite-go-client/blob/master/binary/v1/types.go#L969

Unit test for OP_QUERY_SQL:
https://github.com/amsokol/ignite-go-client/blob/master/binary/v1/client-sql-and-scan-queries_test.go#L9

Unit test for OP_QUERY_SQL_CURSOR_GET_PAGE:
https://github.com/amsokol/ignite-go-client/blob/master/binary/v1/client-sql-and-scan-queries_test.go#L80

Thanks,
Aleksandr

From: Alexey Kosenchuk
Sent: 25 апреля 2018 г. 16:33
To: dev@ignite.apache.org
Subject: Re: Apache Ignite 2.4+ Go language client

No problem with OP_QUERY_SQL_FIELDS.
I mean OP_QUERY_SQL.
But I overlooked "OP_QUERY_SQL - Done without unit test. Need help to 
develop unit test."
Sorry. I remove my question so far)))

Thanks,
-Alexey

25.04.2018 15:40, Aleksandr Sokolovskii пишет:
> Hi Alexey,
> 
>> Seems an important missed part is complex objects support.
>> And it's the most difficult part.
> Yes, you are absolutely right.
> Complex object and binary types are not supported by my client now.
> That’s why I’m here.
> I plan to come back to this subject in the beginning of May.
> I very much count on the community help.
> 
>> Also, do you have a working example for SQL Query which first inserts
>> cache entries and then selects them and successfully get the same values
>> which were inserted ?
> Yes, it works fine.
> This one:
> https://github.com/amsokol/ignite-go-client/blob/master/binary/v1/client-sql-and-scan-queries_test.go#L89
> It’s OP_QUERY_SQL_FIELDS operation unit test.
> It you are familiar with Go it’s easy to run in debug mode.
> 
> If you explain me your problem I can try to help you.
> There some mistakes in binary protocol documentation.
> So I spent a lot of time in Apache Ignite server source code analyzing )))
> 
> Thanks,
> Aleksandr
> 
> From: Alexey Kosenchuk
> Sent: 25 апреля 2018 г. 12:05
> To: dev@ignite.apache.org
> Subject: Re: Apache Ignite 2.4+ Go language client
> 
> Hi Aleksandr,
> 
> Seems an important missed part is complex objects support.
> And it's the most difficult part.
> Actually, it is not possible to implement it correctly basing on the
> current protocol spec only.
> If you decide to support it, you should either wait for an updated spec
> or ask for help.
> 
> The issues against the current protocol spec are summarized in
> IGNITE-8039 [1] and IGNITE-8212 [2]. One more jira with the issues
> against the rest of the spec will be submitted soon.
> If you see more issues, please feel free to added them as comments to
> that jiras.
> 
> Also, do you have a working example for SQL Query which first inserts
> cache entries and then selects them and successfully get the same values
> which were inserted ?
> 
> Thanks,
> -Alexey
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-8039
> [2] https://issues.apache.org/jira/browse/IGNITE-8212
> 
> 25.04.2018 0:11, Aleksandr Sokolovskii пишет:
>> ...forgot OP_RESOURCE_CLOSE that is implemented also.
>>
>> Thanks,
>> Aleksandr
>>
>> Thanks,
>> Aleksandr
>>
>> On 25 April 2018 at 00:06, Aleksandr Sokolovskii  wrote:
>>
>>> Hello All,
>>>
>>> Besides the SQL driver I implemented the following operations also:
>>> OP_CACHE_GET_NAMES
>>> OP_CACHE_CREATE_WITH_NAME
>>> OP_CACHE_GET_OR_CREATE_WITH_NAME
>>> OP_CACHE_CREATE_WITH_CONFIGURATION
>>> OP_CACHE_GET_OR_CREATE_WITH_CONFIGURATION
>>> OP_CACHE_GET_CONFIGURATION
>>> OP_CACHE_DESTROY
>>> OP_CACHE_GET
>>> OP_CACHE_PUT
>>> OP_CACHE_PUT_IF_ABSENT
>>> OP_CACHE_GET_ALL
>>> OP_CACHE_PUT_ALL
>>> OP_CACHE_GET_AND_PUT
>>> OP_CACHE_GET_AND_REPLACE
>>> OP_CACHE_GET_AND_REMOVE
>>> OP_CACHE_GET_AND_PUT_IF_ABSENT
>>> OP_CACHE_REPLACE
>>> OP_CACHE_REPLACE_IF_EQUALS
>>> OP_CACHE_CONTAINS_KEY
>>> OP_CACHE_CONTAINS_KEYS
>>> OP_CACHE_CLEAR
>>> OP_CACHE_CLEAR_KEY
>>> OP_CACHE_CLEAR_KEYS
>>> OP_CACHE_REMOVE_KEY
>>> OP_CACHE_REMOVE_IF_EQUALS
>>> OP_CACHE_REMOVE_KEYS
>>> OP_CACHE_REMOVE_ALL
>>> OP_CACHE_GET_SIZE
>>> OP_QUERY_SQL
>>> OP_QUERY_SQL_CURSOR_GET_PAGE
>>> OP_QUERY_SQL_FIELDS
>>> OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE
>>>
>>> Look at the Client interface here:
>>> https://github.com/amsokol/ignite-go-client/blob/master/
>>> binary/v1/client.go
>>>
>>> But not all Apache Ignite types are supported now.
>>> See README in https://github.com/amsokol/ignite-go-client for details.
>>>
>>> Thanks,
>>> Aleksandr
>>>
>>>
>>>
>>> Thanks,
>>> Aleksandr
>>>
>>> On 24 April 2018 at 13:16, Igor Sapego  wrote:
>>>
 Aleksandr,

 Great job! Do you have any plans on adding new features to
 your client?

 Pavel,

 There are  also CacheGet and CachePut [1] operations, as
 far as 

Re: IGNITE-3999 review

[Dmitriy Setrakyan]

Igniters, let's make sure we add ticket description to the email subject in
future, so the community will know what the ticket is about. Not everyone
has time to look for the ticket, especially when the link is not even
provided in the email.

For example, the subject of this thread should have been: "IGNITE-3999:
Support case insensitive search in SQL"

D.

On Tue, May 8, 2018 at 2:28 PM, Dmitry Pavlov  wrote:

> Hi Vladimir, thank you for stepping in.
>
> This case confirms the usefulness of the practice of discussing the problem
> at the devlist before implementation.
>
> вт, 8 мая 2018 г. в 10:12, Vladimir Ozerov :
>
> > Hi,
> >
> > I provided my comments in the ticket.
> >
> > On Tue, May 8, 2018 at 5:54 AM, Amir Akhmedov 
> > wrote:
> >
> > > Hi Nikolay, Dmitry Pavlov,
> > > Can you take a look at this PR or maybe you have an idea when it
> probably
> > > can be reviewed?
> > >
> > > Thanks,
> > > Amir
> > >
> > > On Wed, Apr 11, 2018 at 10:57 AM, Nikolay Izhikov  >
> > > wrote:
> > >
> > > > Hello, Amir.
> > > >
> > > > Sorry, but no.
> > > >
> > > > I will take a look in a next few days.
> > > >
> > > >
> > > > В Ср, 11/04/2018 в 14:51 +, Amir Akhmedov пишет:
> > > > > Hi Nikolay,
> > > > >
> > > > > Did you have a chance to check my changes?
> > > > >
> > > > > Thanks,
> > > > > Amir
> > > >
> > >
> >
>

Re: Postpone Apache Ignite 2.5 release to fix baseline topology

[Dmitriy Setrakyan]

Completely support the decision to move any BLT behavior changes to 2.6.
However, in 2.5 we need to add usability log messages, which I believe we
already have.

D.

On Tue, May 8, 2018 at 2:15 PM, Andrey Gura  wrote:

> Igniters,
>
> I believe BLT is serious usability problem but rush isn't good idea
> because can lead to new bugs. As release manager I think that we
> should move BLT fix to Apache Ignite 2.6 release and focus on issues
> included to the AI 2.5 release scope.
> I also want inform you that code freeze is planned for Friday, May 11.
>
> Thanks!
>
> On Sun, Apr 29, 2018 at 8:44 PM, Dmitry Pavlov 
> wrote:
> > Hi Dmitriy,
> >
> > As far as I understand manual activation will not be required for
> in-memory
> > mode (same for persistence). Change means we will change node state from
> > 'joined-inactive' to 'joined-active' according to that user defined in
> > policy (cluster grow policy).
> >
> > Default will be allow to rebalance data to joined node, probably, with
> some
> > delay. This detail will be defenetely discussed at dev list before
> > implementation.
> >
> > Pros: Persistent users will not be facing with disabled rebalancing in
> case
> > of node left - (BL)AT will be changed automatically. This also be handled
> > by cluster shrink policy for both in-memory and durable cases.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 28 апр. 2018 г. в 21:10, Dmitriy Setrakyan :
> >
> >> Can someone explain what is the before and after effect for this change
> >> from the usability standpoint. If we are changing BLT for the in-memory
> >> mode, which is the default, then we must think through all the usability
> >> consequences ahead of time. Otherwise, the perception will be that the
> >> product stopped working because someone did not know to activate the
> >> cluster.
> >>
> >> D.
> >>
> >> On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda  wrote:
> >>
> >> > I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's
> not
> >> > time-consuming. To give you a bit more context on the subj, here is
> why
> >> we
> >> > should have the fix to be delivered in 2.5:
> >> > http://apache-ignite-users.70518.x6.nabble.com/Problems-
> >> > with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
> >> >
> >> > Frankly, it's not the first time I see similar complaints from those
> who
> >> > are on 2.4.
> >> >
> >> > Alex G., Vovan, how hard is it to fix this?
> >> >
> >> > --
> >> > Denis
> >> >
> >> >
> >> > On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> >> > wrote:
> >> >
> >> > > Yakov,
> >> > >
> >> > > Messages would help users understand what is wrong earlier, but will
> >> not
> >> > > protect them from additional maintenance which is required in AI 2.4
> >> and
> >> > is
> >> > > supposed to be removed in next AI releases.
> >> > > Please note that in IEP-4 topic I proposed alternative solution -
> >> release
> >> > > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
> >> > would
> >> > > be emergency release.
> >> > >
> >> > > Both approaches works for me, the main goal is to deliver original
> >> > defaults
> >> > > ASAP. However, approach with a single release looks better to me
> >> because
> >> > it
> >> > > will minimize number of migrations for users.
> >> > >
> >> > > Vladimir.
> >> > >
> >> > >
> >> > > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov  >
> >> > > wrote:
> >> > >
> >> > > > Guys, how about we release 2.5 in the nearest future after adding
> >> > proper
> >> > > > usability log messages that will explain user what to do and also
> >> > output
> >> > > > link to readme.io with the first BLT related message during node
> >> > uptime.
> >> > > > This should not take much time and we can use the same messages
> when
> >> we
> >> > > > have (BL)AT modes in 2.6. I think that adding messages makes sense
> >> and
> >> > > > should be clear for users which is not the case for 2.4.
> >> > > >
> >> > > > --Yakov
> >> > > >
> >> > >
> >> >
> >>
>

[GitHub] ignite pull request #3959: IGNITE-8446 Ability to check and completely fill ...

[anton-vinogradov]

GitHub user anton-vinogradov opened a pull request:

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

IGNITE-8446 Ability to check and completely fill transactions on crea…

…tion

Signed-off-by: Anton Vinogradov 

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

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

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

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


commit ff9be9907f2e75ac6c16ab53d425f886987966dd
Author: Anton Vinogradov 
Date:   2018-05-08T12:34:33Z

IGNITE-8446 Ability to check and completely fill transactions on creation

Signed-off-by: Anton Vinogradov 




---

Re: Apache Ignite 2.5 release

[Vladimir Ozerov]

H2 version updated is moved to AI 2.6. There are several serious problems,
main - spatial dependency replacement which is a breaking change.

On Tue, May 8, 2018 at 10:17 AM, Pavel Tupitsyn 
wrote:

> IGNITE-8434 merged to master, cherry-picked to ignite-2.5.
>
> Thank you, Andrey!
>
> On Mon, May 7, 2018 at 10:46 PM, Andrey Gura  wrote:
>
> > Pavel,
> >
> > issue is targeted to release 2.5 now. Thanks!
> >
> > On Mon, May 7, 2018 at 10:40 PM, Pavel Tupitsyn 
> > wrote:
> > > Igniters,
> > >
> > > There is an unpleasant bug in .NET [1]:
> > > Services do not work at all on .NET Core and sometimes on classic .NET.
> > >
> > > I'm almost done with the fix and I think we should include it in 2.5.
> > Users
> > > are complaining [2].
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-8434
> > > [2]
> > > http://apache-ignite-users.70518.x6.nabble.com/Re-
> > Service-Grid-and-net-core-2-td21318.html
> > >
> > > On Mon, May 7, 2018 at 6:44 PM, Vladimir Ozerov 
> > > wrote:
> > >
> > >> Andrey,
> > >>
> > >> I realized that we missed one very important thing - H2 version
> upgrade
> > >> [1]. This is very important thing because new version contain
> > optimization
> > >> to IN clause processing. All we need is to upgrade H2 vesion from
> > 1.4.196
> > >> to 1.4.197 and re-run tests. Can we target it to 2.5 release?
> > >>
> > >> [1] https://issues.apache.org/jira/browse/IGNITE-4150
> > >>
> > >> On Mon, May 7, 2018 at 6:07 PM, Andrey Gura  wrote:
> > >>
> > >> > Ivan,
> > >> >
> > >> > ok, targeted to 2.5. Thanks!
> > >> >
> > >> > On Mon, May 7, 2018 at 5:24 PM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > >> > wrote:
> > >> > > Thank you, Andrey,
> > >> > >
> > >> > > I saw 1 more proposal in separate topic
> > >> > > http://apache-ignite-developers.2346864.n4.nabble.
> > >> > com/RE-Hi-can-we-squeeze-this-into-2-5-https-issues-apache-
> > >> > org-jira-browse-IGNITE-8439-td30161.html
> > >> > >
> > >> > > and 1 proposal here related to ML:
> > >> > > http://apache-ignite-developers.2346864.n4.nabble.
> > >> > com/Apache-Ignite-2-5-release-td28927i20.html#a30155
> > >> > > but here Yuriy Babak probably should share his opinion.
> > >> > >
> > >> > > Sincerely,
> > >> > > Dmitriy Pavlov
> > >> > >
> > >> > > пн, 7 мая 2018 г. в 17:09, Andrey Gura :
> > >> > >>
> > >> > >> Sergey, Dmitry,
> > >> > >>
> > >> > >> I've targeted your issues to 2.5 release.
> > >> > >>
> > >> > >> Thanks!
> > >> > >>
> > >> > >> On Fri, May 4, 2018 at 5:51 PM, Dmitry Pavlov <
> > dpavlov@gmail.com>
> > >> > >> wrote:
> > >> > >> > I did not understand process.
> > >> > >> >
> > >> > >> > Is it required to receive someone reply that issue is agreed to
> > be
> > >> > >> > included
> > >> > >> > into release?
> > >> > >> >
> > >> > >> > Or because there is no response I can cherry-pick anything to
> 2.5
> > >> > hoping
> > >> > >> > it
> > >> > >> > is lazy consensus; no one objected.
> > >> > >> >
> > >> > >> > пт, 4 мая 2018 г. в 17:44, Denis Magda :
> > >> > >> >
> > >> > >> >> Igniters,
> > >> > >> >>
> > >> > >> >> I got lost. Were all the bugs reported in this thread fixed
> and
> > >> > merged
> > >> > >> >> into
> > >> > >> >> 2.5 branch? Is there any bug which fix is still in progress?
> > >> > >> >>
> > >> > >> >> Just want to know when the QA and bugs fixing stage is over.
> > >> > >> >>
> > >> > >> >> --
> > >> > >> >> Denis
> > >> > >> >>
> > >> > >> >> On Thu, May 3, 2018 at 9:14 AM, Dmitry Pavlov <
> > >> dpavlov@gmail.com
> > >> > >
> > >> > >> >> wrote:
> > >> > >> >>
> > >> > >> >> > Hi Andrey, Igniters,
> > >> > >> >> >
> > >> > >> >> > I propose to include
> > >> > >> >> > https://issues.apache.org/jira/browse/IGNITE-8347
> > >> > >> >> fix
> > >> > >> >> > to 2.5. It is quite isolated.
> > >> > >> >> >
> > >> > >> >> > Memory leak can be reproduced if node in embedded mode is
> > >> restarted
> > >> > >> >> > under
> > >> > >> >> > the same process (thread is alive and cleanup is not
> > performed).
> > >> > >> >> >
> > >> > >> >> > Sincerely,
> > >> > >> >> > Dmitriy Pavlov
> > >> > >> >> >
> > >> > >> >> > сб, 28 апр. 2018 г. в 19:49, Sergey Chugunov
> > >> > >> >> >  > >> > >> >> >:
> > >> > >> >> >
> > >> > >> >> > > Igniters,
> > >> > >> >> > >
> > >> > >> >> > > I would like to include into release another critical bug
> > found
> > >> > in
> > >> > >> >> > > ZooKeeper Discovery [1].
> > >> > >> >> > >
> > >> > >> >> > > Situation reproducing the error is very specific and rare
> > but
> > >> it
> > >> > >> >> > > leads
> > >> > >> >> to
> > >> > >> >> > > full cluster shut down. At the same time fix for it very
> > simple
> > >> > and
> > >> > >> >> > > I
> > >> > >> >> > don't
> > >> > >> >> > > expect it is too risky.
> > >> > >> >> > >
> > >> > >> >> > > [1] https://issues.apache.org/jira/browse/IGNITE-8421
> > >> > 

Re: IGNITE-3999 review

[Dmitry Pavlov]

Hi Vladimir, thank you for stepping in.

This case confirms the usefulness of the practice of discussing the problem
at the devlist before implementation.

вт, 8 мая 2018 г. в 10:12, Vladimir Ozerov :

> Hi,
>
> I provided my comments in the ticket.
>
> On Tue, May 8, 2018 at 5:54 AM, Amir Akhmedov 
> wrote:
>
> > Hi Nikolay, Dmitry Pavlov,
> > Can you take a look at this PR or maybe you have an idea when it probably
> > can be reviewed?
> >
> > Thanks,
> > Amir
> >
> > On Wed, Apr 11, 2018 at 10:57 AM, Nikolay Izhikov 
> > wrote:
> >
> > > Hello, Amir.
> > >
> > > Sorry, but no.
> > >
> > > I will take a look in a next few days.
> > >
> > >
> > > В Ср, 11/04/2018 в 14:51 +, Amir Akhmedov пишет:
> > > > Hi Nikolay,
> > > >
> > > > Did you have a chance to check my changes?
> > > >
> > > > Thanks,
> > > > Amir
> > >
> >
>

Re: Node.js client update: rev. 2

[Alexey Kosenchuk]

Hi Igor,

in the newer version (will be available soon) getValues() is changed to 
getValue() which gives sequential per-element access.


The API spec and the setup/run instructions are available with every 
version.


Thanks,
-Alexey

08.05.2018 15:14, Igor Sapego пишет:

Hi, Pavel,

I took a look, and everything looks OK to me (except for the
lack of documentation, but I guess, this is expected for the
early version).

I have a question regardless Cursor class though. Other thin
clients, as far as I know, implement Cursor as a simple
iterator, which gives sequential per-element access, while in
your implementation there is only getAll() and getValues()
methods. The last method returns a whole bunch of values
as an array of unknown size. Are there any reasons from
JS point of view for such architecture?


Best Regards,
Igor

On Fri, Apr 13, 2018 at 2:37 AM, Pavel Petroshenko 
wrote:


Hi Denis,

Thank you for looking at the proposal and raising these questions! We'll
take them to discuss offline and will address your recommendations in the
next revision.

I will let Vladimir comment on the QueryEntity here though to make sure we
are on the same page.

Thanks,

P.


On Thu, Apr 12, 2018 at 2:48 PM, Denis Magda  wrote:


Hello Pavel,

Thanks for the update. Haven't heard from you guys for a while but seems
you were too busy polishing the client. Looks great!

Please consider several questions/notes:

- Do we really want to migrate QueryEntity API [1] to Node.JS client?

I

heard we planned to deprecate it in the future. *Vladimir*, please

share

your thoughts.
- I wouldn't mix key-value and SQL examples together because they
represent different use cases of Ignite. For the sake of simplicity, I
would create a single SqlExample file that uses DDL to configure
tables/cache, inserts data with INSERTS and SELECTs it back (simple
queries
and queries with JOINs). We can base it on the database and queries

used

here [2]. Happy to brainstorm on this with you separately.
-


[1]
https://github.com/nobitlost/ignite/blob/master/modules/
clients/nodejs/examples/SqlQueryExample.js#L68
[2] https://apacheignite-sql.readme.io/docs/getting-started

--
Denis

On Wed, Apr 11, 2018 at 6:45 PM, Pavel Petroshenko <

pa...@petroshenko.com>

wrote:


Igniters,

Just to give you an update on the next iteration of the Ignite Node.js

thin

client implementation.

The second iteration is available for review/testing.

The changes are available in the pull request [1] or directly from our
repository [2].

The short README file [3] covers:

- the list of supported features
- simple instructions:
   * how to install the client
   * how to run the examples
   * how to run the tests

And we actually encourage you to give it a look or even a try.

The APIs are available both: in sources [4] and in a form of a

generated

specification, produced automatically from the jsdoc comments [5]

Please let us know if you have any questions.

Thanks!

P.

[1] https://github.com/apache/ignite/pull/3680
[2] https://github.com/nobitlost/ignite/tree/master/modules/

clients/nodejs

[3] https://github.com/nobitlost/ignite/blob/master/
modules/clients/nodejs/README.md
[4] https://github.com/nobitlost/ignite/blob/master/
modules/clients/nodejs/lib
[5] https://rawgit.com/nobitlost/ignite/master/modules/clients/

nodejs/api_

spec/index.html

Re: Postpone Apache Ignite 2.5 release to fix baseline topology

[Andrey Gura]

Igniters,

I believe BLT is serious usability problem but rush isn't good idea
because can lead to new bugs. As release manager I think that we
should move BLT fix to Apache Ignite 2.6 release and focus on issues
included to the AI 2.5 release scope.
I also want inform you that code freeze is planned for Friday, May 11.

Thanks!

On Sun, Apr 29, 2018 at 8:44 PM, Dmitry Pavlov  wrote:
> Hi Dmitriy,
>
> As far as I understand manual activation will not be required for in-memory
> mode (same for persistence). Change means we will change node state from
> 'joined-inactive' to 'joined-active' according to that user defined in
> policy (cluster grow policy).
>
> Default will be allow to rebalance data to joined node, probably, with some
> delay. This detail will be defenetely discussed at dev list before
> implementation.
>
> Pros: Persistent users will not be facing with disabled rebalancing in case
> of node left - (BL)AT will be changed automatically. This also be handled
> by cluster shrink policy for both in-memory and durable cases.
>
> Sincerely,
> Dmitriy Pavlov
>
> сб, 28 апр. 2018 г. в 21:10, Dmitriy Setrakyan :
>
>> Can someone explain what is the before and after effect for this change
>> from the usability standpoint. If we are changing BLT for the in-memory
>> mode, which is the default, then we must think through all the usability
>> consequences ahead of time. Otherwise, the perception will be that the
>> product stopped working because someone did not know to activate the
>> cluster.
>>
>> D.
>>
>> On Sat, Apr 28, 2018 at 9:27 AM, Denis Magda  wrote:
>>
>> > I'm backing up Vladimir's proposal to fix the behavior in 2.5 if it's not
>> > time-consuming. To give you a bit more context on the subj, here is why
>> we
>> > should have the fix to be delivered in 2.5:
>> > http://apache-ignite-users.70518.x6.nabble.com/Problems-
>> > with-persistence-and-partitioned-cache-in-2-4-0-td21325.html
>> >
>> > Frankly, it's not the first time I see similar complaints from those who
>> > are on 2.4.
>> >
>> > Alex G., Vovan, how hard is it to fix this?
>> >
>> > --
>> > Denis
>> >
>> >
>> > On Sat, Apr 28, 2018 at 7:56 AM, Vladimir Ozerov 
>> > wrote:
>> >
>> > > Yakov,
>> > >
>> > > Messages would help users understand what is wrong earlier, but will
>> not
>> > > protect them from additional maintenance which is required in AI 2.4
>> and
>> > is
>> > > supposed to be removed in next AI releases.
>> > > Please note that in IEP-4 topic I proposed alternative solution -
>> release
>> > > AI 2.5 now, but then release AI 2.6 as soon as BLT is fixed. I.e. it
>> > would
>> > > be emergency release.
>> > >
>> > > Both approaches works for me, the main goal is to deliver original
>> > defaults
>> > > ASAP. However, approach with a single release looks better to me
>> because
>> > it
>> > > will minimize number of migrations for users.
>> > >
>> > > Vladimir.
>> > >
>> > >
>> > > On Sat, Apr 28, 2018 at 5:47 PM, Yakov Zhdanov 
>> > > wrote:
>> > >
>> > > > Guys, how about we release 2.5 in the nearest future after adding
>> > proper
>> > > > usability log messages that will explain user what to do and also
>> > output
>> > > > link to readme.io with the first BLT related message during node
>> > uptime.
>> > > > This should not take much time and we can use the same messages when
>> we
>> > > > have (BL)AT modes in 2.6. I think that adding messages makes sense
>> and
>> > > > should be clear for users which is not the case for 2.4.
>> > > >
>> > > > --Yakov
>> > > >
>> > >
>> >
>>

[jira] [Created] (IGNITE-8452) ML module compilation failure under Java 9

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8452:


 Summary: ML module compilation failure under Java 9
 Key: IGNITE-8452
 URL: https://issues.apache.org/jira/browse/IGNITE-8452
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Peter Ivanov
 Fix For: 2.5


Running Apache Ignite build on master branch (commit: ) fails with following 
error:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
(default-testCompile) on project ignite-ml: Compilation failure: Compilation 
failure:
[ERROR] 
/Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
 incompatible types: java.lang.Object cannot be converted to java.lang.Integer
[ERROR] 
/Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
 incompatible types: java.lang.Object cannot be converted to java.lang.Integer
{code}



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

[GitHub] ignite pull request #3958: IGNITE-8450: Cleanup old algebra

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-8450: Cleanup old algebra



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

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

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

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


commit 098d2832b3f4af23c72bc25f43e4ab8a95f2f416
Author: Zinoviev Alexey 
Date:   2018-04-11T18:40:27Z

IGNITE-7829: Added example

commit 78f9ea687bff77ec9f6bef87126569cb92cbe745
Author: Zinoviev Alexey 
Date:   2018-04-13T15:44:26Z

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

commit 199e17d19ccbde9f15aba5375d834c3930b3a989
Author: Zinoviev Alexey 
Date:   2018-04-27T10:12:47Z

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

commit aca9833df4d3cc4a641dd9109daaf628bc85acdf
Author: Zinoviev Alexey 
Date:   2018-05-08T05:29:49Z

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

commit 861102f115fdd2458aa30ff098395100885bae33
Author: Zinoviev Alexey 
Date:   2018-05-08T10:56:46Z

Removed old algebra




---

Re: Ticket review checklist

[Andrey Kuznetsov]

Anton,

I agree, *MUST* for exception reasons and *SHOULD* for ways of resolution
sound clearer.

2018-05-08 12:56 GMT+03:00 Anton Vinogradov :

> Andrey,
>
> How about
> 1.6) All exceptions thrown to a user *MUST* have explanation of workaround
> and contain original error.
> All exceptions thrown to a user *SHOULD* have explanation how to resolve if
> possible.
> ?
>
> вт, 8 мая 2018 г. в 12:26, Andrey Kuznetsov :
>
> > Vladimir, checklist looks pleasant enough for me.
> >
> > I'd like to suggest one minor change. In 1.6 *MUST* seems to be too
> strict,
> > *SHOULD* would be enough. It can be frustrating for API user if I explain
> > how to fix NPEs in a trivial way, for example.
> >
> > 2018-05-08 11:34 GMT+03:00 Anton Vinogradov :
> >
> > > Alex,
> > >
> > > It is not sounds like that, obviously.
> > >
> > > Tests should cover all negative and positive cases.
> > > You should add enough tests to cover all cases.
> > >
> > > Sometimes one test can cover more than one case, so two tests *CAN*
> > > partially check same things.
> > > In case some cases already covered you should not create duplicates.
> > >
> > > вт, 8 мая 2018 г. в 10:19, Александр Меньшиков :
> > >
> > > > Vladimir, the 3.1 is a bit unclear for me. Which code coverage is
> > > > acceptable? Now it sounds like two tests are enough (one for positive
> > and
> > > > one for negative cases).
> > > >
> > > > 2018-05-07 23:09 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > Is this list on the Wiki?
> > > > >
> > > > > On Mon, May 7, 2018 at 7:26 AM, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > This is the checklist I have at the moment. Please let me know if
> > you
> > > > > have
> > > > > > any comments on existing items, or want to add or remove
> anything.
> > It
> > > > > looks
> > > > > > like we may have not only strict rules, but *nice to have* points
> > > here
> > > > as
> > > > > > well with help of *MUST*, *SHOULD* and *MAY* words as per RFC2119
> > > [1].
> > > > So
> > > > > > please feel free to suggest optional items as well.
> > > > > >
> > > > > > 1) API
> > > > > > 1.1) API compatibility *MUST* be maintained between minor
> releases.
> > > Do
> > > > > not
> > > > > > remove existing methods or change their signatures, deprecate
> them
> > > > > instead
> > > > > > 1.2) Default behaviour "SHOULD NOT* be changed between minor
> > > releases,
> > > > > > unless absolutely needed. If change is made, it *MUST* be
> described
> > > in
> > > > > > "Migration Guide"
> > > > > > 1.3) New operation *MUST* be well-documented in code (javadoc,
> > > > > dotnetdoc):
> > > > > > documentation must contain method's purpose, description of
> > > parameters
> > > > > and
> > > > > > how their values affect the outcome, description of return value
> > and
> > > > it's
> > > > > > default, behavior in negative cases, interaction with other
> > > operations
> > > > > and
> > > > > > components
> > > > > > 1.4) API parity between Java and .NET platforms *SHOULD* be
> > > maintained
> > > > > when
> > > > > > operation makes sense on both platforms. If method cannot be
> > > > implemented
> > > > > in
> > > > > > a platform immediately, new JIRA ticket *MUST* be created and
> > linked
> > > to
> > > > > > current ticket
> > > > > > 1.5) API parity between thin clients (Java, .NET) *SHOULD* be
> > > > maintained
> > > > > > when operation makes sense on several clients. If method cannot
> be
> > > > > > implemented in a client immediately, new JIRA ticket *MUST* be
> > > created
> > > > > and
> > > > > > linked to current ticket
> > > > > > 1.6) All exceptions thrown to a user *MUST* have explanation how
> to
> > > > > > resolve, workaround or debug an error
> > > > > >
> > > > > > 2) Compatibility
> > > > > > 2.1) Persistence backward compatibility *MUST* be maintained
> > between
> > > > > minor
> > > > > > releases. It should be possible to start newer version on data
> > files
> > > > > > created by the previous version
> > > > > > 2.2) Thin client forward and backward compatibility *SHOULD* be
> > > > > maintained
> > > > > > between two consecutive minor releases. If compatibility cannot
> be
> > > > > > maintained it *MUST* be described in "Migration Guide"
> > > > > > 2.3) JDBC and ODBC forward and backward compatibility *SHOULD* be
> > > > > > maintained between two consecutive minor releases. If
> compatibility
> > > > > cannot
> > > > > > be maintained it *MUST* be described in "Migration Guide"
> > > > > >
> > > > > > 3) Tests
> > > > > > 3.1) New functionality *MUST* be covered with unit tests for both
> > > > > positive
> > > > > > and negative use cases
> > > > > > 3.2) All test suites *MUST* be run before merge to master..There
> > > *MUST*
> > > > > be
> > > > > > no new test failures
> > > > > >
> > > > > > 4) Code style *MUST* be followed as per Ignite's 

Re: Ticket review checklist

[Anton Vinogradov]

Andrey,

How about
1.6) All exceptions thrown to a user *MUST* have explanation of workaround
and contain original error.
All exceptions thrown to a user *SHOULD* have explanation how to resolve if
possible.
?

вт, 8 мая 2018 г. в 12:26, Andrey Kuznetsov :

> Vladimir, checklist looks pleasant enough for me.
>
> I'd like to suggest one minor change. In 1.6 *MUST* seems to be too strict,
> *SHOULD* would be enough. It can be frustrating for API user if I explain
> how to fix NPEs in a trivial way, for example.
>
> 2018-05-08 11:34 GMT+03:00 Anton Vinogradov :
>
> > Alex,
> >
> > It is not sounds like that, obviously.
> >
> > Tests should cover all negative and positive cases.
> > You should add enough tests to cover all cases.
> >
> > Sometimes one test can cover more than one case, so two tests *CAN*
> > partially check same things.
> > In case some cases already covered you should not create duplicates.
> >
> > вт, 8 мая 2018 г. в 10:19, Александр Меньшиков :
> >
> > > Vladimir, the 3.1 is a bit unclear for me. Which code coverage is
> > > acceptable? Now it sounds like two tests are enough (one for positive
> and
> > > one for negative cases).
> > >
> > > 2018-05-07 23:09 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Is this list on the Wiki?
> > > >
> > > > On Mon, May 7, 2018 at 7:26 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > This is the checklist I have at the moment. Please let me know if
> you
> > > > have
> > > > > any comments on existing items, or want to add or remove anything.
> It
> > > > looks
> > > > > like we may have not only strict rules, but *nice to have* points
> > here
> > > as
> > > > > well with help of *MUST*, *SHOULD* and *MAY* words as per RFC2119
> > [1].
> > > So
> > > > > please feel free to suggest optional items as well.
> > > > >
> > > > > 1) API
> > > > > 1.1) API compatibility *MUST* be maintained between minor releases.
> > Do
> > > > not
> > > > > remove existing methods or change their signatures, deprecate them
> > > > instead
> > > > > 1.2) Default behaviour "SHOULD NOT* be changed between minor
> > releases,
> > > > > unless absolutely needed. If change is made, it *MUST* be described
> > in
> > > > > "Migration Guide"
> > > > > 1.3) New operation *MUST* be well-documented in code (javadoc,
> > > > dotnetdoc):
> > > > > documentation must contain method's purpose, description of
> > parameters
> > > > and
> > > > > how their values affect the outcome, description of return value
> and
> > > it's
> > > > > default, behavior in negative cases, interaction with other
> > operations
> > > > and
> > > > > components
> > > > > 1.4) API parity between Java and .NET platforms *SHOULD* be
> > maintained
> > > > when
> > > > > operation makes sense on both platforms. If method cannot be
> > > implemented
> > > > in
> > > > > a platform immediately, new JIRA ticket *MUST* be created and
> linked
> > to
> > > > > current ticket
> > > > > 1.5) API parity between thin clients (Java, .NET) *SHOULD* be
> > > maintained
> > > > > when operation makes sense on several clients. If method cannot be
> > > > > implemented in a client immediately, new JIRA ticket *MUST* be
> > created
> > > > and
> > > > > linked to current ticket
> > > > > 1.6) All exceptions thrown to a user *MUST* have explanation how to
> > > > > resolve, workaround or debug an error
> > > > >
> > > > > 2) Compatibility
> > > > > 2.1) Persistence backward compatibility *MUST* be maintained
> between
> > > > minor
> > > > > releases. It should be possible to start newer version on data
> files
> > > > > created by the previous version
> > > > > 2.2) Thin client forward and backward compatibility *SHOULD* be
> > > > maintained
> > > > > between two consecutive minor releases. If compatibility cannot be
> > > > > maintained it *MUST* be described in "Migration Guide"
> > > > > 2.3) JDBC and ODBC forward and backward compatibility *SHOULD* be
> > > > > maintained between two consecutive minor releases. If compatibility
> > > > cannot
> > > > > be maintained it *MUST* be described in "Migration Guide"
> > > > >
> > > > > 3) Tests
> > > > > 3.1) New functionality *MUST* be covered with unit tests for both
> > > > positive
> > > > > and negative use cases
> > > > > 3.2) All test suites *MUST* be run before merge to master..There
> > *MUST*
> > > > be
> > > > > no new test failures
> > > > >
> > > > > 4) Code style *MUST* be followed as per Ignite's Coding Guidelines
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > [1] https://www.ietf.org/rfc/rfc2119.txt
> > > > >
> > > > > On Fri, May 4, 2018 at 4:33 PM, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Dmitry,
> > > > > >
> > > > > > Yes, I'll do that in the nearest days.
> > > > > >
> > > > > > On Wed, Apr 25, 2018 at 8:24 PM, Dmitry Pavlov <
> > > dpavlov@gmail.com>
> > > > > > wrote:
> 

[GitHub] ignite pull request #3957: IGNITE-8430 implemented getCurrentCoordinatorForm...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-8430 implemented getCurrentCoordinatorFormatted method in Igni…

…teMXBean

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

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

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

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


commit 0aa57ba6e47baff658279e53d38f6364e2626fbf
Author: Anton Kalashnikov 
Date:   2018-05-08T09:26:57Z

IGNITE-8430 implemented getCurrentCoordinatorFormatted method in 
IgniteMXBean




---

Re: Ticket review checklist

[Andrey Kuznetsov]

Vladimir, checklist looks pleasant enough for me.

I'd like to suggest one minor change. In 1.6 *MUST* seems to be too strict,
*SHOULD* would be enough. It can be frustrating for API user if I explain
how to fix NPEs in a trivial way, for example.

2018-05-08 11:34 GMT+03:00 Anton Vinogradov :

> Alex,
>
> It is not sounds like that, obviously.
>
> Tests should cover all negative and positive cases.
> You should add enough tests to cover all cases.
>
> Sometimes one test can cover more than one case, so two tests *CAN*
> partially check same things.
> In case some cases already covered you should not create duplicates.
>
> вт, 8 мая 2018 г. в 10:19, Александр Меньшиков :
>
> > Vladimir, the 3.1 is a bit unclear for me. Which code coverage is
> > acceptable? Now it sounds like two tests are enough (one for positive and
> > one for negative cases).
> >
> > 2018-05-07 23:09 GMT+03:00 Dmitriy Setrakyan :
> >
> > > Is this list on the Wiki?
> > >
> > > On Mon, May 7, 2018 at 7:26 AM, Vladimir Ozerov 
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > This is the checklist I have at the moment. Please let me know if you
> > > have
> > > > any comments on existing items, or want to add or remove anything. It
> > > looks
> > > > like we may have not only strict rules, but *nice to have* points
> here
> > as
> > > > well with help of *MUST*, *SHOULD* and *MAY* words as per RFC2119
> [1].
> > So
> > > > please feel free to suggest optional items as well.
> > > >
> > > > 1) API
> > > > 1.1) API compatibility *MUST* be maintained between minor releases.
> Do
> > > not
> > > > remove existing methods or change their signatures, deprecate them
> > > instead
> > > > 1.2) Default behaviour "SHOULD NOT* be changed between minor
> releases,
> > > > unless absolutely needed. If change is made, it *MUST* be described
> in
> > > > "Migration Guide"
> > > > 1.3) New operation *MUST* be well-documented in code (javadoc,
> > > dotnetdoc):
> > > > documentation must contain method's purpose, description of
> parameters
> > > and
> > > > how their values affect the outcome, description of return value and
> > it's
> > > > default, behavior in negative cases, interaction with other
> operations
> > > and
> > > > components
> > > > 1.4) API parity between Java and .NET platforms *SHOULD* be
> maintained
> > > when
> > > > operation makes sense on both platforms. If method cannot be
> > implemented
> > > in
> > > > a platform immediately, new JIRA ticket *MUST* be created and linked
> to
> > > > current ticket
> > > > 1.5) API parity between thin clients (Java, .NET) *SHOULD* be
> > maintained
> > > > when operation makes sense on several clients. If method cannot be
> > > > implemented in a client immediately, new JIRA ticket *MUST* be
> created
> > > and
> > > > linked to current ticket
> > > > 1.6) All exceptions thrown to a user *MUST* have explanation how to
> > > > resolve, workaround or debug an error
> > > >
> > > > 2) Compatibility
> > > > 2.1) Persistence backward compatibility *MUST* be maintained between
> > > minor
> > > > releases. It should be possible to start newer version on data files
> > > > created by the previous version
> > > > 2.2) Thin client forward and backward compatibility *SHOULD* be
> > > maintained
> > > > between two consecutive minor releases. If compatibility cannot be
> > > > maintained it *MUST* be described in "Migration Guide"
> > > > 2.3) JDBC and ODBC forward and backward compatibility *SHOULD* be
> > > > maintained between two consecutive minor releases. If compatibility
> > > cannot
> > > > be maintained it *MUST* be described in "Migration Guide"
> > > >
> > > > 3) Tests
> > > > 3.1) New functionality *MUST* be covered with unit tests for both
> > > positive
> > > > and negative use cases
> > > > 3.2) All test suites *MUST* be run before merge to master..There
> *MUST*
> > > be
> > > > no new test failures
> > > >
> > > > 4) Code style *MUST* be followed as per Ignite's Coding Guidelines
> > > >
> > > > Vladimir.
> > > >
> > > > [1] https://www.ietf.org/rfc/rfc2119.txt
> > > >
> > > > On Fri, May 4, 2018 at 4:33 PM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > > wrote:
> > > >
> > > > > Hi Dmitry,
> > > > >
> > > > > Yes, I'll do that in the nearest days.
> > > > >
> > > > > On Wed, Apr 25, 2018 at 8:24 PM, Dmitry Pavlov <
> > dpavlov@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Igniters, the idea was related to small refactorings co-located
> with
> > > > main
> > > > >> change.
> > > > >>
> > > > >> Main change itself indicates that existing code did not meet the
> > > > criteria
> > > > >> of practice. Approving of standalone refactorings instead
> > contradicts
> > > > with
> > > > >> principle don't touch if it works. So I still like idea of
> > co-located
> > > > >> changes improving code, javadocs, style, etc.
> > > > >>
> > > > >> But let's not argue about this point now, let's summarize 

Re: Suggestion about Docker Swarm Services and Scaling Ignite automatically

[Jonathan Schoreels]

Hi Denis,

It seems like one workaround would be to configure the URL to one of the
manager node, and then the Docker API allows to loop over all the nodes net
interfaces :
https://github.com/bitsofinfo/docker-discovery-swarm-service#status. The
problem is it needs to know which node is a manager and which is a worker.

However, that's still a limitation of docker. After some searching on
"Docker Swarm Peer Discovery", I've found another implementation of the
similar problem, but for rabbitmq, which also relies on a third party
service discovery : Consul. 
Here : https://github.com/rabbitmq/rabbitmq-peer-discovery-consul
One integration with ignite can be found here :
https://github.com/andrea-zanetti/ignite-consul/blob/master/src/main/java/org/apache/ignite/spi/discovery/tcp/ipfinder/consul/TcpDiscoveryConsulIpFinder.java

One other interesting possibility would be to use a dns lookup based on "dig
 short" response. This implementation has been made for example
here for zookeeper :
https://github.com/itsaur/zookeeper-docker-swarm/blob/master/docker-swarm-entrypoint.sh.
 
Indeed, Docker Swarm updates a DNS with all the containers loadbalanced
behind. We could cycle through those information and get all the nodes IP.

I've personnally tested it with scaling, and the new IP addresses are
dynamically added :

bash-4.4# dig tasks.zookeeper1 +short
10.0.0.12

docker service scale stack_zookeeper1=2
stack_zookeeper1 scaled to 2
overall progress: 2 out of 2 tasks 
1/2: running   [==>] 
2/2: running   [==>] 
verify: Service converged 

bash-4.4# dig tasks.zookeeper1 +short
10.0.0.12
10.0.0.17

Any thoughts ? Isn't it a bit too low level ?

Jonathan



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

Re: Ticket review checklist

[Anton Vinogradov]

Alex,

It is not sounds like that, obviously.

Tests should cover all negative and positive cases.
You should add enough tests to cover all cases.

Sometimes one test can cover more than one case, so two tests *CAN*
partially check same things.
In case some cases already covered you should not create duplicates.

вт, 8 мая 2018 г. в 10:19, Александр Меньшиков :

> Vladimir, the 3.1 is a bit unclear for me. Which code coverage is
> acceptable? Now it sounds like two tests are enough (one for positive and
> one for negative cases).
>
> 2018-05-07 23:09 GMT+03:00 Dmitriy Setrakyan :
>
> > Is this list on the Wiki?
> >
> > On Mon, May 7, 2018 at 7:26 AM, Vladimir Ozerov 
> > wrote:
> >
> > > Igniters,
> > >
> > > This is the checklist I have at the moment. Please let me know if you
> > have
> > > any comments on existing items, or want to add or remove anything. It
> > looks
> > > like we may have not only strict rules, but *nice to have* points here
> as
> > > well with help of *MUST*, *SHOULD* and *MAY* words as per RFC2119 [1].
> So
> > > please feel free to suggest optional items as well.
> > >
> > > 1) API
> > > 1.1) API compatibility *MUST* be maintained between minor releases. Do
> > not
> > > remove existing methods or change their signatures, deprecate them
> > instead
> > > 1.2) Default behaviour "SHOULD NOT* be changed between minor releases,
> > > unless absolutely needed. If change is made, it *MUST* be described in
> > > "Migration Guide"
> > > 1.3) New operation *MUST* be well-documented in code (javadoc,
> > dotnetdoc):
> > > documentation must contain method's purpose, description of parameters
> > and
> > > how their values affect the outcome, description of return value and
> it's
> > > default, behavior in negative cases, interaction with other operations
> > and
> > > components
> > > 1.4) API parity between Java and .NET platforms *SHOULD* be maintained
> > when
> > > operation makes sense on both platforms. If method cannot be
> implemented
> > in
> > > a platform immediately, new JIRA ticket *MUST* be created and linked to
> > > current ticket
> > > 1.5) API parity between thin clients (Java, .NET) *SHOULD* be
> maintained
> > > when operation makes sense on several clients. If method cannot be
> > > implemented in a client immediately, new JIRA ticket *MUST* be created
> > and
> > > linked to current ticket
> > > 1.6) All exceptions thrown to a user *MUST* have explanation how to
> > > resolve, workaround or debug an error
> > >
> > > 2) Compatibility
> > > 2.1) Persistence backward compatibility *MUST* be maintained between
> > minor
> > > releases. It should be possible to start newer version on data files
> > > created by the previous version
> > > 2.2) Thin client forward and backward compatibility *SHOULD* be
> > maintained
> > > between two consecutive minor releases. If compatibility cannot be
> > > maintained it *MUST* be described in "Migration Guide"
> > > 2.3) JDBC and ODBC forward and backward compatibility *SHOULD* be
> > > maintained between two consecutive minor releases. If compatibility
> > cannot
> > > be maintained it *MUST* be described in "Migration Guide"
> > >
> > > 3) Tests
> > > 3.1) New functionality *MUST* be covered with unit tests for both
> > positive
> > > and negative use cases
> > > 3.2) All test suites *MUST* be run before merge to master..There *MUST*
> > be
> > > no new test failures
> > >
> > > 4) Code style *MUST* be followed as per Ignite's Coding Guidelines
> > >
> > > Vladimir.
> > >
> > > [1] https://www.ietf.org/rfc/rfc2119.txt
> > >
> > > On Fri, May 4, 2018 at 4:33 PM, Vladimir Ozerov 
> > > wrote:
> > >
> > > > Hi Dmitry,
> > > >
> > > > Yes, I'll do that in the nearest days.
> > > >
> > > > On Wed, Apr 25, 2018 at 8:24 PM, Dmitry Pavlov <
> dpavlov@gmail.com>
> > > > wrote:
> > > >
> > > >> Igniters, the idea was related to small refactorings co-located with
> > > main
> > > >> change.
> > > >>
> > > >> Main change itself indicates that existing code did not meet the
> > > criteria
> > > >> of practice. Approving of standalone refactorings instead
> contradicts
> > > with
> > > >> principle don't touch if it works. So I still like idea of
> co-located
> > > >> changes improving code, javadocs, style, etc.
> > > >>
> > > >> But let's not argue about this point now, let's summarize the
> > undisputed
> > > >> points and add it to the wiki. Vladimir, would you please do it?
> > > >>
> > > >>
> > > >> ср, 25 апр. 2018 г. в 16:42, Nikolay Izhikov :
> > > >>
> > > >> > Igniters,
> > > >> >
> > > >> > I agree with Vova.
> > > >> >
> > > >> > Don't fix if it works!
> > > >> >
> > > >> > If you 100% sure then it a useful addition to the product - just
> > make
> > > a
> > > >> > separate ticket.
> > > >> >
> > > >> > В Ср, 25/04/2018 в 11:44 +0300, Vladimir Ozerov пишет:
> > > >> > > Guys,
> > > >> > >
> > > >> > > The problem with 

[jira] [Created] (IGNITE-8451) [ML] Refactor Labeled Dataset: remove unused methods and fields

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8451:


 Summary: [ML] Refactor Labeled Dataset: remove unused methods and 
fields
 Key: IGNITE-8451
 URL: https://issues.apache.org/jira/browse/IGNITE-8451
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[jira] [Created] (IGNITE-8450) [ML] Cleanup the ML package: remove unused vector/matrix classes

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8450:


 Summary: [ML] Cleanup the ML package: remove unused vector/matrix 
classes
 Key: IGNITE-8450
 URL: https://issues.apache.org/jira/browse/IGNITE-8450
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[GitHub] ignite pull request #3956: IGNITE-4150

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-4150



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

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

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

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


commit 32f2540d20223539e5a587993fa3e81d0d02961d
Author: devozerov 
Date:   2018-05-08T07:16:28Z

IGNITE-4150: Updated H2 version.




---

Re: Ticket review checklist

[Александр Меньшиков]

Vladimir, the 3.1 is a bit unclear for me. Which code coverage is
acceptable? Now it sounds like two tests are enough (one for positive and
one for negative cases).

2018-05-07 23:09 GMT+03:00 Dmitriy Setrakyan :

> Is this list on the Wiki?
>
> On Mon, May 7, 2018 at 7:26 AM, Vladimir Ozerov 
> wrote:
>
> > Igniters,
> >
> > This is the checklist I have at the moment. Please let me know if you
> have
> > any comments on existing items, or want to add or remove anything. It
> looks
> > like we may have not only strict rules, but *nice to have* points here as
> > well with help of *MUST*, *SHOULD* and *MAY* words as per RFC2119 [1]. So
> > please feel free to suggest optional items as well.
> >
> > 1) API
> > 1.1) API compatibility *MUST* be maintained between minor releases. Do
> not
> > remove existing methods or change their signatures, deprecate them
> instead
> > 1.2) Default behaviour "SHOULD NOT* be changed between minor releases,
> > unless absolutely needed. If change is made, it *MUST* be described in
> > "Migration Guide"
> > 1.3) New operation *MUST* be well-documented in code (javadoc,
> dotnetdoc):
> > documentation must contain method's purpose, description of parameters
> and
> > how their values affect the outcome, description of return value and it's
> > default, behavior in negative cases, interaction with other operations
> and
> > components
> > 1.4) API parity between Java and .NET platforms *SHOULD* be maintained
> when
> > operation makes sense on both platforms. If method cannot be implemented
> in
> > a platform immediately, new JIRA ticket *MUST* be created and linked to
> > current ticket
> > 1.5) API parity between thin clients (Java, .NET) *SHOULD* be maintained
> > when operation makes sense on several clients. If method cannot be
> > implemented in a client immediately, new JIRA ticket *MUST* be created
> and
> > linked to current ticket
> > 1.6) All exceptions thrown to a user *MUST* have explanation how to
> > resolve, workaround or debug an error
> >
> > 2) Compatibility
> > 2.1) Persistence backward compatibility *MUST* be maintained between
> minor
> > releases. It should be possible to start newer version on data files
> > created by the previous version
> > 2.2) Thin client forward and backward compatibility *SHOULD* be
> maintained
> > between two consecutive minor releases. If compatibility cannot be
> > maintained it *MUST* be described in "Migration Guide"
> > 2.3) JDBC and ODBC forward and backward compatibility *SHOULD* be
> > maintained between two consecutive minor releases. If compatibility
> cannot
> > be maintained it *MUST* be described in "Migration Guide"
> >
> > 3) Tests
> > 3.1) New functionality *MUST* be covered with unit tests for both
> positive
> > and negative use cases
> > 3.2) All test suites *MUST* be run before merge to master..There *MUST*
> be
> > no new test failures
> >
> > 4) Code style *MUST* be followed as per Ignite's Coding Guidelines
> >
> > Vladimir.
> >
> > [1] https://www.ietf.org/rfc/rfc2119.txt
> >
> > On Fri, May 4, 2018 at 4:33 PM, Vladimir Ozerov 
> > wrote:
> >
> > > Hi Dmitry,
> > >
> > > Yes, I'll do that in the nearest days.
> > >
> > > On Wed, Apr 25, 2018 at 8:24 PM, Dmitry Pavlov 
> > > wrote:
> > >
> > >> Igniters, the idea was related to small refactorings co-located with
> > main
> > >> change.
> > >>
> > >> Main change itself indicates that existing code did not meet the
> > criteria
> > >> of practice. Approving of standalone refactorings instead contradicts
> > with
> > >> principle don't touch if it works. So I still like idea of co-located
> > >> changes improving code, javadocs, style, etc.
> > >>
> > >> But let's not argue about this point now, let's summarize the
> undisputed
> > >> points and add it to the wiki. Vladimir, would you please do it?
> > >>
> > >>
> > >> ср, 25 апр. 2018 г. в 16:42, Nikolay Izhikov :
> > >>
> > >> > Igniters,
> > >> >
> > >> > I agree with Vova.
> > >> >
> > >> > Don't fix if it works!
> > >> >
> > >> > If you 100% sure then it a useful addition to the product - just
> make
> > a
> > >> > separate ticket.
> > >> >
> > >> > В Ср, 25/04/2018 в 11:44 +0300, Vladimir Ozerov пишет:
> > >> > > Guys,
> > >> > >
> > >> > > The problem with in-place refactorings is that you increase
> affected
> > >> > scope.
> > >> > > It is not uncommon to break compatibility or public contracts with
> > >> even
> > >> > > minor things. E.g. recently we decided drop org.jsr166 package in
> > >> favor
> > >> > of
> > >> > > Java 8 classes. Innocent change. Result - broken storage. Another
> > >> problem
> > >> > > is conflicts. It is not uncommon to have long-lived branches which
> > we
> > >> > need
> > >> > > to merge with master over and over again. And a lot of
> refactorings
> > >> cause
> > >> > > conflicts. It is much easier to resolve them if you know that
> logic
> > >> was
> > >> > 

[GitHub] ignite pull request #3952: IGNITE-8447: .Net support of DataStreamer#perThre...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: IGNITE-3999 review

[Vladimir Ozerov]

Hi,

I provided my comments in the ticket.

On Tue, May 8, 2018 at 5:54 AM, Amir Akhmedov 
wrote:

> Hi Nikolay, Dmitry Pavlov,
> Can you take a look at this PR or maybe you have an idea when it probably
> can be reviewed?
>
> Thanks,
> Amir
>
> On Wed, Apr 11, 2018 at 10:57 AM, Nikolay Izhikov 
> wrote:
>
> > Hello, Amir.
> >
> > Sorry, but no.
> >
> > I will take a look in a next few days.
> >
> >
> > В Ср, 11/04/2018 в 14:51 +, Amir Akhmedov пишет:
> > > Hi Nikolay,
> > >
> > > Did you have a chance to check my changes?
> > >
> > > Thanks,
> > > Amir
> >
>

[GitHub] ignite pull request #3946: IGNITE-8434 .NET: Fix service proxies on .NET Cor...

[asfgit]

Github user asfgit closed the pull request at:

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


---