Re: Removing "fabric" from Ignite binary package name

[Peter Ivanov]

The task was ready long ago, but community failed to review and merge it
¯\_(ツ)_/¯
Not being a committer, my capabilities of introducing such changes are
limited.

I will update code during this week and will pass for review once again.


On Wed, 1 Aug 2018 at 00:24, Dmitriy Setrakyan 
wrote:

> Yes, agree, fabric has to be removed. If it is done in 2.7, would be great!
>
> On Tue, Jul 31, 2018 at 2:18 PM, Denis Magda  wrote:
>
> > Peter, folks,
> >
> > It's weird, but we have been failing to introduce this minor change since
> > December. Can we get it done for 2.7 that is being discussed at the
> moment?
> > Are there any technical issues that block you from merging the changes?
> >
> > --
> > Denis
> >
> > On Thu, Jun 7, 2018 at 10:03 PM Peter Ivanov 
> wrote:
> >
> > > Ok, then I will update issue code and start preparation for build
> > > configuration changes.
> > >
> > >
> > > On Thu, 7 Jun 2018 at 23:41, Denis Magda  wrote:
> > >
> > > > >
> > > > > With which one — current implementation in issue?
> > > >
> > > >
> > > > That's the answer to your question:
> > > >
> > > > 1. quickly fix all of them (can be solved by preliminary
> preparations —
> > > > searching for -fabric- usages in build configuration);
> > > > 2. update all branches to master because otherwise old branch
> will
> > > stop
> > > > building.
> > > >
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Thu, Jun 7, 2018 at 1:12 PM, Petr Ivanov 
> > wrote:
> > > >
> > > > >
> > > > > > On 7 Jun 2018, at 23:04, Denis Magda  wrote:
> > > > > >
> > > > > > I'm fine with the suggested approach.
> > > > >
> > > > > With which one — current implementation in issue?
> > > > >
> > > > >
> > > > > > However, not sure we need to update
> > > > > > all the branches. Can't branch owners just pull the changes back
> > from
> > > > > > master if the plan to merge back later?
> > > > >
> > > > > Of course, we as an initiative group of this issue should do
> nothing,
> > > it
> > > > > will lie on shoulders of developers.
> > > > >
> > > > >
> > > > > >
> > > > > > --
> > > > > > Denis
> > > > > >
> > > > > > On Thu, Jun 7, 2018 at 12:57 PM, Petr Ivanov <
> mr.wei...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> Denis,
> > > > > >>
> > > > > >>
> > > > > >> The most simple approach — repack and rearchive binary archive
> > after
> > > > > >> release build, however that would not resolve the problem
> globally
> > > > (and
> > > > > >> will require fixing every build configuration we have on
> > TeamCity).
> > > > > >> Current approach implemented in task — creates already correct
> > > folder
> > > > > and
> > > > > >> binary archive name, but old name (with -fabric-) is used in
> > almost
> > > > > every
> > > > > >> build configuration too and merge code to master will require
> to:
> > > > > >>1. quickly fix all of them (can be solved by preliminary
> > > > preparations
> > > > > >> — searching for -fabric- usages in build configuration);
> > > > > >>2. update all branches to master because otherwise old branch
> > > will
> > > > > >> stop building.
> > > > > >>
> > > > > >> WDYT?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>> On 7 Jun 2018, at 22:42, Denis Magda 
> wrote:
> > > > > >>>
> > > > > >>> Petr,
> > > > > >>>
> > > > > >>> Thanks for pulling up the conversation.
> > > > > >>>
> > > > > >>> I still prefer us not to complicate the things and just remove
> > > > "fabric"
> > > > > >>> from the *package name*. Use the easiest way possible.
> > > > > >>>
> > > > > >>> Personally, I don't care about Hadoop and would not suggest the
> > > > > community
> > > > > >>> wasting its time on it. So, just rename the suffixes/prefixes
> of
> > > the
> > > > > >> build
> > > > > >>> files the way you like to address Anton's concerns.
> > > > > >>>
> > > > > >>> --
> > > > > >>> Denis
> > > > > >>>
> > > > > >>>
> > > > > >>> On Thu, Jun 7, 2018 at 1:49 AM, Petr Ivanov <
> mr.wei...@gmail.com
> > >
> > > > > wrote:
> > > > > >>>
> > > > >  Igniters,
> > > > > 
> > > > > 
> > > > >  Lets define once again what should be done in this [1] task?
> > > > >  If current implementation is good, than I’ll update it to
> master
> > > and
> > > > > >> pass
> > > > >  for review.
> > > > > 
> > > > >  Yet, there is other part of the task which concerns our build
> > > server
> > > > > — I
> > > > >  assume that almost all our build configurations will fail due
> to
> > > > name
> > > > >  change and there is no simple way of updating configurations
> > other
> > > > > then
> > > > >  merge task to master and start fixing failing builds.
> > > > > 
> > > > > 
> > > > >  [1] https://issues.apache.org/jira/browse/IGNITE-7251
> > > > > 
> > > > > 
> > > > > 
> > > > > > On 10 Feb 2018, at 01:56, Denis Magda 
> > wrote:
> > > > > >
> > > > > >> I don't think we necessarily need to remove 'fabric' word
> from
> > > > every
> > > > >  file
> > > > > >> in the

Re: Assign JIRA tickets to someone else

[Maxim Muzafarov]

Folks,

I don't think we need additional notification for catching attention of
some community
experts. Such notifications can be overused by other participants.
Developer mail list
the best place we have for any discussions.

What I really would like to have is the list of community members\experts
and their zones
of Ignite project code responsibilities. May be such list already exists,
does it?

As for me, I think we should pose right the complexity of the issue at the
moment
of their creation. Ask expert to provide some high level implementation
details and
keep it unassingned, so anyone can take it.

On Wed, 1 Aug 2018 at 01:09 Nikolay Izhikov  wrote:

> How about mention desired expert with some predefined message?
> So expert can setup simple email filter and know about tickets that have
> to be done.
>
> Example:
>
> "[~dpavlov] TFY" - ticket for you.
>
> В Вт, 31/07/2018 в 14:04 -0700, Dmitriy Setrakyan пишет:
> > Dmitriy,
> >
> > I would agree with everything you are saying. There are some tickets,
> > however, that cannot be done by just anyone and preferably have to be
> > looked at by certain domain experts. In those cases only it would be OK
> to
> > assign a ticket explicitly in my view. For all other cases we should
> allow
> > the community pick up a ticket they want to work on.
> >
> > D.
> >
> > On Tue, Jul 31, 2018 at 10:34 AM, Dmitriy Pavlov 
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > Ignite is complex project and sometimes we know
> > > 1. who can solve the issue
> > > 2. and we would like that particular contributor would take an issue.
> > >
> > > In the same time "in an open source community where everything is
> > > distributed, asynchronous and volunteer work we should leave the issues
> > > open to anyone until someone volunteers to work on it."
> > >
> > > It seems it is not prohibited by Apache to assign it directly, in the
> same
> > > time it is better for community grown to avoid it:
> > > "Assigning things to people seems the role of a project manager that
> has
> > > some sort of power over the managed team. Speaking from experience I
> do not
> > > take it nicely when someone that uses the project I am a volunteer at
> > > (which I might now know ) "assigns work" to me."
> > >
> > > Please find Apache mentors' comments on this:
> > > https://lists.apache.org/thread.html/c6013b99940de32aae831a0b76e8fd
> > > 53febe5040e9e0d67abb4f62a5@%3Cdev.community.apache.org%3E
> > >
> > >
> > > Please share you vision.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >

-- 
--
Maxim Muzafarov

Re: Apache Flink Sink + Ignite: Ouch! Argument is invalid

[Saikat Maitra]

Hi,

I have submitted the below PR, please review and share feedback.


Jira: https://issues.apache.org/jira/browse/IGNITE-8697
PR : https://github.com/apache/ignite/pull/4398
Review : https://reviews.ignite.apache.org/ignite/review/IGNT-CR-695

Regards,
Saikat


On Thu, Jul 26, 2018 at 11:26 PM, Saikat Maitra 
wrote:

> Hi Andrew,
>
> As we discussed I have updated the PR, please take a look. If it looks
> good then I can go ahead and merge the changes.
>
> PR : https://github.com/apache/ignite/pull/4398
> Review : https://reviews.ignite.apache.org/ignite/review/IGNT-CR-695
>
> Regards,
> Saikat
>
> On Thu, Jul 26, 2018 at 11:25 PM, Saikat Maitra 
> wrote:
>
>> Hi Ray,
>>
>> We will need to use igniteSink.setAllowOverwrite(true) flag so that
>> latest computed values are stored in cache. Also we need not call
>> igniteSink.open(new Configuration)
>>
>> Please take a look into the below modified wordCount sample.
>>
>> https://github.com/samaitra/flink-fn/blob/master/flink-fn/sr
>> c/main/scala/com/samaitra/WordCount.scala
>>
>> Please review and share feedback
>>
>> Regards
>> Saikat
>>
>> On Thu, Jul 26, 2018 at 1:16 AM, Ray  wrote:
>>
>>> Hi Saikat,
>>>
>>> The results flink calculated before sending to sink is correct, but the
>>> results in Ignite is not correct.
>>> You can remove the sink and print the stream content to validate my
>>> point.
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>>>
>>
>>
>

[jira] [Created] (IGNITE-9150) Web console: incorrect text of cluster acivation component in corner case

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-9150:
--

 Summary: Web  console: incorrect text of cluster acivation 
component in corner case
 Key: IGNITE-9150
 URL: https://issues.apache.org/jira/browse/IGNITE-9150
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov


# deactivate a cluster
# switch to cluster w\o persistent
# switch back to the first cluster
- component prints 'Activating' but should 'Deactivating'

The reason is that Ignite has no it own state 'activating(deactivating) in 
progress' and the current implementation is a workaround only.



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

Re: Spark DataFrames With Cache Key and Value Objects

[Valentin Kulichenko]

I don't think there are exact plans to remove _key and _value fields as
it's pretty hard considering the fact that many users use them and that
they are deeply integrated into the product. However, we already had
multiple usability and other issues due to their existence, and while
fixing them we gradually get rid of _key/_val on public API. Hard to tell
when we will be able to completely deprecate/remove these fields, but we
definitely should avoid building new features based on them.

On top of that, I also don't like this approach because it doesn't seem to
be Spark-friendly to me. That's not how they typically create typed
datasets (I already provided a documentation link [1] with examples
earlier).

>From API standpoint, I think we should do the following:
1. Add 'IgniteSparkSession#createDataset(IgniteCache[K, V] cache):
Dataset[(K, V)]' method that would create a dataset based on a cache.
2. (Scala only) Introduce 'IgniteCache.toDS()' that would do the same, but
via implicit conversions instead of SparkSession extension.

On implementation level, we can use SqlQuery API (not SqlFieldQuery) that
is specifically designed to return key-value pairs instead of specific
fields, while still providing all SQL capabilities.

*Nikolay*, does this makes sense to you? Is it feasible and how hard would
it be to implement? How much of the existing code can we reuse (I believe
it should it be majority of it)?

[1]
https://spark.apache.org/docs/2.3.1/sql-programming-guide.html#creating-datasets

-Val

On Tue, Jul 31, 2018 at 2:03 PM Denis Magda  wrote:

> Hello folks,
>
> The documentation goes with a small reference about _key and _val usage,
> and only for Ignite SQL APIs (Java, Net, C++). I tried to clean up all the
> documentation code snippets.
>
> As for the GitHub examples, they require a major overhaul. Instead of _key
> and _val usage, we need to use SQL fields. Hopefully, someone will groom
> the examples.
>
> Considering this, I wouldn't suggest us exposing _key and _val in other
> places like Spark. Are there any alternatives to this approach?
>
> --
> Denis
>
>
>
> On Tue, Jul 31, 2018 at 2:49 AM Nikolay Izhikov 
> wrote:
>
> > Hello, Igniters.
> >
> > Valentin,
> >
> > > We never recommend to use these fields
> >
> > Actually, we did:
> >
> > * Documentation [1]. Please, see "Predefined Fields" section.
> > * Java Example [2]
> > * DotNet Example [3]
> > * Scala Example [4]
> >
> > > ...hopefully will be removed altogether one day
> >
> > This is new for me.
> >
> > Do we have specific plans for it?
> >
> > [1] https://apacheignite-sql.readme.io/docs/schema-and-indexes
> > [2]
> >
> https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/sql/SqlDmlExample.java#L88
> > [3]
> >
> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Sql/SqlDmlExample.cs#L91
> > [4]
> >
> https://github.com/apache/ignite/blob/master/examples/src/main/scala/org/apache/ignite/scalar/examples/ScalarCachePopularNumbersExample.scala#L124
> >
> > В Пт, 27/07/2018 в 15:22 -0700, Valentin Kulichenko пишет:
> > > Stuart,
> > >
> > > _key and _val fields is quite a dirty hack that was added years ago and
> > is
> > > virtually never used now. We never recommend to use these fields and I
> > > would definitely avoid building new features based on them.
> > >
> > > Having said that, I'm not arguing the use case, but we need better
> > > implementation approach here. I suggest we think it over and come back
> to
> > > this next week :) I'm sure Nikolay will also chime in and share his
> > > thoughts.
> > >
> > > -Val
> > >
> > > On Fri, Jul 27, 2018 at 12:39 PM Stuart Macdonald 
> > wrote:
> > >
> > > > If your predicates and joins are expressed in Spark SQL, you cannot
> > > > currently optimise those and also gain access to the key/val objects.
> > If
> > > > you went without the Ignite Spark SQL optimisations and expressed
> your
> > > > query in Ignite SQL, you still need to use the _key/_val columns. The
> > > > Ignite documentation has this specific example using the _val column
> > (right
> > > > at the end):
> > > > https://apacheignite-fs.readme.io/docs/ignitecontext-igniterdd
> > > >
> > > > Stuart.
> > > >
> > > > On 27 Jul 2018, at 20:05, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com>
> > > > wrote:
> > > >
> > > > Well, the second approach would use the optimizations, no?
> > > >
> > > > -Val
> > > >
> > > >
> > > > On Fri, Jul 27, 2018 at 11:49 AM Stuart Macdonald  >
> > > > wrote:
> > > >
> > > > Val,
> > > >
> > > >
> > > > Yes you can already get access to the cache objects as an RDD or
> > > >
> > > > Dataset but you can’t use the Ignite-optimised DataFrames with these
> > > >
> > > > mechanisms. Optimised DataFrames have to be passed through Spark
> SQL’s
> > > >
> > > > Catalyst engine to allow for predicate pushdown to Ignite. So the
> > > >
> > > > usecase we’re talking about here 

Re: Local Continuous Query

[Valentin Kulichenko]

Denis,

I think this is correct behavior. If you deploy a local query on a single
node with a REPLICATED cache, you expect to be notified with all the
updates. This is not the case for PARTITIONED caches.

-Val

On Tue, Jul 31, 2018 at 3:19 AM Denis Mekhanikov 
wrote:

> Igniters,
>
> As you may know, *ContinuousQuery
> <
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/ContinuousQuery.html
> >*
> class
> extends the *Query
> <
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/Query.html
> >
> *class, so *setLocal *method is applicable to *ContinuousQuery *as well.
> Behaviour of such queries is not documented at all, and it's unclear, how
> they should work.
>
> In particular, local continuous queries work differently for partitioned
> and replicated caches, even if a node contains all backup partitions.
> Listener for a local continuous query is invoked only for primary
> partitions in case of a partitioned cache, and for all partitions in case
> of a replicated cache.
>
> Is it supposed to work like this?
>
> I agree to leave this behaviour untouched, but it certainly needs to be
> documented.
>
> Denis
>

DataFrame integration does not support ARRAY type

[Valentin Kulichenko]

Hi Nikolay,

Can you please take a look at this thread on SO?
https://stackoverflow.com/questions/51621280/saving-a-spark-dataset-to-apache-ignite-with-array-column-and-savemode-overwrite

Looks like org.apache.ignite.spark.impl.QueryUtils#dataType method should
also support ArrayType as one of the cases. Currently it doesn't and throws
an exception.

Is it a bug?

-Val

Re: Assign JIRA tickets to someone else

[Nikolay Izhikov]

How about mention desired expert with some predefined message?
So expert can setup simple email filter and know about tickets that have to be 
done.

Example:

"[~dpavlov] TFY" - ticket for you.

В Вт, 31/07/2018 в 14:04 -0700, Dmitriy Setrakyan пишет:
> Dmitriy,
> 
> I would agree with everything you are saying. There are some tickets,
> however, that cannot be done by just anyone and preferably have to be
> looked at by certain domain experts. In those cases only it would be OK to
> assign a ticket explicitly in my view. For all other cases we should allow
> the community pick up a ticket they want to work on.
> 
> D.
> 
> On Tue, Jul 31, 2018 at 10:34 AM, Dmitriy Pavlov 
> wrote:
> 
> > Hi Igniters,
> > 
> > Ignite is complex project and sometimes we know
> > 1. who can solve the issue
> > 2. and we would like that particular contributor would take an issue.
> > 
> > In the same time "in an open source community where everything is
> > distributed, asynchronous and volunteer work we should leave the issues
> > open to anyone until someone volunteers to work on it."
> > 
> > It seems it is not prohibited by Apache to assign it directly, in the same
> > time it is better for community grown to avoid it:
> > "Assigning things to people seems the role of a project manager that has
> > some sort of power over the managed team. Speaking from experience I do not
> > take it nicely when someone that uses the project I am a volunteer at
> > (which I might now know ) "assigns work" to me."
> > 
> > Please find Apache mentors' comments on this:
> > https://lists.apache.org/thread.html/c6013b99940de32aae831a0b76e8fd
> > 53febe5040e9e0d67abb4f62a5@%3Cdev.community.apache.org%3E
> > 
> > 
> > Please share you vision.
> > 
> > Sincerely,
> > Dmitriy Pavlov
> > 

signature.asc
Description: This is a digitally signed message part

Re: Removing "fabric" from Ignite binary package name

[Dmitriy Setrakyan]

Yes, agree, fabric has to be removed. If it is done in 2.7, would be great!

On Tue, Jul 31, 2018 at 2:18 PM, Denis Magda  wrote:

> Peter, folks,
>
> It's weird, but we have been failing to introduce this minor change since
> December. Can we get it done for 2.7 that is being discussed at the moment?
> Are there any technical issues that block you from merging the changes?
>
> --
> Denis
>
> On Thu, Jun 7, 2018 at 10:03 PM Peter Ivanov  wrote:
>
> > Ok, then I will update issue code and start preparation for build
> > configuration changes.
> >
> >
> > On Thu, 7 Jun 2018 at 23:41, Denis Magda  wrote:
> >
> > > >
> > > > With which one — current implementation in issue?
> > >
> > >
> > > That's the answer to your question:
> > >
> > > 1. quickly fix all of them (can be solved by preliminary preparations —
> > > searching for -fabric- usages in build configuration);
> > > 2. update all branches to master because otherwise old branch will
> > stop
> > > building.
> > >
> > >
> > > --
> > > Denis
> > >
> > > On Thu, Jun 7, 2018 at 1:12 PM, Petr Ivanov 
> wrote:
> > >
> > > >
> > > > > On 7 Jun 2018, at 23:04, Denis Magda  wrote:
> > > > >
> > > > > I'm fine with the suggested approach.
> > > >
> > > > With which one — current implementation in issue?
> > > >
> > > >
> > > > > However, not sure we need to update
> > > > > all the branches. Can't branch owners just pull the changes back
> from
> > > > > master if the plan to merge back later?
> > > >
> > > > Of course, we as an initiative group of this issue should do nothing,
> > it
> > > > will lie on shoulders of developers.
> > > >
> > > >
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Thu, Jun 7, 2018 at 12:57 PM, Petr Ivanov 
> > > > wrote:
> > > > >
> > > > >> Denis,
> > > > >>
> > > > >>
> > > > >> The most simple approach — repack and rearchive binary archive
> after
> > > > >> release build, however that would not resolve the problem globally
> > > (and
> > > > >> will require fixing every build configuration we have on
> TeamCity).
> > > > >> Current approach implemented in task — creates already correct
> > folder
> > > > and
> > > > >> binary archive name, but old name (with -fabric-) is used in
> almost
> > > > every
> > > > >> build configuration too and merge code to master will require to:
> > > > >>1. quickly fix all of them (can be solved by preliminary
> > > preparations
> > > > >> — searching for -fabric- usages in build configuration);
> > > > >>2. update all branches to master because otherwise old branch
> > will
> > > > >> stop building.
> > > > >>
> > > > >> WDYT?
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On 7 Jun 2018, at 22:42, Denis Magda  wrote:
> > > > >>>
> > > > >>> Petr,
> > > > >>>
> > > > >>> Thanks for pulling up the conversation.
> > > > >>>
> > > > >>> I still prefer us not to complicate the things and just remove
> > > "fabric"
> > > > >>> from the *package name*. Use the easiest way possible.
> > > > >>>
> > > > >>> Personally, I don't care about Hadoop and would not suggest the
> > > > community
> > > > >>> wasting its time on it. So, just rename the suffixes/prefixes of
> > the
> > > > >> build
> > > > >>> files the way you like to address Anton's concerns.
> > > > >>>
> > > > >>> --
> > > > >>> Denis
> > > > >>>
> > > > >>>
> > > > >>> On Thu, Jun 7, 2018 at 1:49 AM, Petr Ivanov  >
> > > > wrote:
> > > > >>>
> > > >  Igniters,
> > > > 
> > > > 
> > > >  Lets define once again what should be done in this [1] task?
> > > >  If current implementation is good, than I’ll update it to master
> > and
> > > > >> pass
> > > >  for review.
> > > > 
> > > >  Yet, there is other part of the task which concerns our build
> > server
> > > > — I
> > > >  assume that almost all our build configurations will fail due to
> > > name
> > > >  change and there is no simple way of updating configurations
> other
> > > > then
> > > >  merge task to master and start fixing failing builds.
> > > > 
> > > > 
> > > >  [1] https://issues.apache.org/jira/browse/IGNITE-7251
> > > > 
> > > > 
> > > > 
> > > > > On 10 Feb 2018, at 01:56, Denis Magda 
> wrote:
> > > > >
> > > > >> I don't think we necessarily need to remove 'fabric' word from
> > > every
> > > >  file
> > > > >> in the project, we just need to rename the name of
> downloadable
> > > > >> package.
> > > > >
> > > > > Couldn’t say it better than you, Val. Thanks for pitching in :)
> > > This
> > > > is
> > > >  exactly what the ticket is about.
> > > > >
> > > > > —
> > > > > Denis
> > > > >
> > > > >> On Feb 9, 2018, at 11:53 AM, Valentin Kulichenko <
> > > >  valentin.kuliche...@gmail.com> wrote:
> > > > >>
> > > > >> Anton,
> > > > >>
> > > > >> I don't think we necessarily need to remove 'fabric' word from
> > > every
> > > >  file
> > > > >> in the project, we just need to rename the name of
> downloadable

Re: Removing "fabric" from Ignite binary package name

[Denis Magda]

Peter, folks,

It's weird, but we have been failing to introduce this minor change since
December. Can we get it done for 2.7 that is being discussed at the moment?
Are there any technical issues that block you from merging the changes?

--
Denis

On Thu, Jun 7, 2018 at 10:03 PM Peter Ivanov  wrote:

> Ok, then I will update issue code and start preparation for build
> configuration changes.
>
>
> On Thu, 7 Jun 2018 at 23:41, Denis Magda  wrote:
>
> > >
> > > With which one — current implementation in issue?
> >
> >
> > That's the answer to your question:
> >
> > 1. quickly fix all of them (can be solved by preliminary preparations —
> > searching for -fabric- usages in build configuration);
> > 2. update all branches to master because otherwise old branch will
> stop
> > building.
> >
> >
> > --
> > Denis
> >
> > On Thu, Jun 7, 2018 at 1:12 PM, Petr Ivanov  wrote:
> >
> > >
> > > > On 7 Jun 2018, at 23:04, Denis Magda  wrote:
> > > >
> > > > I'm fine with the suggested approach.
> > >
> > > With which one — current implementation in issue?
> > >
> > >
> > > > However, not sure we need to update
> > > > all the branches. Can't branch owners just pull the changes back from
> > > > master if the plan to merge back later?
> > >
> > > Of course, we as an initiative group of this issue should do nothing,
> it
> > > will lie on shoulders of developers.
> > >
> > >
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Thu, Jun 7, 2018 at 12:57 PM, Petr Ivanov 
> > > wrote:
> > > >
> > > >> Denis,
> > > >>
> > > >>
> > > >> The most simple approach — repack and rearchive binary archive after
> > > >> release build, however that would not resolve the problem globally
> > (and
> > > >> will require fixing every build configuration we have on TeamCity).
> > > >> Current approach implemented in task — creates already correct
> folder
> > > and
> > > >> binary archive name, but old name (with -fabric-) is used in almost
> > > every
> > > >> build configuration too and merge code to master will require to:
> > > >>1. quickly fix all of them (can be solved by preliminary
> > preparations
> > > >> — searching for -fabric- usages in build configuration);
> > > >>2. update all branches to master because otherwise old branch
> will
> > > >> stop building.
> > > >>
> > > >> WDYT?
> > > >>
> > > >>
> > > >>
> > > >>> On 7 Jun 2018, at 22:42, Denis Magda  wrote:
> > > >>>
> > > >>> Petr,
> > > >>>
> > > >>> Thanks for pulling up the conversation.
> > > >>>
> > > >>> I still prefer us not to complicate the things and just remove
> > "fabric"
> > > >>> from the *package name*. Use the easiest way possible.
> > > >>>
> > > >>> Personally, I don't care about Hadoop and would not suggest the
> > > community
> > > >>> wasting its time on it. So, just rename the suffixes/prefixes of
> the
> > > >> build
> > > >>> files the way you like to address Anton's concerns.
> > > >>>
> > > >>> --
> > > >>> Denis
> > > >>>
> > > >>>
> > > >>> On Thu, Jun 7, 2018 at 1:49 AM, Petr Ivanov 
> > > wrote:
> > > >>>
> > >  Igniters,
> > > 
> > > 
> > >  Lets define once again what should be done in this [1] task?
> > >  If current implementation is good, than I’ll update it to master
> and
> > > >> pass
> > >  for review.
> > > 
> > >  Yet, there is other part of the task which concerns our build
> server
> > > — I
> > >  assume that almost all our build configurations will fail due to
> > name
> > >  change and there is no simple way of updating configurations other
> > > then
> > >  merge task to master and start fixing failing builds.
> > > 
> > > 
> > >  [1] https://issues.apache.org/jira/browse/IGNITE-7251
> > > 
> > > 
> > > 
> > > > On 10 Feb 2018, at 01:56, Denis Magda  wrote:
> > > >
> > > >> I don't think we necessarily need to remove 'fabric' word from
> > every
> > >  file
> > > >> in the project, we just need to rename the name of downloadable
> > > >> package.
> > > >
> > > > Couldn’t say it better than you, Val. Thanks for pitching in :)
> > This
> > > is
> > >  exactly what the ticket is about.
> > > >
> > > > —
> > > > Denis
> > > >
> > > >> On Feb 9, 2018, at 11:53 AM, Valentin Kulichenko <
> > >  valentin.kuliche...@gmail.com> wrote:
> > > >>
> > > >> Anton,
> > > >>
> > > >> I don't think we necessarily need to remove 'fabric' word from
> > every
> > >  file
> > > >> in the project, we just need to rename the name of downloadable
> > >  package. Is
> > > >> there any other place where 'fabric' is exposed to the user?
> > > >>
> > > >> If that's the case, it should not be a big change, no?
> > > >>
> > > >> -Val
> > > >>
> > > >> On Fri, Feb 9, 2018 at 3:49 AM, Anton Vinogradov <
> > >  avinogra...@gridgain.com>
> > > >> wrote:
> > > >>
> > > >>> Denis,
> > > >>>
> > > >>> You're proposing changes without viewing a code :)

Update Ignite description in .NET docs and NuGet

[Denis Magda]

Hey Pavel,

Could you help to update Ignite definition in accordance to the website?
.NET docs [1] and NuGet [2] packages define it as In-Memory Data Fabric and
data grid.

The definition needs to be updated to the following:

   - Project name - Apache Ignite
   - Definition - Apache Ignite is a memory-centric distributed database,
   caching, and processing platform for transactional, analytical, and
   streaming workloads, delivering in-memory speeds at petabyte scale


[1] https://ignite.apache.org/releases/latest/dotnetdoc/
[2] https://www.nuget.org/packages/Apache.Ignite/2.6.0

-
Denis

Re: Apache Ignite tickets with empty description & dev list references

[Dmitriy Setrakyan]

Completely agree. When filing a ticket, we must all understand that we are
asking the community to work on it. Without a clear description nobody will
be able to pick up the ticket.

D.

On Tue, Jul 31, 2018 at 7:02 AM, Dmitriy Pavlov 
wrote:

> Hi Igniters,
>
> I would like to ask everyone in the Community to fill ticket decsription.
> Without it ticket is almost always incomplete and it is unclear for all
> community members, why this change was done. Moreover it is unlear why
> Ignite comitters accepts such changes.
>
> Also please link ticket to dev.list dicsusions (if any). You can find your
> topic in http://apache-ignite-developers.2346864.n4.nabble.com/ and insert
> link using More->Link->Web Link and insert particular post URL there.
>
> Please make sure you've covered
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> I would be happy to answer any questions related to contribution, and any
> feedback, as always, is welcomed.
>
> Sincerely,
> Dmitriy Pavlov
>

Re: Assign JIRA tickets to someone else

[Dmitriy Setrakyan]

Dmitriy,

I would agree with everything you are saying. There are some tickets,
however, that cannot be done by just anyone and preferably have to be
looked at by certain domain experts. In those cases only it would be OK to
assign a ticket explicitly in my view. For all other cases we should allow
the community pick up a ticket they want to work on.

D.

On Tue, Jul 31, 2018 at 10:34 AM, Dmitriy Pavlov 
wrote:

> Hi Igniters,
>
> Ignite is complex project and sometimes we know
> 1. who can solve the issue
> 2. and we would like that particular contributor would take an issue.
>
> In the same time "in an open source community where everything is
> distributed, asynchronous and volunteer work we should leave the issues
> open to anyone until someone volunteers to work on it."
>
> It seems it is not prohibited by Apache to assign it directly, in the same
> time it is better for community grown to avoid it:
> "Assigning things to people seems the role of a project manager that has
> some sort of power over the managed team. Speaking from experience I do not
> take it nicely when someone that uses the project I am a volunteer at
> (which I might now know ) "assigns work" to me."
>
> Please find Apache mentors' comments on this:
> https://lists.apache.org/thread.html/c6013b99940de32aae831a0b76e8fd
> 53febe5040e9e0d67abb4f62a5@%3Cdev.community.apache.org%3E
>
>
> Please share you vision.
>
> Sincerely,
> Dmitriy Pavlov
>

Re: Spark DataFrames With Cache Key and Value Objects

[Denis Magda]

Hello folks,

The documentation goes with a small reference about _key and _val usage,
and only for Ignite SQL APIs (Java, Net, C++). I tried to clean up all the
documentation code snippets.

As for the GitHub examples, they require a major overhaul. Instead of _key
and _val usage, we need to use SQL fields. Hopefully, someone will groom
the examples.

Considering this, I wouldn't suggest us exposing _key and _val in other
places like Spark. Are there any alternatives to this approach?

--
Denis



On Tue, Jul 31, 2018 at 2:49 AM Nikolay Izhikov  wrote:

> Hello, Igniters.
>
> Valentin,
>
> > We never recommend to use these fields
>
> Actually, we did:
>
> * Documentation [1]. Please, see "Predefined Fields" section.
> * Java Example [2]
> * DotNet Example [3]
> * Scala Example [4]
>
> > ...hopefully will be removed altogether one day
>
> This is new for me.
>
> Do we have specific plans for it?
>
> [1] https://apacheignite-sql.readme.io/docs/schema-and-indexes
> [2]
> https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/sql/SqlDmlExample.java#L88
> [3]
> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Sql/SqlDmlExample.cs#L91
> [4]
> https://github.com/apache/ignite/blob/master/examples/src/main/scala/org/apache/ignite/scalar/examples/ScalarCachePopularNumbersExample.scala#L124
>
> В Пт, 27/07/2018 в 15:22 -0700, Valentin Kulichenko пишет:
> > Stuart,
> >
> > _key and _val fields is quite a dirty hack that was added years ago and
> is
> > virtually never used now. We never recommend to use these fields and I
> > would definitely avoid building new features based on them.
> >
> > Having said that, I'm not arguing the use case, but we need better
> > implementation approach here. I suggest we think it over and come back to
> > this next week :) I'm sure Nikolay will also chime in and share his
> > thoughts.
> >
> > -Val
> >
> > On Fri, Jul 27, 2018 at 12:39 PM Stuart Macdonald 
> wrote:
> >
> > > If your predicates and joins are expressed in Spark SQL, you cannot
> > > currently optimise those and also gain access to the key/val objects.
> If
> > > you went without the Ignite Spark SQL optimisations and expressed your
> > > query in Ignite SQL, you still need to use the _key/_val columns. The
> > > Ignite documentation has this specific example using the _val column
> (right
> > > at the end):
> > > https://apacheignite-fs.readme.io/docs/ignitecontext-igniterdd
> > >
> > > Stuart.
> > >
> > > On 27 Jul 2018, at 20:05, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>
> > > wrote:
> > >
> > > Well, the second approach would use the optimizations, no?
> > >
> > > -Val
> > >
> > >
> > > On Fri, Jul 27, 2018 at 11:49 AM Stuart Macdonald 
> > > wrote:
> > >
> > > Val,
> > >
> > >
> > > Yes you can already get access to the cache objects as an RDD or
> > >
> > > Dataset but you can’t use the Ignite-optimised DataFrames with these
> > >
> > > mechanisms. Optimised DataFrames have to be passed through Spark SQL’s
> > >
> > > Catalyst engine to allow for predicate pushdown to Ignite. So the
> > >
> > > usecase we’re talking about here is when we want to be able to push
> > >
> > > Spark filters/joins to Ignite to optimise, but still have access to
> > >
> > > the underlying cache objects, which is not possible currently.
> > >
> > >
> > > Can you elaborate on the reason _key and _val columns in Ignite SQL
> > >
> > > will be removed?
> > >
> > >
> > > Stuart.
> > >
> > >
> > > On 27 Jul 2018, at 19:39, Valentin Kulichenko <
> > >
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > >
> > > Stuart, Nikolay,
> > >
> > >
> > > I really don't like the idea of exposing '_key' and '_val' fields. This
> > >
> > > is
> > >
> > > legacy stuff that hopefully will be removed altogether one day. Let's
> not
> > >
> > > use it in new features.
> > >
> > >
> > > Actually, I don't even think it's even needed. Spark docs [1] suggest
> two
> > >
> > > ways of creating a typed dataset:
> > >
> > > 1. Based on RDD. This should be supported using IgniteRDD I believe.
> > >
> > > 2. Based on DataFrame providing a class. This would just work out of
> the
> > >
> > > box I guess.
> > >
> > >
> > > Of course, this needs to be tested and verified, and there might be
> > >
> > > certain
> > >
> > > pieces missing to fully support the use case. But generally I like
> these
> > >
> > > approaches much more.
> > >
> > >
> > >
> > >
> > >
> https://spark.apache.org/docs/2.3.1/sql-programming-guide.html#creating-datasets
> > >
> > >
> > > -Val
> > >
> > >
> > > On Fri, Jul 27, 2018 at 6:31 AM Stuart Macdonald 
> > >
> > > wrote:
> > >
> > >
> > > Here’s the ticket:
> > >
> > >
> > > https://issues.apache.org/jira/browse/IGNITE-9108
> > >
> > >
> > > Stuart.
> > >
> > >
> > >
> > > On Friday, 27 July 2018 at 14:19, Nikolay Izhikov wrote:
> > >
> > >
> > > Sure.
> > >
> > >
> > > Please, send ticket number in thi

Re: TDE: Upgrade Team City JDK

[Petr Ivanov]

>8u111.

I’ve started the process of update, will try to accomplish by the end of the 
week.


> On 31 Jul 2018, at 21:26, Denis Magda  wrote:
> 
> Nikolay,
> 
> Do you need 8u111 and later? Or any JDK 8 works for you?
> 
> --
> Denis
> 
> On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  wrote:
> 
>> Hello, Petr.
>> 
>>> What JDK is required for running this build?
>> 
>> 8u111 and later.
>> 
>>> I can filter agents with correct JDK for now.
>> 
>> Encryption tests are executed by following build plans:
>> 
>>* Basic 1
>>* Binary Objects (Simple Mapper Basic)
>>* Queries 1
>>* Spring
>> 
>> В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
>>> No we cannot do it right now.
>>> 
>>> What JDK is required for running this build?
>>> I can filter agents with correct JDK for now.
>>> 
>>> 
>>> 
 On 31 Jul 2018, at 16:35, Nikolay Izhikov  wrote:
 
 Hello, Igniters.
 
 I have to up this thread.
 
 TDE. Phase 1 development is over.
 But, I still can't run TDE tests on Team city [1].
 
 I think that source of error is [2]
 
 Can we upgrade Team City JDK?
 
 [1]
>> https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1566703&_focus=446976
 [2] https://bugs.openjdk.java.net/browse/JDK-8149411
 
 В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
> Hi.
> 
>> can we add option enables AES 128
> 
> Currently, 128 bit key used [1]
> 
> 
>> I guess we should update environment to meet test requirements
>> prior putting changes to master.
> 
> Yes.
> 
> [1]
>> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
> 
> 
> В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
>> Hi Nikolay,
>> 
>> can we add option enables AES 128 for test mode? This should work
>> well
>> without update env.
>> 
>> Sincerely,
>> 
>> ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
>> 
>>> 
>>> 
 On 27 Jun 2018, at 18:06, Nikolay Izhikov 
>> wrote:
 
 Hello, Eduard.
 
> We should make suites which are restricted by agents to make
>> as small
>>> 
>>> as> possible.
 
 Agree. That means we should enable java cryptography on all
>> agents.
>>> 
>>> Isn't it?
 
> So, I strictly against adding such test (therefore
>> restriction) to
>>> 
>>> these> suites.>
 
 What is wrong with tests?
>>> 
>>> Tests in current configuration require specific environment.
>>> I guess we should update environment to meet test requirements
>> prior
>>> putting changes to master.
>>> 
>>> 
 Do you looked at it or something?
 
 
 В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
> Nikolay, Petr,
> 
> We should make suites which are restricted by agents to make
>> as small as
> possible.
> 
> So, I strictly against adding such test (therefore
>> restriction) to these
> suites.
> 
> On Wed, Jun 27, 2018 at 11:39 AM, Petr Ivanov <
>> mr.wei...@gmail.com>
>>> 
>>> wrote:
> 
>> IgniteSpiTestSuite is called from ’SPI’ build type and
>> I’ve added agent
>> filter there.
>> IgniteKernalSelfTestSuite is not found in build types.
>> 
>> 
>> 
>>> On 27 Jun 2018, at 11:26, Nikolay Izhikov <
>> nizhi...@apache.org>
>>> 
>>> wrote:
>>> 
>>> Well, it's a good question :)
>>> 
>>> I've added encryption tests in
>> `IgniteKernalSelfTestSuite` and in
>> 
>> `IgniteSpiTestSuite`.
>>> Not sure, what builds on Team City runs these suites.
>>> 
>>> В Ср, 27/06/2018 в 11:18 +0300, Petr Ivanov пишет:
 Nikolay,
 
 
 What is “core” module?
 
 
> On 27 Jun 2018, at 00:42, Nikolay Izhikov <
>> nizhi...@apache.org>
>>> 
>>> wrote:
> 
> Hello, Petr.
> 
> Thanks a lot!
> I see success spring encryption tests now [1]
> 
> I've added encryption tests to core module also.
> Can we set same rule for a core module?
> 
> [1]
>> https://ci.ignite.apache.org/project.html?projectId=
>> 
>> 
>> IgniteTests24Java8&testNameId=-2290193573767653560&tab=testDetails
> 
> В Вт, 26/06/2018 в 23:38 +0300, Petr Ivanov пишет:
>> I’ve added JCE as it is described in
>> documentation, but for some
>> 
>> unknown reason it won’t work on 1.8.0_u151.
>> So I’ve fix agent filter rule to run Spring build
>> type only on
>> 
>> 1.8.0_u171 (49 agents) and 

Re: TDE: Upgrade Team City JDK

[Denis Magda]

Nikolay,

Do you need 8u111 and later? Or any JDK 8 works for you?

--
Denis

On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  wrote:

> Hello, Petr.
>
> > What JDK is required for running this build?
>
> 8u111 and later.
>
> > I can filter agents with correct JDK for now.
>
> Encryption tests are executed by following build plans:
>
> * Basic 1
> * Binary Objects (Simple Mapper Basic)
> * Queries 1
> * Spring
>
> В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
> > No we cannot do it right now.
> >
> > What JDK is required for running this build?
> > I can filter agents with correct JDK for now.
> >
> >
> >
> > > On 31 Jul 2018, at 16:35, Nikolay Izhikov  wrote:
> > >
> > > Hello, Igniters.
> > >
> > > I have to up this thread.
> > >
> > > TDE. Phase 1 development is over.
> > > But, I still can't run TDE tests on Team city [1].
> > >
> > > I think that source of error is [2]
> > >
> > > Can we upgrade Team City JDK?
> > >
> > > [1]
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1566703&_focus=446976
> > > [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> > >
> > > В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
> > > > Hi.
> > > >
> > > > > can we add option enables AES 128
> > > >
> > > > Currently, 128 bit key used [1]
> > > >
> > > >
> > > > > I guess we should update environment to meet test requirements
> prior putting changes to master.
> > > >
> > > > Yes.
> > > >
> > > > [1]
> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
> > > >
> > > >
> > > > В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> > > > > Hi Nikolay,
> > > > >
> > > > > can we add option enables AES 128 for test mode? This should work
> well
> > > > > without update env.
> > > > >
> > > > > Sincerely,
> > > > >
> > > > > ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
> > > > >
> > > > > >
> > > > > >
> > > > > > > On 27 Jun 2018, at 18:06, Nikolay Izhikov 
> wrote:
> > > > > > >
> > > > > > > Hello, Eduard.
> > > > > > >
> > > > > > > > We should make suites which are restricted by agents to make
> as small
> > > > > >
> > > > > > as> possible.
> > > > > > >
> > > > > > > Agree. That means we should enable java cryptography on all
> agents.
> > > > > >
> > > > > > Isn't it?
> > > > > > >
> > > > > > > > So, I strictly against adding such test (therefore
> restriction) to
> > > > > >
> > > > > > these> suites.>
> > > > > > >
> > > > > > > What is wrong with tests?
> > > > > >
> > > > > > Tests in current configuration require specific environment.
> > > > > > I guess we should update environment to meet test requirements
> prior
> > > > > > putting changes to master.
> > > > > >
> > > > > >
> > > > > > > Do you looked at it or something?
> > > > > > >
> > > > > > >
> > > > > > > В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
> > > > > > > > Nikolay, Petr,
> > > > > > > >
> > > > > > > > We should make suites which are restricted by agents to make
> as small as
> > > > > > > > possible.
> > > > > > > >
> > > > > > > > So, I strictly against adding such test (therefore
> restriction) to these
> > > > > > > > suites.
> > > > > > > >
> > > > > > > > On Wed, Jun 27, 2018 at 11:39 AM, Petr Ivanov <
> mr.wei...@gmail.com>
> > > > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > IgniteSpiTestSuite is called from ’SPI’ build type and
> I’ve added agent
> > > > > > > > > filter there.
> > > > > > > > > IgniteKernalSelfTestSuite is not found in build types.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > On 27 Jun 2018, at 11:26, Nikolay Izhikov <
> nizhi...@apache.org>
> > > > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Well, it's a good question :)
> > > > > > > > > >
> > > > > > > > > > I've added encryption tests in
> `IgniteKernalSelfTestSuite` and in
> > > > > > > > >
> > > > > > > > > `IgniteSpiTestSuite`.
> > > > > > > > > > Not sure, what builds on Team City runs these suites.
> > > > > > > > > >
> > > > > > > > > > В Ср, 27/06/2018 в 11:18 +0300, Petr Ivanov пишет:
> > > > > > > > > > > Nikolay,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > What is “core” module?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > On 27 Jun 2018, at 00:42, Nikolay Izhikov <
> nizhi...@apache.org>
> > > > > >
> > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hello, Petr.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks a lot!
> > > > > > > > > > > > I see success spring encryption tests now [1]
> > > > > > > > > > > >
> > > > > > > > > > > > I've added encryption tests to core module also.
> > > > > > > > > > > > Can we set same rule for a core module?
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> https://ci.ignite.apache.org/project.html?projectId=
> > > > > > > > >
> > > > > > > > >
> IgniteTests24Java8&testNameId=-2290193573767653560&tab=testDetails
> > > > > > > > > > > >
> > > 

Assign JIRA tickets to someone else

[Dmitriy Pavlov]

Hi Igniters,

Ignite is complex project and sometimes we know
1. who can solve the issue
2. and we would like that particular contributor would take an issue.

In the same time "in an open source community where everything is
distributed, asynchronous and volunteer work we should leave the issues
open to anyone until someone volunteers to work on it."

It seems it is not prohibited by Apache to assign it directly, in the same
time it is better for community grown to avoid it:
"Assigning things to people seems the role of a project manager that has
some sort of power over the managed team. Speaking from experience I do not
take it nicely when someone that uses the project I am a volunteer at
(which I might now know ) "assigns work" to me."

Please find Apache mentors' comments on this:
https://lists.apache.org/thread.html/c6013b99940de32aae831a0b76e8fd53febe5040e9e0d67abb4f62a5@%3Cdev.community.apache.org%3E


Please share you vision.

Sincerely,
Dmitriy Pavlov

[jira] [Created] (IGNITE-9149) Get rid of logging remaining supllier nodes rebalance time

[Maxim Muzafarov (JIRA)]

Maxim Muzafarov created IGNITE-9149:
---

 Summary: Get rid of logging remaining supllier nodes rebalance time
 Key: IGNITE-9149
 URL: https://issues.apache.org/jira/browse/IGNITE-9149
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov


Logging rebalance execution time in section of each supplier node have no sence 
and provides no helpfull info for analyzing logs. It also overcomplicates 
{{GridDhtPartitionDemander}}.

I'm suggesting remove it by simplifying {{Map>}} to {{Map}}.
{code:java}
/** Remaining. T2: startTime, partitions */
private final Map> remaining = 
new HashMap<>();
{code}



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

[GitHub] ignite pull request #4463: GG-14025: Fix deleted entry version.

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

GG-14025: Fix deleted entry version.

For test purposes.

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

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

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

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


commit e1af50ecdd37b5e47e05c957c5f9e40c10ee81ec
Author: Andrey V. Mashenkov 
Date:   2018-07-31T13:58:43Z

GG-14025: WIP. Fix deleted entry version.

Fix DR conflict resolution due to wrong entry version handling when entry 
remove opeartion has replicated.




---

Re: Permissions for creating a TeamCity configuration.

[Pavel Pereslegin]

Hi Dmitriy,

Yes I can, thank you.

2018-07-31 19:17 GMT+03:00 Dmitriy Pavlov :
> Hi Pavel,
>
> Could you check now if you coud change settings in Ignite 2.4 Java 8
> projects?
>
> Sincerely,
> Dmitriy Pavkiv
>
> вт, 31 июл. 2018 г. в 19:16, Dmitriy Pavlov :
>
>> Hi Pavel,
>>
>> I support idea of granting necessary permission, but I'm not sure which
>> role I should assign.
>>
>> So let's wait for experienced TC admins to grant it.
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> вт, 31 июл. 2018 г. в 19:13, Pavel Pereslegin :
>>
>>> Hello Igniters,
>>>
>>> I want get to work on issue [1] (Split Cache 3 TC configuration).
>>> Could you give me permissions on TeamCity for creating new configurations?
>>> My TeamCity login: xtern.
>>>
>>> [1] https://issues.apache.org/jira/browse/IGNITE-9148
>>>
>>

Re: Permissions for creating a TeamCity configuration.

[Dmitriy Pavlov]

Hi Pavel,

Could you check now if you coud change settings in Ignite 2.4 Java 8
projects?

Sincerely,
Dmitriy Pavkiv

вт, 31 июл. 2018 г. в 19:16, Dmitriy Pavlov :

> Hi Pavel,
>
> I support idea of granting necessary permission, but I'm not sure which
> role I should assign.
>
> So let's wait for experienced TC admins to grant it.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 31 июл. 2018 г. в 19:13, Pavel Pereslegin :
>
>> Hello Igniters,
>>
>> I want get to work on issue [1] (Split Cache 3 TC configuration).
>> Could you give me permissions on TeamCity for creating new configurations?
>> My TeamCity login: xtern.
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-9148
>>
>

Re: Permissions for creating a TeamCity configuration.

[Dmitriy Pavlov]

Hi Pavel,

I support idea of granting necessary permission, but I'm not sure which
role I should assign.

So let's wait for experienced TC admins to grant it.

Sincerely,
Dmitriy Pavlov

вт, 31 июл. 2018 г. в 19:13, Pavel Pereslegin :

> Hello Igniters,
>
> I want get to work on issue [1] (Split Cache 3 TC configuration).
> Could you give me permissions on TeamCity for creating new configurations?
> My TeamCity login: xtern.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9148
>

Permissions for creating a TeamCity configuration.

[Pavel Pereslegin]

Hello Igniters,

I want get to work on issue [1] (Split Cache 3 TC configuration).
Could you give me permissions on TeamCity for creating new configurations?
My TeamCity login: xtern.

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

[jira] [Created] (IGNITE-9148) Split Cache 3 TC configuration.

[Pavel Pereslegin (JIRA)]

Pavel Pereslegin created IGNITE-9148:


 Summary: Split Cache 3 TC configuration.
 Key: IGNITE-9148
 URL: https://issues.apache.org/jira/browse/IGNITE-9148
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin


Cache 3 TC configuration takes too long time to complete (>1.5h) and should be 
split into two.



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

[jira] [Created] (IGNITE-9147) When server node left cluster on high load, cluster take hang on PartitionalExchange

[ARomantsov (JIRA)]

ARomantsov created IGNITE-9147:
--

 Summary: When server node left cluster on high load, cluster take 
hang on PartitionalExchange
 Key: IGNITE-9147
 URL: https://issues.apache.org/jira/browse/IGNITE-9147
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.5
Reporter: ARomantsov
 Fix For: 2.7


I ran a simple test

1) Start 15 servers node
2) Start client with long transaction
3) Additional start 5 client with loading in many caches (near 2 thousand)
4) Stop 1 server node, wait 1 minute and start it back

Cluster freenze on more than hour, then license end



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

[GitHub] ignite pull request #4203: IGNITE-8180

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9146) Analyse and improve code coverage in ML module

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-9146:
--

 Summary: Analyse and improve code coverage in ML module
 Key: IGNITE-9146
 URL: https://issues.apache.org/jira/browse/IGNITE-9146
 Project: Ignite
  Issue Type: Task
  Components: ml
Affects Versions: 2.6
Reporter: Oleg Ignatenko


Run code coverage analysis, study results and add missing tests where needed.



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

[GitHub] ignite pull request #4458: IGNITE-9130: Test fixed.

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4462: IGNITE-9124 Remove some dead code in ML module

[oignatenko]

GitHub user oignatenko opened a pull request:

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

IGNITE-9124 Remove some dead code in ML module



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

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

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

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


commit 6a92b001d65c8f39f88edf53c2487c4f32929f42
Author: Oleg Ignatenko 
Date:   2018-07-30T15:55:20Z

IGNITE-9124 Remove some dead code in math.exceptions and optimization 
packages of ML module
- draft removal
-- verified with diffs overview and clean rebuild

commit 566b8e35e92d4aa39c5a79ff12f1defae9552d1e
Author: Oleg Ignatenko 
Date:   2018-07-31T14:00:09Z

IGNITE-9124 Remove some dead code in math.exceptions and optimization 
packages of ML module
- removal completed
-- verified with diffs overview and clean rebuild

commit d71ddd0c9a987d98d10b38f9cf47b5ed237977e0
Author: Oleg Ignatenko 
Date:   2018-07-31T14:02:00Z

Merge branch 'master-ml' into ignite-9124




---

[GitHub] ignite pull request #4460: IGNITE-9114

[devozerov]

Github user devozerov closed the pull request at:

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


---

[jira] [Created] (IGNITE-9145) [ML] Add different strategies to index labels in StringEncoderTrainer

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-9145:


 Summary: [ML] Add different strategies to index labels in 
StringEncoderTrainer
 Key: IGNITE-9145
 URL: https://issues.apache.org/jira/browse/IGNITE-9145
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev
 Fix For: 2.7


The main idea to add a few strategies of indexing: sorting and so on.

Currently it supports only one strategy (most popular with zero and less 
popular with the max index size).

There are can be a few options
 * 'frequencyDesc': descending order by label frequency (most frequent label 
assigned 0)
 * 'frequencyAsc': ascending order by label frequency (least frequent label 
assigned 0)
 * 'alphabetDesc': descending alphabetical order
 * 'alphabetAsc': ascending alphabetical order

 

Please, update the method **transformFrequenciesToEncodingValues and add the 
strategy as a parameter of trainer.

 



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

Apache Ignite tickets with empty description & dev list references

[Dmitriy Pavlov]

Hi Igniters,

I would like to ask everyone in the Community to fill ticket decsription.
Without it ticket is almost always incomplete and it is unclear for all
community members, why this change was done. Moreover it is unlear why
Ignite comitters accepts such changes.

Also please link ticket to dev.list dicsusions (if any). You can find your
topic in http://apache-ignite-developers.2346864.n4.nabble.com/ and insert
link using More->Link->Web Link and insert particular post URL there.

Please make sure you've covered
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

I would be happy to answer any questions related to contribution, and any
feedback, as always, is welcomed.

Sincerely,
Dmitriy Pavlov

[GitHub] ignite pull request #4402: IGNITE-9034 Add Estimator API support to TensorFl...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: TDE: Upgrade Team City JDK

[Nikolay Izhikov]

Hello, Petr.

> What JDK is required for running this build? 

8u111 and later.

> I can filter agents with correct JDK for now.

Encryption tests are executed by following build plans:

* Basic 1
* Binary Objects (Simple Mapper Basic)
* Queries 1
* Spring

В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
> No we cannot do it right now.
> 
> What JDK is required for running this build? 
> I can filter agents with correct JDK for now.
> 
> 
> 
> > On 31 Jul 2018, at 16:35, Nikolay Izhikov  wrote:
> > 
> > Hello, Igniters.
> > 
> > I have to up this thread.
> > 
> > TDE. Phase 1 development is over.
> > But, I still can't run TDE tests on Team city [1].
> > 
> > I think that source of error is [2]
> > 
> > Can we upgrade Team City JDK?
> > 
> > [1] 
> > https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1566703&_focus=446976
> > [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> > 
> > В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
> > > Hi.
> > > 
> > > > can we add option enables AES 128
> > > 
> > > Currently, 128 bit key used [1]
> > > 
> > > 
> > > > I guess we should update environment to meet test requirements prior 
> > > > putting changes to master.
> > > 
> > > Yes.
> > > 
> > > [1] 
> > > https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
> > > 
> > > 
> > > В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> > > > Hi Nikolay,
> > > > 
> > > > can we add option enables AES 128 for test mode? This should work well
> > > > without update env.
> > > > 
> > > > Sincerely,
> > > > 
> > > > ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
> > > > 
> > > > > 
> > > > > 
> > > > > > On 27 Jun 2018, at 18:06, Nikolay Izhikov  
> > > > > > wrote:
> > > > > > 
> > > > > > Hello, Eduard.
> > > > > > 
> > > > > > > We should make suites which are restricted by agents to make as 
> > > > > > > small
> > > > > 
> > > > > as> possible.
> > > > > > 
> > > > > > Agree. That means we should enable java cryptography on all agents.
> > > > > 
> > > > > Isn't it?
> > > > > > 
> > > > > > > So, I strictly against adding such test (therefore restriction) to
> > > > > 
> > > > > these> suites.>
> > > > > > 
> > > > > > What is wrong with tests?
> > > > > 
> > > > > Tests in current configuration require specific environment.
> > > > > I guess we should update environment to meet test requirements prior
> > > > > putting changes to master.
> > > > > 
> > > > > 
> > > > > > Do you looked at it or something?
> > > > > > 
> > > > > > 
> > > > > > В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
> > > > > > > Nikolay, Petr,
> > > > > > > 
> > > > > > > We should make suites which are restricted by agents to make as 
> > > > > > > small as
> > > > > > > possible.
> > > > > > > 
> > > > > > > So, I strictly against adding such test (therefore restriction) 
> > > > > > > to these
> > > > > > > suites.
> > > > > > > 
> > > > > > > On Wed, Jun 27, 2018 at 11:39 AM, Petr Ivanov 
> > > > > > > 
> > > > > 
> > > > > wrote:
> > > > > > > 
> > > > > > > > IgniteSpiTestSuite is called from ’SPI’ build type and I’ve 
> > > > > > > > added agent
> > > > > > > > filter there.
> > > > > > > > IgniteKernalSelfTestSuite is not found in build types.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > On 27 Jun 2018, at 11:26, Nikolay Izhikov 
> > > > > > > > > 
> > > > > 
> > > > > wrote:
> > > > > > > > > 
> > > > > > > > > Well, it's a good question :)
> > > > > > > > > 
> > > > > > > > > I've added encryption tests in `IgniteKernalSelfTestSuite` 
> > > > > > > > > and in
> > > > > > > > 
> > > > > > > > `IgniteSpiTestSuite`.
> > > > > > > > > Not sure, what builds on Team City runs these suites.
> > > > > > > > > 
> > > > > > > > > В Ср, 27/06/2018 в 11:18 +0300, Petr Ivanov пишет:
> > > > > > > > > > Nikolay,
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > What is “core” module?
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > On 27 Jun 2018, at 00:42, Nikolay Izhikov 
> > > > > > > > > > > 
> > > > > 
> > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > Hello, Petr.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks a lot!
> > > > > > > > > > > I see success spring encryption tests now [1]
> > > > > > > > > > > 
> > > > > > > > > > > I've added encryption tests to core module also.
> > > > > > > > > > > Can we set same rule for a core module?
> > > > > > > > > > > 
> > > > > > > > > > > [1] https://ci.ignite.apache.org/project.html?projectId=
> > > > > > > > 
> > > > > > > > IgniteTests24Java8&testNameId=-2290193573767653560&tab=testDetails
> > > > > > > > > > > 
> > > > > > > > > > > В Вт, 26/06/2018 в 23:38 +0300, Petr Ivanov пишет:
> > > > > > > > > > > > I’ve added JCE as it is described in documentation, but 
> > > > > > > > > > > > for some
> > > > > > > > 
> > > > > > > > unknown reason it won’t work on 1.8.0_u151.
> > > > > > > > > > > > So 

[GitHub] ignite pull request #4459: IGNITE-9138: ZookeeperDiscoverySpiTest#checkInter...

[BiryukovVA]

Github user BiryukovVA closed the pull request at:

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


---

Re: TDE: Upgrade Team City JDK

[Petr Ivanov]

No we cannot do it right now.

What JDK is required for running this build? 
I can filter agents with correct JDK for now.



> On 31 Jul 2018, at 16:35, Nikolay Izhikov  wrote:
> 
> Hello, Igniters.
> 
> I have to up this thread.
> 
> TDE. Phase 1 development is over.
> But, I still can't run TDE tests on Team city [1].
> 
> I think that source of error is [2]
> 
> Can we upgrade Team City JDK?
> 
> [1] 
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1566703&_focus=446976
> [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> 
> В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
>> Hi.
>> 
>>> can we add option enables AES 128
>> 
>> Currently, 128 bit key used [1]
>> 
>> 
>>> I guess we should update environment to meet test requirements prior 
>>> putting changes to master.
>> 
>> Yes.
>> 
>> [1] 
>> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
>> 
>> 
>> В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
>>> Hi Nikolay,
>>> 
>>> can we add option enables AES 128 for test mode? This should work well
>>> without update env.
>>> 
>>> Sincerely,
>>> 
>>> ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
>>> 
 
 
> On 27 Jun 2018, at 18:06, Nikolay Izhikov  wrote:
> 
> Hello, Eduard.
> 
>> We should make suites which are restricted by agents to make as small
 
 as> possible.
> 
> Agree. That means we should enable java cryptography on all agents.
 
 Isn't it?
> 
>> So, I strictly against adding such test (therefore restriction) to
 
 these> suites.>
> 
> What is wrong with tests?
 
 Tests in current configuration require specific environment.
 I guess we should update environment to meet test requirements prior
 putting changes to master.
 
 
> Do you looked at it or something?
> 
> 
> В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
>> Nikolay, Petr,
>> 
>> We should make suites which are restricted by agents to make as small as
>> possible.
>> 
>> So, I strictly against adding such test (therefore restriction) to these
>> suites.
>> 
>> On Wed, Jun 27, 2018 at 11:39 AM, Petr Ivanov 
 
 wrote:
>> 
>>> IgniteSpiTestSuite is called from ’SPI’ build type and I’ve added agent
>>> filter there.
>>> IgniteKernalSelfTestSuite is not found in build types.
>>> 
>>> 
>>> 
 On 27 Jun 2018, at 11:26, Nikolay Izhikov 
 
 wrote:
 
 Well, it's a good question :)
 
 I've added encryption tests in `IgniteKernalSelfTestSuite` and in
>>> 
>>> `IgniteSpiTestSuite`.
 Not sure, what builds on Team City runs these suites.
 
 В Ср, 27/06/2018 в 11:18 +0300, Petr Ivanov пишет:
> Nikolay,
> 
> 
> What is “core” module?
> 
> 
>> On 27 Jun 2018, at 00:42, Nikolay Izhikov 
 
 wrote:
>> 
>> Hello, Petr.
>> 
>> Thanks a lot!
>> I see success spring encryption tests now [1]
>> 
>> I've added encryption tests to core module also.
>> Can we set same rule for a core module?
>> 
>> [1] https://ci.ignite.apache.org/project.html?projectId=
>>> 
>>> IgniteTests24Java8&testNameId=-2290193573767653560&tab=testDetails
>> 
>> В Вт, 26/06/2018 в 23:38 +0300, Petr Ivanov пишет:
>>> I’ve added JCE as it is described in documentation, but for some
>>> 
>>> unknown reason it won’t work on 1.8.0_u151.
>>> So I’ve fix agent filter rule to run Spring build type only on
>>> 
>>> 1.8.0_u171 (49 agents) and run it on all enabled compatible agents.
>>> Looks like it fixed the issue.
>>> 
>>> 
>>> 
 On 26 Jun 2018, at 19:27, Nikolay Izhikov 
>>> 
>>> wrote:
 
 Petr, can you make suggested jdk upgrade?
 
 В Пн, 25/06/2018 в 14:28 +0300, Nikolay Izhikov пишет:
> Petr.
> 
> One more thing:
> 
> We need to install "Java Cryptography Extension (JCE) Unlimited
>>> 
>>> Strength Jurisdiction Policy Files" [1] to enable usage of JDK provided
>>> crypto algorithmes.
> Otherwise it fails with "java.security.InvalidKeyException:
>>> 
>>> Illegal key size at
 
 javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1039)"
>>> [2]
> 
> Can you do it for Team City agents?
> 
> [1] http://www.oracle.com/technetwork/java/javase/
>>> 
>>> downloads/jce8-download-2133166.html
> [2] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&
>>> 
>>> logTab=tree&filter=debug&expand=all&buildId=1421337&_focus=30899
> 
> В Пн

find bugs code check

[Евгений Станиловский]

hi, igniters.
I take a little time to analyze findbugs  http://findbugs.sourceforge.net/  
output from ignite-core module.
There is summary of suspicious messages:

GridIoManager

sync on conc map:

synchronized (map) {
rmv = map.remove(set.nodeId(), set);
}
---

GridCacheLockImpl

read without sync monitor

final int getPermits() {
return getState();
}

final synchronized void setPermits(int permits) {
setState(permits);
}

---

GridDhtPartitionFullMap

add null check

@Override public boolean equals(Object o) {
if (this == o)
return true;

GridDhtPartitionFullMap other = (GridDhtPartitionFullMap)o;

return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
}

GridDhtPartitionMap

add null check

@Override public boolean equals(Object o) {
if (this == o)
return true;

GridDhtPartitionMap other = (GridDhtPartitionMap)o;

return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
}

add null check

GridNearOptimisticTxPrepareFuture

@Override public boolean equals(Object o) {
MappingKey that = (MappingKey) o;

return nearEntries == that.nearEntries && nodeId.equals(that.nodeId);
}

-

copy-paste:
public class GridTuple6

@Override public boolean equals(Object o) {
if (this == o)
return true;

if (!(o instanceof GridTuple5))
return false;


---

not closing stream:
public class GridClientJdkMarshaller implements GridClientMarshaller {
/** ID. */
public static final byte ID = 2;

/** {@inheritDoc} */
@Override public ByteBuffer marshal(Object obj, int off) throws IOException {
GridByteArrayOutputStream bOut = new GridByteArrayOutputStream();

ObjectOutput out = new ObjectOutputStream(bOut);
plz take a look on it, thanks !

Re: TDE: Upgrade Team City JDK

[Nikolay Izhikov]

Hello, Igniters.

I have to up this thread.

TDE. Phase 1 development is over.
But, I still can't run TDE tests on Team city [1].

I think that source of error is [2]

Can we upgrade Team City JDK?

[1] 
https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1566703&_focus=446976
[2] https://bugs.openjdk.java.net/browse/JDK-8149411

В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
> Hi.
> 
> > can we add option enables AES 128
> 
> Currently, 128 bit key used [1]
> 
> 
> > I guess we should update environment to meet test requirements prior 
> > putting changes to master.
> 
> Yes.
> 
> [1] 
> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
> 
> 
> В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> > Hi Nikolay,
> > 
> >  can we add option enables AES 128 for test mode? This should work well
> > without update env.
> > 
> > Sincerely,
> > 
> > ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
> > 
> > > 
> > > 
> > > > On 27 Jun 2018, at 18:06, Nikolay Izhikov  wrote:
> > > > 
> > > > Hello, Eduard.
> > > > 
> > > > > We should make suites which are restricted by agents to make as small
> > > 
> > > as> possible.
> > > > 
> > > > Agree. That means we should enable java cryptography on all agents.
> > > 
> > > Isn't it?
> > > > 
> > > > > So, I strictly against adding such test (therefore restriction) to
> > > 
> > > these> suites.>
> > > > 
> > > > What is wrong with tests?
> > > 
> > > Tests in current configuration require specific environment.
> > > I guess we should update environment to meet test requirements prior
> > > putting changes to master.
> > > 
> > > 
> > > > Do you looked at it or something?
> > > > 
> > > > 
> > > > В Ср, 27/06/2018 в 14:24 +0300, Eduard Shangareev пишет:
> > > > > Nikolay, Petr,
> > > > > 
> > > > > We should make suites which are restricted by agents to make as small 
> > > > > as
> > > > > possible.
> > > > > 
> > > > > So, I strictly against adding such test (therefore restriction) to 
> > > > > these
> > > > > suites.
> > > > > 
> > > > > On Wed, Jun 27, 2018 at 11:39 AM, Petr Ivanov 
> > > 
> > > wrote:
> > > > > 
> > > > > > IgniteSpiTestSuite is called from ’SPI’ build type and I’ve added 
> > > > > > agent
> > > > > > filter there.
> > > > > > IgniteKernalSelfTestSuite is not found in build types.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > On 27 Jun 2018, at 11:26, Nikolay Izhikov 
> > > 
> > > wrote:
> > > > > > > 
> > > > > > > Well, it's a good question :)
> > > > > > > 
> > > > > > > I've added encryption tests in `IgniteKernalSelfTestSuite` and in
> > > > > > 
> > > > > > `IgniteSpiTestSuite`.
> > > > > > > Not sure, what builds on Team City runs these suites.
> > > > > > > 
> > > > > > > В Ср, 27/06/2018 в 11:18 +0300, Petr Ivanov пишет:
> > > > > > > > Nikolay,
> > > > > > > > 
> > > > > > > > 
> > > > > > > > What is “core” module?
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > On 27 Jun 2018, at 00:42, Nikolay Izhikov 
> > > > > > > > > 
> > > 
> > > wrote:
> > > > > > > > > 
> > > > > > > > > Hello, Petr.
> > > > > > > > > 
> > > > > > > > > Thanks a lot!
> > > > > > > > > I see success spring encryption tests now [1]
> > > > > > > > > 
> > > > > > > > > I've added encryption tests to core module also.
> > > > > > > > > Can we set same rule for a core module?
> > > > > > > > > 
> > > > > > > > > [1] https://ci.ignite.apache.org/project.html?projectId=
> > > > > > 
> > > > > > IgniteTests24Java8&testNameId=-2290193573767653560&tab=testDetails
> > > > > > > > > 
> > > > > > > > > В Вт, 26/06/2018 в 23:38 +0300, Petr Ivanov пишет:
> > > > > > > > > > I’ve added JCE as it is described in documentation, but for 
> > > > > > > > > > some
> > > > > > 
> > > > > > unknown reason it won’t work on 1.8.0_u151.
> > > > > > > > > > So I’ve fix agent filter rule to run Spring build type only 
> > > > > > > > > > on
> > > > > > 
> > > > > > 1.8.0_u171 (49 agents) and run it on all enabled compatible agents.
> > > > > > > > > > Looks like it fixed the issue.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > On 26 Jun 2018, at 19:27, Nikolay Izhikov 
> > > > > > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > Petr, can you make suggested jdk upgrade?
> > > > > > > > > > > 
> > > > > > > > > > > В Пн, 25/06/2018 в 14:28 +0300, Nikolay Izhikov пишет:
> > > > > > > > > > > > Petr.
> > > > > > > > > > > > 
> > > > > > > > > > > > One more thing:
> > > > > > > > > > > > 
> > > > > > > > > > > > We need to install "Java Cryptography Extension (JCE) 
> > > > > > > > > > > > Unlimited
> > > > > > 
> > > > > > Strength Jurisdiction Policy Files" [1] to enable usage of JDK 
> > > > > > provided
> > > > > > crypto algorithmes.
> > > > > > > > > > > > Otherwise it fails with 
> > > > > > > > > > > > "java.security.InvalidKeyException:
> > > > > > 
> > > > > > Illegal key size at
> > > 
> > > javax.crypto.Ci

Re: Apache Ignite 2.7: scope, time and release manager

[Nikolay Izhikov]

Thanks, Petr!

В Вт, 31/07/2018 в 16:10 +0300, Petr Ivanov пишет:
> Fixed that.
> It seems that Heading 2 style was applied to some Jira macros.
> 
> 
> 
> > On 31 Jul 2018, at 16:06, Dmitriy Pavlov  wrote:
> > 
> > Hi Nikolay,
> > 
> > Thank you for this page. It seems font size for some filters is bigger than
> > for others. It is intentionally done this way?
> > 
> > Sincerely,
> > Dmitriy Pavlov
> > 
> > вт, 31 июл. 2018 г. в 15:57, Nikolay Izhikov :
> > 
> > > Hello, Igniters.
> > > 
> > > Release page created [1].
> > > 
> > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7
> > > 
> > > В Пт, 27/07/2018 в 00:52 -0700, Denis Magda пишет:
> > > > Sure, it can wait. Thanks! Take a rest )
> > > > 
> > > > On Thu, Jul 26, 2018 at 11:39 PM Nikolay Izhikov 
> > > > wrote:
> > > > 
> > > > > Hello, Denis.
> > > > > 
> > > > > Actually, I'm on vacation till July, 31.
> > > > > After it I will put all my efforts to manage Ignite release.
> > > > > 
> > > > > Can we wait until Tuesday?
> > > > > 
> > > > > В Чт, 26/07/2018 в 17:01 -0700, Denis Magda пишет:
> > > > > > Nikolay,
> > > > > > 
> > > > > > Could you please prepare Ignite 2.7 page similar to the following?
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> > > > > > 
> > > > > > We need to start tracking the progress and most essential
> > > 
> > > capabilities
> > > > > 
> > > > > that will get into the release.
> > > > > > 
> > > > > > --
> > > > > > Denis
> > > > > > On Tue, Jul 24, 2018 at 1:39 AM Vyacheslav Daradur <
> > > 
> > > daradu...@gmail.com>
> > > > > 
> > > > > wrote:
> > > > > > > Hi, Igniters!
> > > > > > > 
> > > > > > > The end of September for Ignite 2.7 release sounds good to me.
> > > > > > > 
> > > > > > > I'm working on Service Grid and going to deliver the following
> > > 
> > > tasks:
> > > > > > > - Use discovery messages for service deployment [[1]
> > > > > > > - Collect service deployment results asynchronously on coordinator
> > > 
> > > [2]
> > > > > > > - Propagate service deployment results from assigned nodes to
> > > > > 
> > > > > initiator [3]
> > > > > > > - Handle topology changes during service deployment [4]
> > > > > > > - Propagate deployed services to joining nodes [5]
> > > > > > > - Replace service instance parameter with a class name in
> > > > > > > ServiceConfiguration [6] (planned to be implemented by Amelchev
> > > > > > > Nikita)
> > > > > > > 
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8361
> > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-8362
> > > > > > > [3] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-8363
> > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-8364
> > > > > > > [6] https://issues.apache.org/jira/browse/IGNITE-8366
> > > > > > > On Mon, Jul 23, 2018 at 4:02 PM Dmitry Pavlov <
> > > 
> > > dpavlov@gmail.com>
> > > > > 
> > > > > wrote:
> > > > > > > > 
> > > > > > > > Hi Denis, Nikolay,
> > > > > > > > 
> > > > > > > > I've issued a number of tickets to update dependencies versions.
> > > 
> > > I
> > > > > 
> > > > > would
> > > > > > > > like all these updates are available within 2.7.
> > > > > > > > 
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > > 
> > > > > > > > сб, 21 июл. 2018 г. в 3:28, Pavel Petroshenko <
> > > 
> > > pa...@petroshenko.com
> > > > > > 
> > > > > > :
> > > > > > > > 
> > > > > > > > > Hi Denis, Nikolay,
> > > > > > > > > 
> > > > > > > > > The proposed 2.7 release timing sounds reasonable to me.
> > > > > > > > > Python [1], PHP [2], and Node.js [3] thin clients should take
> > > 
> > > the
> > > > > 
> > > > > train.
> > > > > > > > > 
> > > > > > > > > p.
> > > > > > > > > 
> > > > > > > > > [1] https://jira.apache.org/jira/browse/IGNITE-7782
> > > > > > > > > [2] https://jira.apache.org/jira/browse/IGNITE-7783
> > > > > > > > > [3] https://jira.apache.org/jira/browse/IGNITE-
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Fri, Jul 20, 2018 at 2:35 PM, Denis Magda <
> > > 
> > > dma...@gridgain.com>
> > > > > 
> > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > Igniters,
> > > > > > > > > > 
> > > > > > > > > > Let's agree on the time and the scope of 2.7. As for the
> > > 
> > > release
> > > > > 
> > > > > manager,
> > > > > > > > > > we had a conversation with Nikolay Izhikov and he decided to
> > > 
> > > try
> > > > > 
> > > > > the role
> > > > > > > > > > out. Thanks, Nikolay!
> > > > > > > > > > 
> > > > > > > > > > Nikolay, we need to prepare a page like that [1] once the
> > > > > 
> > > > > release terms
> > > > > > > > > are
> > > > > > > > > > defined.
> > > > > > > > > > 
> > > > > > > > > > I propose us to roll Ignite 2.7 at the end of September.
> > > 
> > > Folks
> > > > > 
> > > > > who are
> > > > > > > > > > working on SQL, core, C++/NET, thin clients, ML, service 
> > > > > > > > > > grid
> > > > > > > > > > optimizat

Re: Apache Ignite 2.7: scope, time and release manager

[Petr Ivanov]

Fixed that.
It seems that Heading 2 style was applied to some Jira macros.



> On 31 Jul 2018, at 16:06, Dmitriy Pavlov  wrote:
> 
> Hi Nikolay,
> 
> Thank you for this page. It seems font size for some filters is bigger than
> for others. It is intentionally done this way?
> 
> Sincerely,
> Dmitriy Pavlov
> 
> вт, 31 июл. 2018 г. в 15:57, Nikolay Izhikov :
> 
>> Hello, Igniters.
>> 
>> Release page created [1].
>> 
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7
>> 
>> В Пт, 27/07/2018 в 00:52 -0700, Denis Magda пишет:
>>> Sure, it can wait. Thanks! Take a rest )
>>> 
>>> On Thu, Jul 26, 2018 at 11:39 PM Nikolay Izhikov 
>>> wrote:
>>> 
 Hello, Denis.
 
 Actually, I'm on vacation till July, 31.
 After it I will put all my efforts to manage Ignite release.
 
 Can we wait until Tuesday?
 
 В Чт, 26/07/2018 в 17:01 -0700, Denis Magda пишет:
> Nikolay,
> 
> Could you please prepare Ignite 2.7 page similar to the following?
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> 
> We need to start tracking the progress and most essential
>> capabilities
 
 that will get into the release.
> 
> --
> Denis
> On Tue, Jul 24, 2018 at 1:39 AM Vyacheslav Daradur <
>> daradu...@gmail.com>
 
 wrote:
>> Hi, Igniters!
>> 
>> The end of September for Ignite 2.7 release sounds good to me.
>> 
>> I'm working on Service Grid and going to deliver the following
>> tasks:
>> - Use discovery messages for service deployment [[1]
>> - Collect service deployment results asynchronously on coordinator
>> [2]
>> - Propagate service deployment results from assigned nodes to
 
 initiator [3]
>> - Handle topology changes during service deployment [4]
>> - Propagate deployed services to joining nodes [5]
>> - Replace service instance parameter with a class name in
>> ServiceConfiguration [6] (planned to be implemented by Amelchev
>> Nikita)
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-8361
>> [2] https://issues.apache.org/jira/browse/IGNITE-8362
>> [3] https://issues.apache.org/jira/browse/IGNITE-3392
>> [4] https://issues.apache.org/jira/browse/IGNITE-8363
>> [5] https://issues.apache.org/jira/browse/IGNITE-8364
>> [6] https://issues.apache.org/jira/browse/IGNITE-8366
>> On Mon, Jul 23, 2018 at 4:02 PM Dmitry Pavlov <
>> dpavlov@gmail.com>
 
 wrote:
>>> 
>>> Hi Denis, Nikolay,
>>> 
>>> I've issued a number of tickets to update dependencies versions.
>> I
 
 would
>>> like all these updates are available within 2.7.
>>> 
>>> Sincerely,
>>> Dmitriy Pavlov
>>> 
>>> сб, 21 июл. 2018 г. в 3:28, Pavel Petroshenko <
>> pa...@petroshenko.com
> 
> :
>>> 
 Hi Denis, Nikolay,
 
 The proposed 2.7 release timing sounds reasonable to me.
 Python [1], PHP [2], and Node.js [3] thin clients should take
>> the
 
 train.
 
 p.
 
 [1] https://jira.apache.org/jira/browse/IGNITE-7782
 [2] https://jira.apache.org/jira/browse/IGNITE-7783
 [3] https://jira.apache.org/jira/browse/IGNITE-
 
 
 On Fri, Jul 20, 2018 at 2:35 PM, Denis Magda <
>> dma...@gridgain.com>
 
 wrote:
 
> Igniters,
> 
> Let's agree on the time and the scope of 2.7. As for the
>> release
 
 manager,
> we had a conversation with Nikolay Izhikov and he decided to
>> try
 
 the role
> out. Thanks, Nikolay!
> 
> Nikolay, we need to prepare a page like that [1] once the
 
 release terms
 are
> defined.
> 
> I propose us to roll Ignite 2.7 at the end of September.
>> Folks
 
 who are
> working on SQL, core, C++/NET, thin clients, ML, service grid
> optimizations, data structures please enlist what you're
>> ready to
 
 deliver.
> 
> 
> [1]
 
 https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> 
>> 
>> 
>> 

Re: iep-6 metrics ticket review

[Dmitriy Pavlov]

Hi,

Alexey, yes, that's right, it seems, we discussed this. Merged to master.

Alexey, thank you for contribution,
Dmitriy, Val, thank you for review.
Ilya, thank you for checking solution performance.

Sincerely,
Dmitriy Pavlov

вт, 31 июл. 2018 г. в 14:42, Aleksey Kuznetsov :

> Hi!
>
> Yes, I added `GridCacheNearAtomicMetricsSelfTest` to test atomic
> configuration, but `testNearRead` is broken.
>
> We agreed to proceed with this test broken and fix it later : [1]
>
> [1] :
> https://issues.apache.org/jira/browse/IGNITE-6846?focusedCommentId=16417786&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16417786
>
> I'm going to fix it after current ticket.
>
> вт, 31 июл. 2018 г. в 14:28, Dmitriy Pavlov :
> >
> > Hi Alexey,
> >
> > I've found test failure, which is not executied in master
> >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8815184974848592565&branch=pull%2F3148%2Fhead&tab=testDetails&branch_IgniteTests24Java8=__all_branches__
> >
> > Is it newly contributed test? Why it fails in PR?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 31 июл. 2018 г. в 13:01, Dmitriy Pavlov :
> >
> > > Hi Ilya,
> > >
> > > Great, thanks! I'm going to apply this patch.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вт, 31 июл. 2018 г. в 12:35, Ilya Suntsov :
> > >
> > >> Dmitry G.,
> > >>
> > >> I've run yardstick pds benchmarks against PR-3148 and master and can
> > >> confirm that fixes from PR don't affect performance.
> > >>
> > >> 2018-07-26 18:38 GMT+03:00 Dmitry Pavlov :
> > >>
> > >>> Hi Ilya,
> > >>>
> > >>> We all agreed change is good, but we'd like to be absolutely sure
> there
> > >>> is no performance drop. Dmitriy G. was one from reviewer, so I hope
> he
> > >>> would provide any additional info about change.
> > >>>
> > >>> Could you please assist here?
> > >>>
> > >>> Sincerely,
> > >>> Dmitriy Pavlov
> > >>>
> > >>> чт, 26 июл. 2018 г. в 18:25, Aleksey Kuznetsov <
> alkuznetsov...@gmail.com
> > >>> >:
> > >>>
> >  Hi, Igniters!
> > 
> >  I have the ticket [1] reviewed, it introduce large changes to cache.
> > 
> >  How can I assure it causes no performance drop ?
> > 
> >  [1] : https://issues.apache.org/jira/browse/IGNITE-6846
> > 
> >  ср, 11 апр. 2018 г. в 3:32, Valentin Kulichenko <
> >  valentin.kuliche...@gmail.com>:
> > 
> >  > This is on my plate, will try to take a look this week.
> >  >
> >  > -Val
> >  >
> >  > On Mon, Apr 9, 2018 at 10:28 AM, Denis Magda 
> >  wrote:
> >  >
> >  > > Val,
> >  > >
> >  > > As an initial reviewer and reporter, could you have a look and
> sign
> >  the
> >  > > contribution off?
> >  > >
> >  > > --
> >  > > Denis
> >  > >
> >  > > On Mon, Apr 9, 2018 at 12:56 AM, Aleksey Kuznetsov <
> >  > > alkuznetsov...@gmail.com
> >  > > > wrote:
> >  > >
> >  > > > Hi ,Igniters!
> >  > > >
> >  > > > Do we still need this ticket, about invoke metrics : [1] ?
> >  > > >
> >  > > > If yes, than could somebody review it ?
> >  > > >
> >  > > > If no, should we close this ticket ?
> >  > > >
> >  > > > [1] : https://issues.apache.org/jira/browse/IGNITE-6846
> >  > > > --
> >  > > >
> >  > > > *Best Regards,*
> >  > > >
> >  > > > *Kuznetsov Aleksey*
> >  > > >
> >  > >
> >  >
> > 
> > >>>
> > >>
> > >>
> > >> --
> > >> Best Regards,
> > >> Ilya Suntsov
> > >> email: isunt...@gridgain.com
> > >> *GridGain Systems*
> > >> www.gridgain.com
> > >>
> > >
>

Re: Apache Ignite 2.7: scope, time and release manager

[Dmitriy Pavlov]

Hi Nikolay,

Thank you for this page. It seems font size for some filters is bigger than
for others. It is intentionally done this way?

Sincerely,
Dmitriy Pavlov

вт, 31 июл. 2018 г. в 15:57, Nikolay Izhikov :

> Hello, Igniters.
>
> Release page created [1].
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7
>
> В Пт, 27/07/2018 в 00:52 -0700, Denis Magda пишет:
> > Sure, it can wait. Thanks! Take a rest )
> >
> > On Thu, Jul 26, 2018 at 11:39 PM Nikolay Izhikov 
> > wrote:
> >
> > > Hello, Denis.
> > >
> > > Actually, I'm on vacation till July, 31.
> > > After it I will put all my efforts to manage Ignite release.
> > >
> > > Can we wait until Tuesday?
> > >
> > > В Чт, 26/07/2018 в 17:01 -0700, Denis Magda пишет:
> > > > Nikolay,
> > > >
> > > > Could you please prepare Ignite 2.7 page similar to the following?
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> > > >
> > > > We need to start tracking the progress and most essential
> capabilities
> > >
> > > that will get into the release.
> > > >
> > > > --
> > > > Denis
> > > > On Tue, Jul 24, 2018 at 1:39 AM Vyacheslav Daradur <
> daradu...@gmail.com>
> > >
> > > wrote:
> > > > > Hi, Igniters!
> > > > >
> > > > > The end of September for Ignite 2.7 release sounds good to me.
> > > > >
> > > > > I'm working on Service Grid and going to deliver the following
> tasks:
> > > > > - Use discovery messages for service deployment [[1]
> > > > > - Collect service deployment results asynchronously on coordinator
> [2]
> > > > > - Propagate service deployment results from assigned nodes to
> > >
> > > initiator [3]
> > > > > - Handle topology changes during service deployment [4]
> > > > > - Propagate deployed services to joining nodes [5]
> > > > > - Replace service instance parameter with a class name in
> > > > > ServiceConfiguration [6] (planned to be implemented by Amelchev
> > > > > Nikita)
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8361
> > > > > [2] https://issues.apache.org/jira/browse/IGNITE-8362
> > > > > [3] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > [4] https://issues.apache.org/jira/browse/IGNITE-8363
> > > > > [5] https://issues.apache.org/jira/browse/IGNITE-8364
> > > > > [6] https://issues.apache.org/jira/browse/IGNITE-8366
> > > > > On Mon, Jul 23, 2018 at 4:02 PM Dmitry Pavlov <
> dpavlov@gmail.com>
> > >
> > > wrote:
> > > > > >
> > > > > > Hi Denis, Nikolay,
> > > > > >
> > > > > > I've issued a number of tickets to update dependencies versions.
> I
> > >
> > > would
> > > > > > like all these updates are available within 2.7.
> > > > > >
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > >
> > > > > > сб, 21 июл. 2018 г. в 3:28, Pavel Petroshenko <
> pa...@petroshenko.com
> > > >
> > > > :
> > > > > >
> > > > > > > Hi Denis, Nikolay,
> > > > > > >
> > > > > > > The proposed 2.7 release timing sounds reasonable to me.
> > > > > > > Python [1], PHP [2], and Node.js [3] thin clients should take
> the
> > >
> > > train.
> > > > > > >
> > > > > > > p.
> > > > > > >
> > > > > > > [1] https://jira.apache.org/jira/browse/IGNITE-7782
> > > > > > > [2] https://jira.apache.org/jira/browse/IGNITE-7783
> > > > > > > [3] https://jira.apache.org/jira/browse/IGNITE-
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jul 20, 2018 at 2:35 PM, Denis Magda <
> dma...@gridgain.com>
> > >
> > > wrote:
> > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > Let's agree on the time and the scope of 2.7. As for the
> release
> > >
> > > manager,
> > > > > > > > we had a conversation with Nikolay Izhikov and he decided to
> try
> > >
> > > the role
> > > > > > > > out. Thanks, Nikolay!
> > > > > > > >
> > > > > > > > Nikolay, we need to prepare a page like that [1] once the
> > >
> > > release terms
> > > > > > > are
> > > > > > > > defined.
> > > > > > > >
> > > > > > > > I propose us to roll Ignite 2.7 at the end of September.
> Folks
> > >
> > > who are
> > > > > > > > working on SQL, core, C++/NET, thin clients, ML, service grid
> > > > > > > > optimizations, data structures please enlist what you're
> ready to
> > > > > > >
> > > > > > > deliver.
> > > > > > > >
> > > > > > > >
> > > > > > > > [1]
> > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> > > > > > > >
> > > > >
> > > > >
> > > > >

[GitHub] ignite pull request #3148: Ignite-6846 Add metrics for entry processor invoc...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite 2.7: scope, time and release manager

[Nikolay Izhikov]

Hello, Igniters.

Release page created [1].

[1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7

В Пт, 27/07/2018 в 00:52 -0700, Denis Magda пишет:
> Sure, it can wait. Thanks! Take a rest )
> 
> On Thu, Jul 26, 2018 at 11:39 PM Nikolay Izhikov 
> wrote:
> 
> > Hello, Denis.
> > 
> > Actually, I'm on vacation till July, 31.
> > After it I will put all my efforts to manage Ignite release.
> > 
> > Can we wait until Tuesday?
> > 
> > В Чт, 26/07/2018 в 17:01 -0700, Denis Magda пишет:
> > > Nikolay,
> > > 
> > > Could you please prepare Ignite 2.7 page similar to the following?
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> > > 
> > > We need to start tracking the progress and most essential capabilities
> > 
> > that will get into the release.
> > > 
> > > --
> > > Denis
> > > On Tue, Jul 24, 2018 at 1:39 AM Vyacheslav Daradur 
> > 
> > wrote:
> > > > Hi, Igniters!
> > > > 
> > > > The end of September for Ignite 2.7 release sounds good to me.
> > > > 
> > > > I'm working on Service Grid and going to deliver the following tasks:
> > > > - Use discovery messages for service deployment [[1]
> > > > - Collect service deployment results asynchronously on coordinator [2]
> > > > - Propagate service deployment results from assigned nodes to
> > 
> > initiator [3]
> > > > - Handle topology changes during service deployment [4]
> > > > - Propagate deployed services to joining nodes [5]
> > > > - Replace service instance parameter with a class name in
> > > > ServiceConfiguration [6] (planned to be implemented by Amelchev
> > > > Nikita)
> > > > 
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-8361
> > > > [2] https://issues.apache.org/jira/browse/IGNITE-8362
> > > > [3] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > [4] https://issues.apache.org/jira/browse/IGNITE-8363
> > > > [5] https://issues.apache.org/jira/browse/IGNITE-8364
> > > > [6] https://issues.apache.org/jira/browse/IGNITE-8366
> > > > On Mon, Jul 23, 2018 at 4:02 PM Dmitry Pavlov 
> > 
> > wrote:
> > > > > 
> > > > > Hi Denis, Nikolay,
> > > > > 
> > > > > I've issued a number of tickets to update dependencies versions. I
> > 
> > would
> > > > > like all these updates are available within 2.7.
> > > > > 
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > > 
> > > > > сб, 21 июл. 2018 г. в 3:28, Pavel Petroshenko  > > 
> > > :
> > > > > 
> > > > > > Hi Denis, Nikolay,
> > > > > > 
> > > > > > The proposed 2.7 release timing sounds reasonable to me.
> > > > > > Python [1], PHP [2], and Node.js [3] thin clients should take the
> > 
> > train.
> > > > > > 
> > > > > > p.
> > > > > > 
> > > > > > [1] https://jira.apache.org/jira/browse/IGNITE-7782
> > > > > > [2] https://jira.apache.org/jira/browse/IGNITE-7783
> > > > > > [3] https://jira.apache.org/jira/browse/IGNITE-
> > > > > > 
> > > > > > 
> > > > > > On Fri, Jul 20, 2018 at 2:35 PM, Denis Magda 
> > 
> > wrote:
> > > > > > 
> > > > > > > Igniters,
> > > > > > > 
> > > > > > > Let's agree on the time and the scope of 2.7. As for the release
> > 
> > manager,
> > > > > > > we had a conversation with Nikolay Izhikov and he decided to try
> > 
> > the role
> > > > > > > out. Thanks, Nikolay!
> > > > > > > 
> > > > > > > Nikolay, we need to prepare a page like that [1] once the
> > 
> > release terms
> > > > > > are
> > > > > > > defined.
> > > > > > > 
> > > > > > > I propose us to roll Ignite 2.7 at the end of September. Folks
> > 
> > who are
> > > > > > > working on SQL, core, C++/NET, thin clients, ML, service grid
> > > > > > > optimizations, data structures please enlist what you're ready to
> > > > > > 
> > > > > > deliver.
> > > > > > > 
> > > > > > > 
> > > > > > > [1]
> > 
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> > > > > > > 
> > > > 
> > > > 
> > > > 

signature.asc
Description: This is a digitally signed message part

[GitHub] ignite pull request #4461: IGNITE-9134: ZookeeperDiscoverySpiTest#testLargeU...

[BiryukovVA]

GitHub user BiryukovVA opened a pull request:

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

IGNITE-9134: ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with 
OOME.



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

$ git pull https://github.com/BiryukovVA/ignite IGNITE-9134

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

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


commit c430a34c477e5c2b0f60a34335277910c5982691
Author: Vitaliy Biryukov 
Date:   2018-07-31T12:46:25Z

IGNITE-9134: ZookeeperDiscoverySpiTest#testLargeUserAttribute3 fails with 
OOME.




---

[GitHub] ignite pull request #4460: IGNITE-9114

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-9114



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

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

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

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


commit 91b9501b9e5844e76276739514445058df7b66ee
Author: devozerov 
Date:   2018-07-31T12:15:30Z

Better timeout management.




---

[jira] [Created] (IGNITE-9144) A client node leaving a grid may trigger the wrong message about coordinator change in the logs

[Ivan Artukhov (JIRA)]

Ivan Artukhov created IGNITE-9144:
-

 Summary: A client node leaving a grid may trigger the wrong 
message about coordinator change in the logs
 Key: IGNITE-9144
 URL: https://issues.apache.org/jira/browse/IGNITE-9144
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Artukhov


The issue was introduced by https://issues.apache.org/jira/browse/IGNITE-8738.

Suppose we have a grid with X server nodes and Y client nodes. Server nodes are 
restarted periodically while client nodes are left untouched. In this case 
*order* of current coordinator might be greater than *order* of any client 
node. Then when some client node leaves the grid, we will erroneously print the 
*Coordinator changed* message with *client* node being the previous 
coordinator. E.g.:

{noformat}
[2018-07-19 14:55:28,897][INFO ][disco-event-worker-#61] Node left topology: 
TcpDiscoveryNode [id=7240957f-a51b-452d-bfc8-420e8ef9ea68, addrs=[127.0.0.1, 
172.17.0.1, 172.25.1.15], sockAddrs=[/172.17.0.1:0, /127.0.0.1:0, 
lab15.gridgain.local/172.25.1.15:0], discPort=0, order=16, intOrder=11, 
lastExchangeTime=1532001260398, loc=false, ver=2.5.1#20180717-sha1:80e51c80, 
isClient=true]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Topology snapshot 
[ver=27, servers=3, clients=4, CPUs=96, offheap=260.0GB, heap=56.0GB]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Coordinator changed 
[prev=TcpDiscoveryNode [id=7240957f-a51b-452d-bfc8-420e8ef9ea68, 
addrs=[127.0.0.1, 172.17.0.1, 172.25.1.15], sockAddrs=[/172.17.0.1:0, 
/127.0.0.1:0, lab15.gridgain.local/172.25.1.15:0], discPort=0, order=16, 
intOrder=11, lastExchangeTime=1532001260398, loc=false, 
ver=2.5.1#20180717-sha1:80e51c80, isClient=true], cur=TcpDiscoveryNode 
[id=760fd8f2-b9d7-4953-aa86-3954c05c9feb, addrs=[127.0.0.1, 172.17.0.1, 
172.25.1.21], sockAddrs=[/172.17.0.1:47500, 
lab21.gridgain.local/172.25.1.21:47500, /127.0.0.1:47500], discPort=47500, 
order=21, intOrder=15, lastExchangeTime=1532001260428, loc=false, 
ver=2.5.1#20180717-sha1:80e51c80, isClient=false]]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61]   ^-- Node 
[id=22B15E97-9944-48B5-A473-5C64E75A4D5A, clusterState=ACTIVE]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61]   ^-- Baseline [id=6, 
size=3, online=3, offline=0]
[2018-07-19 14:55:28,899][INFO ][disco-event-worker-#61] Data Regions 
Configured:
[2018-07-19 14:55:28,900][INFO ][disco-event-worker-#61]   ^-- default 
[initSize=256.0 MiB, maxSize=60.0 GiB, persistenceEnabled=true]
{noformat}

The *Coordinator changed* message should not be here because in fact the 
coordinator was not changed.



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

Re: iep-6 metrics ticket review

[Aleksey Kuznetsov]

Hi!

Yes, I added `GridCacheNearAtomicMetricsSelfTest` to test atomic
configuration, but `testNearRead` is broken.

We agreed to proceed with this test broken and fix it later : [1]

[1] : 
https://issues.apache.org/jira/browse/IGNITE-6846?focusedCommentId=16417786&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16417786

I'm going to fix it after current ticket.

вт, 31 июл. 2018 г. в 14:28, Dmitriy Pavlov :
>
> Hi Alexey,
>
> I've found test failure, which is not executied in master
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8815184974848592565&branch=pull%2F3148%2Fhead&tab=testDetails&branch_IgniteTests24Java8=__all_branches__
>
> Is it newly contributed test? Why it fails in PR?
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 31 июл. 2018 г. в 13:01, Dmitriy Pavlov :
>
> > Hi Ilya,
> >
> > Great, thanks! I'm going to apply this patch.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 31 июл. 2018 г. в 12:35, Ilya Suntsov :
> >
> >> Dmitry G.,
> >>
> >> I've run yardstick pds benchmarks against PR-3148 and master and can
> >> confirm that fixes from PR don't affect performance.
> >>
> >> 2018-07-26 18:38 GMT+03:00 Dmitry Pavlov :
> >>
> >>> Hi Ilya,
> >>>
> >>> We all agreed change is good, but we'd like to be absolutely sure there
> >>> is no performance drop. Dmitriy G. was one from reviewer, so I hope he
> >>> would provide any additional info about change.
> >>>
> >>> Could you please assist here?
> >>>
> >>> Sincerely,
> >>> Dmitriy Pavlov
> >>>
> >>> чт, 26 июл. 2018 г. в 18:25, Aleksey Kuznetsov  >>> >:
> >>>
>  Hi, Igniters!
> 
>  I have the ticket [1] reviewed, it introduce large changes to cache.
> 
>  How can I assure it causes no performance drop ?
> 
>  [1] : https://issues.apache.org/jira/browse/IGNITE-6846
> 
>  ср, 11 апр. 2018 г. в 3:32, Valentin Kulichenko <
>  valentin.kuliche...@gmail.com>:
> 
>  > This is on my plate, will try to take a look this week.
>  >
>  > -Val
>  >
>  > On Mon, Apr 9, 2018 at 10:28 AM, Denis Magda 
>  wrote:
>  >
>  > > Val,
>  > >
>  > > As an initial reviewer and reporter, could you have a look and sign
>  the
>  > > contribution off?
>  > >
>  > > --
>  > > Denis
>  > >
>  > > On Mon, Apr 9, 2018 at 12:56 AM, Aleksey Kuznetsov <
>  > > alkuznetsov...@gmail.com
>  > > > wrote:
>  > >
>  > > > Hi ,Igniters!
>  > > >
>  > > > Do we still need this ticket, about invoke metrics : [1] ?
>  > > >
>  > > > If yes, than could somebody review it ?
>  > > >
>  > > > If no, should we close this ticket ?
>  > > >
>  > > > [1] : https://issues.apache.org/jira/browse/IGNITE-6846
>  > > > --
>  > > >
>  > > > *Best Regards,*
>  > > >
>  > > > *Kuznetsov Aleksey*
>  > > >
>  > >
>  >
> 
> >>>
> >>
> >>
> >> --
> >> Best Regards,
> >> Ilya Suntsov
> >> email: isunt...@gridgain.com
> >> *GridGain Systems*
> >> www.gridgain.com
> >>
> >

Re: iep-6 metrics ticket review

[Dmitriy Pavlov]

Hi Alexey,

I've found test failure, which is not executied in master
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8815184974848592565&branch=pull%2F3148%2Fhead&tab=testDetails&branch_IgniteTests24Java8=__all_branches__

Is it newly contributed test? Why it fails in PR?

Sincerely,
Dmitriy Pavlov

вт, 31 июл. 2018 г. в 13:01, Dmitriy Pavlov :

> Hi Ilya,
>
> Great, thanks! I'm going to apply this patch.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 31 июл. 2018 г. в 12:35, Ilya Suntsov :
>
>> Dmitry G.,
>>
>> I've run yardstick pds benchmarks against PR-3148 and master and can
>> confirm that fixes from PR don't affect performance.
>>
>> 2018-07-26 18:38 GMT+03:00 Dmitry Pavlov :
>>
>>> Hi Ilya,
>>>
>>> We all agreed change is good, but we'd like to be absolutely sure there
>>> is no performance drop. Dmitriy G. was one from reviewer, so I hope he
>>> would provide any additional info about change.
>>>
>>> Could you please assist here?
>>>
>>> Sincerely,
>>> Dmitriy Pavlov
>>>
>>> чт, 26 июл. 2018 г. в 18:25, Aleksey Kuznetsov >> >:
>>>
 Hi, Igniters!

 I have the ticket [1] reviewed, it introduce large changes to cache.

 How can I assure it causes no performance drop ?

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

 ср, 11 апр. 2018 г. в 3:32, Valentin Kulichenko <
 valentin.kuliche...@gmail.com>:

 > This is on my plate, will try to take a look this week.
 >
 > -Val
 >
 > On Mon, Apr 9, 2018 at 10:28 AM, Denis Magda 
 wrote:
 >
 > > Val,
 > >
 > > As an initial reviewer and reporter, could you have a look and sign
 the
 > > contribution off?
 > >
 > > --
 > > Denis
 > >
 > > On Mon, Apr 9, 2018 at 12:56 AM, Aleksey Kuznetsov <
 > > alkuznetsov...@gmail.com
 > > > wrote:
 > >
 > > > Hi ,Igniters!
 > > >
 > > > Do we still need this ticket, about invoke metrics : [1] ?
 > > >
 > > > If yes, than could somebody review it ?
 > > >
 > > > If no, should we close this ticket ?
 > > >
 > > > [1] : https://issues.apache.org/jira/browse/IGNITE-6846
 > > > --
 > > >
 > > > *Best Regards,*
 > > >
 > > > *Kuznetsov Aleksey*
 > > >
 > >
 >

>>>
>>
>>
>> --
>> Best Regards,
>> Ilya Suntsov
>> email: isunt...@gridgain.com
>> *GridGain Systems*
>> www.gridgain.com
>>
>

[jira] [Created] (IGNITE-9143) Web console: SQL buttons are disabled in case when it must be enabled

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-9143:
--

 Summary: Web console: SQL buttons are disabled in case when it 
must be enabled
 Key: IGNITE-9143
 URL: https://issues.apache.org/jira/browse/IGNITE-9143
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


Create a new notebook.
Start writing a new query.




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

[jira] [Created] (IGNITE-9142) CacheAsyncOperationsFailoverTxTest hangs because of hanging optimistic transaction

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-9142:
-

 Summary: CacheAsyncOperationsFailoverTxTest hangs because of 
hanging optimistic transaction
 Key: IGNITE-9142
 URL: https://issues.apache.org/jira/browse/IGNITE-9142
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev


https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1542329&_focus=2400075


{code}
"main" #1 prio=5 os_prio=0 tid=0x7f9ea000d000 nid=0x437d waiting on 
condition [0x7f9ea901b000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:816)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.loadData(DataStreamerImpl.java:700)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:666)
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.removeDataInternal(DataStreamerImpl.java:619)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter$GlobalRemoveAllJob.localExecute(GridDistributedCacheAdapter.java:467)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$TopologyVersionAwareJob.execute(GridCacheAdapter.java:6233)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6744)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1407)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:660)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:760)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:452)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:408)
at 
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.removeAll(GridDistributedCacheAdapter.java:188)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.removeAll(IgniteCacheProxyImpl.java:1333)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.removeAll(GatewayProtectedCacheProxy.java:1081)
at 
org.apache.ignite.internal.processors.cache.GridCacheAbstractSelfTest$1.applyx(GridCacheAbstractSelfTest.java:150)
at 
org.apache.ignite.internal.util.lang.GridAbsPredicateX.apply(GridAbsPredicateX.java:32)
at 
org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1647)
at 
org.apache.ignite.internal.processors.cache.GridCacheAbstractSelfTest.afterTest(GridCacheAbstractSelfTest.java:146)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1694)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:503)
at junit.framework.TestCase.runBare(TestCase.java:146)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:369)
at 
org.apache.maven.surefire.junit4.

Local Continuous Query

[Denis Mekhanikov]

Igniters,

As you may know, *ContinuousQuery
*
class
extends the *Query

*class, so *setLocal *method is applicable to *ContinuousQuery *as well.
Behaviour of such queries is not documented at all, and it's unclear, how
they should work.

In particular, local continuous queries work differently for partitioned
and replicated caches, even if a node contains all backup partitions.
Listener for a local continuous query is invoked only for primary
partitions in case of a partitioned cache, and for all partitions in case
of a replicated cache.

Is it supposed to work like this?

I agree to leave this behaviour untouched, but it certainly needs to be
documented.

Denis

[jira] [Created] (IGNITE-9141) SQL: Trace and test query mapping problems

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-9141:
---

 Summary: SQL: Trace and test query mapping problems
 Key: IGNITE-9141
 URL: https://issues.apache.org/jira/browse/IGNITE-9141
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.6
Reporter: Vladimir Ozerov
 Fix For: 2.7






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

[jira] [Created] (IGNITE-9140) Web console: incorrect X-axis lebel format for TIME_LINE

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-9140:
--

 Summary: Web console: incorrect X-axis lebel format for TIME_LINE
 Key: IGNITE-9140
 URL: https://issues.apache.org/jira/browse/IGNITE-9140
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov
 Attachments: screenshot-1.png

Start Demo
Open the Demo notebook
Open the Chart Settings
Change the value for X-axis to ROW_ID and then return to TIME_LINE




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

Re: SSLParameters for SslContextFactory

[Mikhail Cherkasov]

> I have commented your change: setProtocols is still redundant since we
have protocol in sslContextFactory.

it's not the same, the protocol field allows to set only one particular
protocol, while protocols allow you to set several different versions, for
example with protocols you can set:
TLSv1.1 and TLSv1.2, but exclude TLSv1.0.

> there is a caveat with ciphers list: by default SSL will fail if you ever
list a cipher there that is not present in current JVM

these are options for subtle SSL configuration, so it requires some
understanding what you do.

On Mon, Jul 30, 2018 at 6:54 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> Thank you! I have commented your change: setProtocols is still redundant
> since we have protocol in sslContextFactory.
>
> BTW, there is a caveat with ciphers list: by default SSL will fail if you
> ever list a cipher there that is not present in current JVM, even if the
> rest of them are present and can be used. Thus the configuration becomes
> fragile. However I don't think it's our job to take care of that.
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-07-30 18:12 GMT+03:00 Michael Cherkasov  >:
>
> > Hi all,
> >
> > as was suggested, I removed all mention about SSLParameters and replaced
> it
> > with a simple String[].
> > I added configurations for protocols and cipher suites.
> >
> > Please, review .
> >
> > Thanks,
> > Mike.
> >
> >
> >
> > 2018-07-30 13:58 GMT+03:00 Vladimir Ozerov :
> >
> > > Agree. It is much easier for user to set a collection of strings
> > > (especially from Spring), rather than construct some complex Java 8
> > object.
> > > Also we need to remember that this feature should be propagated to all
> > thin
> > > clients and .NET integration. String getter/setter is only way to
> > maintain
> > > API consistency across various platforms.
> > >
> > > On Thu, Jul 26, 2018 at 9:16 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > I really dislike the fact that SSLParameters has 6 setter methods,
> and
> > we
> > > > only support one of them, when two more clash with SSL settings which
> > are
> > > > set elsewhere.
> > > >
> > > > I.e. what happens if I pass SSLParameters with
> > setAlgorithmConstraints()
> > > or
> > > > setProtocols() called on them?
> > > >
> > > > Is it possible that we will just have an array of allowed ciphers in
> > > > configuration?
> > > >
> > > > Regards,
> > > >
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > > 2018-07-26 20:16 GMT+03:00 Michael Cherkasov <
> > > michael.cherka...@gmail.com
> > > > >:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I want to add SSLParameters for SslContextFactory.
> > > > >
> > > > > Right now there's no way to specify a particular set of cipher
> suites
> > > > that
> > > > > you want to use.
> > > > > there's even old request to add this functionality:
> > > > > https://issues.apache.org/jira/browse/IGNITE-6167
> > > > > even with current API you can achieve this, but this requires a lot
> > of
> > > > > boilerplate code, to avoid this I added SSLParameters, that would
> be
> > > > > applied to all SSL connections, please review my pull request:
> > > > > https://github.com/apache/ignite/pull/4440
> > > > >
> > > > > I think this patch covers 6167, so I want to push it in context of
> > this
> > > > > ticket.
> > > > >
> > > > > Thanks,
> > > > > Mike.
> > > > >
> > > >
> > >
> >
>


-- 
Thanks,
Mikhail.

Re: iep-6 metrics ticket review

[Dmitriy Pavlov]

Hi Ilya,

Great, thanks! I'm going to apply this patch.

Sincerely,
Dmitriy Pavlov

вт, 31 июл. 2018 г. в 12:35, Ilya Suntsov :

> Dmitry G.,
>
> I've run yardstick pds benchmarks against PR-3148 and master and can
> confirm that fixes from PR don't affect performance.
>
> 2018-07-26 18:38 GMT+03:00 Dmitry Pavlov :
>
>> Hi Ilya,
>>
>> We all agreed change is good, but we'd like to be absolutely sure there
>> is no performance drop. Dmitriy G. was one from reviewer, so I hope he
>> would provide any additional info about change.
>>
>> Could you please assist here?
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> чт, 26 июл. 2018 г. в 18:25, Aleksey Kuznetsov > >:
>>
>>> Hi, Igniters!
>>>
>>> I have the ticket [1] reviewed, it introduce large changes to cache.
>>>
>>> How can I assure it causes no performance drop ?
>>>
>>> [1] : https://issues.apache.org/jira/browse/IGNITE-6846
>>>
>>> ср, 11 апр. 2018 г. в 3:32, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com>:
>>>
>>> > This is on my plate, will try to take a look this week.
>>> >
>>> > -Val
>>> >
>>> > On Mon, Apr 9, 2018 at 10:28 AM, Denis Magda 
>>> wrote:
>>> >
>>> > > Val,
>>> > >
>>> > > As an initial reviewer and reporter, could you have a look and sign
>>> the
>>> > > contribution off?
>>> > >
>>> > > --
>>> > > Denis
>>> > >
>>> > > On Mon, Apr 9, 2018 at 12:56 AM, Aleksey Kuznetsov <
>>> > > alkuznetsov...@gmail.com
>>> > > > wrote:
>>> > >
>>> > > > Hi ,Igniters!
>>> > > >
>>> > > > Do we still need this ticket, about invoke metrics : [1] ?
>>> > > >
>>> > > > If yes, than could somebody review it ?
>>> > > >
>>> > > > If no, should we close this ticket ?
>>> > > >
>>> > > > [1] : https://issues.apache.org/jira/browse/IGNITE-6846
>>> > > > --
>>> > > >
>>> > > > *Best Regards,*
>>> > > >
>>> > > > *Kuznetsov Aleksey*
>>> > > >
>>> > >
>>> >
>>>
>>
>
>
> --
> Best Regards,
> Ilya Suntsov
> email: isunt...@gridgain.com
> *GridGain Systems*
> www.gridgain.com
>

[GitHub] ignite pull request #4453: IGNITE-9114

[devozerov]

Github user devozerov closed the pull request at:

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


---

Re: Spark DataFrames With Cache Key and Value Objects

[Nikolay Izhikov]

Hello, Igniters.

Valentin, 

> We never recommend to use these fields

Actually, we did:

* Documentation [1]. Please, see "Predefined Fields" section.
* Java Example [2]
* DotNet Example [3]
* Scala Example [4]

> ...hopefully will be removed altogether one day

This is new for me.

Do we have specific plans for it?

[1] https://apacheignite-sql.readme.io/docs/schema-and-indexes
[2] 
https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/sql/SqlDmlExample.java#L88
[3] 
https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/examples/Apache.Ignite.Examples/Sql/SqlDmlExample.cs#L91
[4] 
https://github.com/apache/ignite/blob/master/examples/src/main/scala/org/apache/ignite/scalar/examples/ScalarCachePopularNumbersExample.scala#L124

В Пт, 27/07/2018 в 15:22 -0700, Valentin Kulichenko пишет:
> Stuart,
> 
> _key and _val fields is quite a dirty hack that was added years ago and is
> virtually never used now. We never recommend to use these fields and I
> would definitely avoid building new features based on them.
> 
> Having said that, I'm not arguing the use case, but we need better
> implementation approach here. I suggest we think it over and come back to
> this next week :) I'm sure Nikolay will also chime in and share his
> thoughts.
> 
> -Val
> 
> On Fri, Jul 27, 2018 at 12:39 PM Stuart Macdonald  wrote:
> 
> > If your predicates and joins are expressed in Spark SQL, you cannot
> > currently optimise those and also gain access to the key/val objects. If
> > you went without the Ignite Spark SQL optimisations and expressed your
> > query in Ignite SQL, you still need to use the _key/_val columns. The
> > Ignite documentation has this specific example using the _val column (right
> > at the end):
> > https://apacheignite-fs.readme.io/docs/ignitecontext-igniterdd
> > 
> > Stuart.
> > 
> > On 27 Jul 2018, at 20:05, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>
> > wrote:
> > 
> > Well, the second approach would use the optimizations, no?
> > 
> > -Val
> > 
> > 
> > On Fri, Jul 27, 2018 at 11:49 AM Stuart Macdonald 
> > wrote:
> > 
> > Val,
> > 
> > 
> > Yes you can already get access to the cache objects as an RDD or
> > 
> > Dataset but you can’t use the Ignite-optimised DataFrames with these
> > 
> > mechanisms. Optimised DataFrames have to be passed through Spark SQL’s
> > 
> > Catalyst engine to allow for predicate pushdown to Ignite. So the
> > 
> > usecase we’re talking about here is when we want to be able to push
> > 
> > Spark filters/joins to Ignite to optimise, but still have access to
> > 
> > the underlying cache objects, which is not possible currently.
> > 
> > 
> > Can you elaborate on the reason _key and _val columns in Ignite SQL
> > 
> > will be removed?
> > 
> > 
> > Stuart.
> > 
> > 
> > On 27 Jul 2018, at 19:39, Valentin Kulichenko <
> > 
> > valentin.kuliche...@gmail.com> wrote:
> > 
> > 
> > Stuart, Nikolay,
> > 
> > 
> > I really don't like the idea of exposing '_key' and '_val' fields. This
> > 
> > is
> > 
> > legacy stuff that hopefully will be removed altogether one day. Let's not
> > 
> > use it in new features.
> > 
> > 
> > Actually, I don't even think it's even needed. Spark docs [1] suggest two
> > 
> > ways of creating a typed dataset:
> > 
> > 1. Based on RDD. This should be supported using IgniteRDD I believe.
> > 
> > 2. Based on DataFrame providing a class. This would just work out of the
> > 
> > box I guess.
> > 
> > 
> > Of course, this needs to be tested and verified, and there might be
> > 
> > certain
> > 
> > pieces missing to fully support the use case. But generally I like these
> > 
> > approaches much more.
> > 
> > 
> > 
> > 
> > https://spark.apache.org/docs/2.3.1/sql-programming-guide.html#creating-datasets
> > 
> > 
> > -Val
> > 
> > 
> > On Fri, Jul 27, 2018 at 6:31 AM Stuart Macdonald 
> > 
> > wrote:
> > 
> > 
> > Here’s the ticket:
> > 
> > 
> > https://issues.apache.org/jira/browse/IGNITE-9108
> > 
> > 
> > Stuart.
> > 
> > 
> > 
> > On Friday, 27 July 2018 at 14:19, Nikolay Izhikov wrote:
> > 
> > 
> > Sure.
> > 
> > 
> > Please, send ticket number in this thread.
> > 
> > 
> > пт, 27 июля 2018 г., 16:16 Stuart Macdonald  > 
> > (mailto:
> > 
> > stu...@stuwee.org)>:
> > 
> > 
> > Thanks Nikolay. For both options if the cache object isn’t a simple
> > 
> > type,
> > 
> > we’d probably do something like this in our Ignite SQL statement:
> > 
> > 
> > select cast(_key as binary), cast(_val as binary), ...
> > 
> > 
> > Which would give us the BinaryObject’s byte[], then for option 1 we
> > 
> > keep
> > 
> > the Ignite format and introduce a new Spark Encoder for Ignite binary
> > 
> > types
> > 
> > (
> > 
> > 
> > 
> > 
> > 
> > https://spark.apache.org/docs/2.1.0/api/java/org/apache/spark/sql/Encoder.html
> > 
> > ),
> > 
> > so that the end user interface would be something like:
> > 
> > 
> > IgniteSparkSession session = ...
> > 
> > Dataset dataFram

Re: iep-6 metrics ticket review

[Ilya Suntsov]

Dmitry G.,

I've run yardstick pds benchmarks against PR-3148 and master and can
confirm that fixes from PR don't affect performance.

2018-07-26 18:38 GMT+03:00 Dmitry Pavlov :

> Hi Ilya,
>
> We all agreed change is good, but we'd like to be absolutely sure there is
> no performance drop. Dmitriy G. was one from reviewer, so I hope he would
> provide any additional info about change.
>
> Could you please assist here?
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 26 июл. 2018 г. в 18:25, Aleksey Kuznetsov :
>
>> Hi, Igniters!
>>
>> I have the ticket [1] reviewed, it introduce large changes to cache.
>>
>> How can I assure it causes no performance drop ?
>>
>> [1] : https://issues.apache.org/jira/browse/IGNITE-6846
>>
>> ср, 11 апр. 2018 г. в 3:32, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>> > This is on my plate, will try to take a look this week.
>> >
>> > -Val
>> >
>> > On Mon, Apr 9, 2018 at 10:28 AM, Denis Magda  wrote:
>> >
>> > > Val,
>> > >
>> > > As an initial reviewer and reporter, could you have a look and sign
>> the
>> > > contribution off?
>> > >
>> > > --
>> > > Denis
>> > >
>> > > On Mon, Apr 9, 2018 at 12:56 AM, Aleksey Kuznetsov <
>> > > alkuznetsov...@gmail.com
>> > > > wrote:
>> > >
>> > > > Hi ,Igniters!
>> > > >
>> > > > Do we still need this ticket, about invoke metrics : [1] ?
>> > > >
>> > > > If yes, than could somebody review it ?
>> > > >
>> > > > If no, should we close this ticket ?
>> > > >
>> > > > [1] : https://issues.apache.org/jira/browse/IGNITE-6846
>> > > > --
>> > > >
>> > > > *Best Regards,*
>> > > >
>> > > > *Kuznetsov Aleksey*
>> > > >
>> > >
>> >
>>
>


-- 
Best Regards,
Ilya Suntsov
email: isunt...@gridgain.com
*GridGain Systems*
www.gridgain.com

Re: automatic node failure

[Alex Plehanov]

Dmitriy,

Failure handler not supposed to be triggered by user defined exception, but
in some cases user defined exception can cause critical system threads
termination and this event will trigger a failure handler (which can
shutdown the node).
There is still no reproducer or full stack trace on StackOverflow, so it's
hard to tell was node stopped by failure handler or by any other reason.


2018-07-31 2:59 GMT+03:00 Dmitriy Setrakyan :

> Igniters,
>
> I remember that we have added automatic node failure in case of unknown
> errors or events that may be fatal. Does this extend to the actual user
> exceptions?
>
> The reason I am asking is because of this thread on SO:
> https://stackoverflow.com/questions/51556794/ignite-
> server-node-crashes-on-
> throwing-user-defined-exceptions-from-the-cache-st
>
> Andrey Gura, as the expert on the automatic node failure feature, can you
> please comment?
>
> D.
>

[GitHub] ignite pull request #2955: IGNITE-6803 Avoid classloader widening for intern...

[alamar]

Github user alamar closed the pull request at:

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


---

[GitHub] ignite pull request #4459: IGNITE-9130: ZookeeperDiscoverySpiTest#checkInter...

[BiryukovVA]

GitHub user BiryukovVA opened a pull request:

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

IGNITE-9130: ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup fails 
if zk cluster was stpped before nodes.



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

$ git pull https://github.com/BiryukovVA/ignite IGNITE-9138

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

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


commit 263bcea8b83c56f883e046e40139362f419c8252
Author: Vitaliy Biryukov 
Date:   2018-07-31T08:45:17Z

IGNITE-9130: ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup fails 
if zk cluster was stpped before nodes.




---

[jira] [Created] (IGNITE-9139) Web console: item from dropdown cannot be selected

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-9139:
--

 Summary: Web console: item from dropdown cannot be selected
 Key: IGNITE-9139
 URL: https://issues.apache.org/jira/browse/IGNITE-9139
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Dmitriy Shabalin
 Attachments: image-2018-07-31-15-44-30-099.png

Query - Result - Chart - Chart Settings - Y axis settings 
 !image-2018-07-31-15-44-30-099.png! 



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

[jira] [Created] (IGNITE-9138) ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup fails if zk cluster was stpped before nodes.

[Vitaliy Biryukov (JIRA)]

Vitaliy Biryukov created IGNITE-9138:


 Summary: ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup 
fails if zk cluster was stpped before nodes.
 Key: IGNITE-9138
 URL: https://issues.apache.org/jira/browse/IGNITE-9138
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov
 Fix For: 2.7






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

Re: Relevance of IGNITE-6409

[Vladimir Ozerov]

Hi Amir,

Not very relevant at the moment.

On Sun, Jul 8, 2018 at 3:53 AM Amir Akhmedov 
wrote:

> Hi Igniters,
>
> I want to work on IGNITE-6409 (SQL: bypass H2 during index update) and want
> to ask about it's status. Is it still relevant ticket to work on?
>
> Vladimir Ozerov, as a reporter, can you please give your feedback please?
>
> Thanks,
> Amir
>

Re: [jira] [Assigned] (IGNITE-9113) Allocate memory for a data region when first cache assigned to this region is created

[Dmitriy Pavlov]

Hi Dmitriy,

I agree that person is right in that case, but Alex G. is not only one
person who can complete the issue.

I agree it is not newbie ticket, but this assigned ticket is locked by
assignee (see
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute )

My concern is related not to this ticket, but to our process: I've heard
complains from Igniters if someone assigns ticket to person, who are not
going to complete it.

I would appreciate if you find topic where Apache mentor explain it. I
could learn it and can tell other Igniters how it works.

Sincerely,
Dmitriy Pavlov

вт, 31 июл. 2018 г. в 1:33, Dmitriy Setrakyan :

> Dmitriy,
>
> I am still struggling to understand which portion of the code of conduct is
> being violated. BTW, this point was raised during the Ignite incubation
> process and the community agreed that it is up to the project community
> itself to decide on the best process here. This is not an Apache matter (I
> am too lazy to look for the thread now).
>
> I have been on this project long enough to have a good understanding who in
> the community has the best knowledge to fix a certain issue. When an issue
> requires strong domain expertise, I will assign a ticket to a certain
> domain expert to ensure that he or she are at least aware of it and try to
> address it. If they cannot, then they can always unassign it.
>
> I also use the table at the bottom of this page to find out domain experts
> on different sections of the project:
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> BTW, this ticket in particular is absolutely not a casual newbie ticket and
> can have dire consequences on the project quality if done wrong. Therefore,
> I have picked the best domain expert to implement it or at least to comment
> on it. I will assign it back to AG, unless we decide as a community that it
> is a wrong process.
>
> If you disagree with the process, please do not unassign any ticket
> yourself. Feel free to start a separate discussion and we can have a PMC or
> community decision on it.
>
> D.
>
> On Mon, Jul 30, 2018 at 3:22 AM, Dmitriy Pavlov 
> wrote:
>
> > Hi Dmitriy, Igniters,
> >
> > I would like to ask an assistance from experienced Ignite contributors
> > here. I'm still trying to find clear reference on that.
> >
> > In the same time I beleive that assignment to other person, who probably
> > will not work on issue, confronts at least with Code of conduct
> > http://www.apache.org/foundation/policies/conduct.html This policy is to
> > be
> > followed in spirit as much as in the letter.
> >
> > Assigning issue means no one else in the community can begin working on
> it.
> > Let's suppose contributor would like to complete issue, than he or she
> will
> > have to ask assignee to move issue to unassigned before he or she can
> > start. It is not welcoming and discourage people from contribution.
> >
> > So my proposal is as follows:
> > - to encourage particular contibutor to pay attention let's use
> >  -- direct mention in issue comments (it has almost the same effect:
> email
> > will be sent)
> > --  dev. list and CC to contributor's email
> >
> > - and keep ticket unassigned
> > -- until contributor starts
> > -- or going to start actual implementation.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 28 июл. 2018 г. в 15:50, Dmitriy Setrakyan :
> >
> > > On Sat, Jul 28, 2018 at 2:20 AM, Dmitriy Pavlov  >
> > > wrote:
> > >
> > > > Hi Dmitriy,
> > > >
> > > > As far as I know this approach is contlicting with the Apache Way. We
> > > > should be absolutely sure that assignee is agree and going to do this
> > > task.
> > > > But in our case domain expert did not replied to dev list topic.
> > > >
> > >
> > > I do not see any conflict with any Apache rule at all. By assigning a
> > > ticket to someone I am suggesting that as a domain expert it is
> > preferable
> > > that he or she looks at it. If not, these people can un-assign or
> > reassign
> > > the ticket.
> > >
> > > If you believe there is a conflict with some Apache principle, please
> > > provide a link so we could all learn about it.
> > >
> > > To solve lost ticket problem I suggest to use dev. list and bumping
> > up/ping
> > > > messages.
> > > >
> > >
> > > Agree, I do that too.
> > >
> > >
> > > > I hope it makes sense to you. If not, I will do my absolute best to
> > find
> > > > out corresponding ASF policy.
> > > >
> > >
> > > Please do.
> > >
> > >
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > сб, 28 июл. 2018 г. в 3:28, Dmitriy Setrakyan  >:
> > > >
> > > > > On Fri, Jul 27, 2018 at 3:02 PM, Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Igniters,
> > > > > >
> > > > > > I would discourage all Igniters from direct assigning issues to
> > > anyone
> > > > > > else. Of cource excepting the case it was directly discussed with
> > > > > asignee.
> > > > > > Any contributor should be able to assign issue

Re: Relevance of IGNITE-6409

[Dmitriy Pavlov]

Hi, Igniters,

I've misprinted in previous letter: "ticket is actual and worths to be
done".

Sorry for autocorrection done by cell phone.

Sincerely,
Dmitriy Pavlov

пн, 30 июл. 2018 г. в 14:21, Dmitriy Pavlov :

> Hi Vladimir,
>
> Could you please confirm if this ticket is actual AMD worth to be done.
>
> Sincerely,
> Dmitriy Pavlov
>
> вс, 8 июл. 2018 г., 3:53 Amir Akhmedov :
>
>> Hi Igniters,
>>
>> I want to work on IGNITE-6409 (SQL: bypass H2 during index update) and
>> want
>> to ask about it's status. Is it still relevant ticket to work on?
>>
>> Vladimir Ozerov, as a reporter, can you please give your feedback please?
>>
>> Thanks,
>> Amir
>>
>