Re: [VOTE] Apache Ignite 2.1.0 RC3

[Denis Magda]

Anton V,

Would you mind closing the vote if it passes? Unfortunately, I won't do
this, going offline for significant time.

Denis

On Friday, July 21, 2017, Semyon Boikov  wrote:

> +1 binding
>
> On Fri, Jul 21, 2017 at 1:09 PM, Yakov Zhdanov  > wrote:
>
> > +1 binding
> >
> > Checked maven build, imported and built examples project in IDEA and run
> > several compute exampled and started 2 nodes with default config.
> >
> > --Yakov
> >
> > 2017-07-21 12:21 GMT+03:00 Anton Vinogradov  >:
> >
> > > +1 (binding)
> > >
> > > On Fri, Jul 21, 2017 at 12:08 PM, Pavel Tupitsyn  >
> > > wrote:
> > >
> > > > +1
> > > >
> > > > Checked .NET: nodes start and join from exe file, bat file, NuGet,
> user
> > > > project.
> > > >
> > > > On Fri, Jul 21, 2017 at 11:49 AM, Vyacheslav Daradur <
> > > daradu...@gmail.com >
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Build success now. Node starts without issues.
> > > > >
> > > > > 2017-07-21 11:38 GMT+03:00 Kozlov Maxim  >:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > > 21 июля 2017 г., в 7:48, Valentin Kulichenko <
> > > > > > valentin.kuliche...@gmail.com > написал(а):
> > > > > > >
> > > > > > > +1 (binding)
> > > > > > >
> > > > > > > On Thu, Jul 20, 2017 at 9:35 PM, Sasha Belyak <
> > rtsfo...@gmail.com >
> > > > > > wrote:
> > > > > > >
> > > > > > >> +1
> > > > > > >>
> > > > > > >> 2017-07-21 5:34 GMT+07:00 Denis Magda  >:
> > > > > > >>
> > > > > > >>> Igniters,
> > > > > > >>>
> > > > > > >>> Setting off the vote one more time. Hope I’ll be successful
> > this
> > > > > time,
> > > > > > >>> keeping fingers crossed :)
> > > > > > >>>
> > > > > > >>> We have uploaded a 2.1.0 release candidate to
> > > > > > >>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> > > > > > >>>
> > > > > > >>> Git tag name is
> > > > > > >>> 2.1.0-rc3
> > > > > > >>>
> > > > > > >>> This release includes the following changes:
> > > > > > >>>
> > > > > > >>> Ignite:
> > > > > > >>> * Persistent cache store
> > > > > > >>> * Added IgniteFuture.listenAsync() and
> > IgniteFuture.chainAsync()
> > > > > > mehtods
> > > > > > >>> * Deprecated IgniteConfiguration.marshaller
> > > > > > >>> * Updated Lucene dependency to version 5.5.2
> > > > > > >>> * Machine learning: implemented K-means clusterization
> > algorithm
> > > > > > >> optimized
> > > > > > >>> for distributed storages
> > > > > > >>> * SQL: CREATE TABLE and DROP TABLE commands support
> > > > > > >>> * SQL: New thin JDBC driver
> > > > > > >>> * SQL: Improved performance of certain queries, when affinity
> > > node
> > > > > can
> > > > > > be
> > > > > > >>> calculated in advance
> > > > > > >>> * SQL: Fixed return type of AVG() function
> > > > > > >>> * SQL: BLOB type support added to thick JDBC driver
> > > > > > >>> * SQL: Improved LocalDate, LocalTime and LocalDateTime
> support
> > > for
> > > > > > Java 8
> > > > > > >>> * SQL: Added FieldsQueryCursor interface to get fields
> metadata
> > > for
> > > > > > >>> SqlFieldsQuery
> > > > > > >>> * ODBC: Implemented DML statement batching
> > > > > > >>> * Massive performance and stability improvements
> > > > > > >>>
> > > > > > >>> Ignite.NET:
> > > > > > >>> * Automatic remote assembly loading
> > > > > > >>> * NuGet-based standalone node deployment
> > > > > > >>> * Added conditional data removeal via LINQ DeleteAll
> > > > > > >>> * Added TimestampAttribute to control DateTime serialization
> > mode
> > > > > > >>> * Added local collections joins support to LINQ.
> > > > > > >>>
> > > > > > >>> Ignite CPP:
> > > > > > >>> * Added Compute::Call and Compute::Broadcast methods
> > > > > > >>>
> > > > > > >>> Web Console:
> > > > > > >>> * Implemented support for UNIQUE indexes for key fields on
> > import
> > > > > model
> > > > > > >>> from RDBMS
> > > > > > >>> * Added option to show full stack trace on Queries screen
> > > > > > >>> * Added PK alias generation on Models screen.
> > > > > > >>>
> > > > > > >>> Complete list of closed issues:
> > > > > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > > > > > 3D%20IGNITE%20AND%
> > > > > > >>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > > > > > >>> 20closed%20or%20status%20%3D%
> > > > > > >>> 20resolved)
> > > > > > >>>
> > > > > > >>> DEVNOTES
> > > > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > > > >>> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> > > > > > >>>
> > > > > > >>> RELEASE NOTES
> > > > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > > > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> > > > > > >>>
> > > > > > >>> Please start voting.
> > > > > > >>>
> > > > > > >>> +1 - to accept Apache Ignite 2.1.0-rc3
> > > > > > >>> 0 - don't care either way

[GitHub] ignite pull request #699: ignite-3098

[ascherbakoff]

Github user ascherbakoff closed the pull request at:

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


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

Re: Changing public IgniteCompute API to improve changes in 5037 ticket

[Valentin Kulichenko]

Maxim,

The issue is that it's currently assumed to support job mapping, but it
actually doesn't. However, I agree that AffinityKeyMapped annotation
doesn't fit the use case well. Let's fix documentation and JavaDoc then.

As for the proposed API, it's overcomplicated, took me 15 minutes to
understand what it does :)

What is the use case for which current affinityRun/Call API doesn't work?

-Val

On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim  wrote:

> Valentin,
>
> The author of tiket wants to see to provide some API allows to map
> ComputeJobs to partitions or keys. If we use @AffinityKeyMapped then you
> need to enter the cache name parameter, I think this is not convenient for
> the user. Therefore, I propose to extend the existing API.
> Having consulted with Anton V. decided to make a separate interface
> ReducibleTask, which will allow us to have different map logic at each
> inheritor.
>
> Old method, allows to map to node
> public interface ComputeTask extends ReducibleTask {
> @Nullable public Map
> map(List subgrid, @Nullable T arg) throws IgniteException;
> }
>
> Brand new method with mapping to partitions, which solves topology change
> issues.
> public interface AffinityComputeTask extends ReducibleTask {
> @Nullable public Map map(@NotnullString
> cacheName, List partIds, @Nullable T arg) throws IgniteException;
> }
>
> public interface ReducibleTask extends Serializable {
> public ComputeJobResultPolicy result(ComputeJobResult res,
> List rcvd) throws IgniteException;
>
> @Nullable public R reduce(List results) throws
> IgniteException;
> }
>
> We also need to implement AffinityComputeTaskAdapter and
> AffinityComputeTaskSplitAdapter, for implementation by default. It is
> right?
>
> In the IgniteCompute add:
>
> @IgniteAsyncSupported
> public  R affinityExecute(Class>
> taskCls, List partIds, @Nullable T arg) throws IgniteException;
> @IgniteAsyncSupported
> public  R affinityExecute(AffinityComputeTask task,
> List partIds, @Nullable T arg) throws IgniteException;
>
> public  ComputeTaskFuture affinityExecuteAsync(Class AffinityComputeTask> taskCls, List partIds, @Nullable T arg)
> throws IgniteException;
> public  ComputeTaskFuture affinityExecuteAsync(AffinityComputeTask R> task, List partIds, @Nullable T arg) throws IgniteException;
>
>
> How do you like this idea or do you insist that you need to use
> @AffinityKeyMapped to solve the problem?
>
>
> > 13 июля 2017 г., в 6:36, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> написал(а):
> >
> > Hi Max,
> >
> > This ticket doesn't assume any API changes, it's about broken
> > functionality. I would start with checking what tests we have
> > for @AffinityKeyMapped and creating missing one. From what I understand
> > functionality is broken completely or almost completely, so I guess
> testing
> > coverage is very weak there.
> >
> > -Val
> >
> > On Wed, Jul 12, 2017 at 4:27 PM, Kozlov Maxim 
> wrote:
> >
> >> Igniters,
> >>
> >> jira: https://issues.apache.org/jira/browse/IGNITE-5037 <
> >> https://issues.apache.org/jira/browse/IGNITE-5037>
> >> How do you look to solve this ticket by adding two methods to the public
> >> IgniteCompute API?
> >>
> >> @IgniteAsyncSupported
> >> public void affinityRun(@NotNull Collection cacheNames,
> >> Collection keys, IgniteRunnable job)
> >>throws IgniteException;
> >>
> >> @IgniteAsyncSupported
> >> public  R affinityCall(@NotNull Collection cacheNames,
> >> Collection keys, IgniteCallable job)
> >>throws IgniteException;
> >>
> >> There is also a question of how to act when changing the topology during
> >> the execution of the job.
> >> 1) complete with an exception;
> >> 2) stop execution and wait until the topology is rebuilt and continue
> >> execution;
> >>
> >> I think the second way, do you think?
> >>
> >> --
> >> Best Regards,
> >> Max K.
> >>
> >>
> >>
> >>
> >>
>
> --
> Best Regards,
> Max K.
>
>
>
>
>

Re: SSL certificate for the CI server

[Konstantin Boudnik]

I have never heard about this provider, and it is great they are donating
their resources to the FOSS. I quick glance on their site has reveiled a
couple of issues:
- the page for the "Standard Agreement" returns 404 [1]. I won't be willing to
  agree to something I cannot read upfront.
- the process seems to be manual.

The reason I like [2] is because it's backed by EFF and has a huge user base
(over 100 millions certificates to date) [3]

The process has been debugged already for other Apache projects, so I don't
really see why we need to go to someone else?

[1] 
https://www.globalsign.com/en/repository/globalsign-subscriber-agreement-digital-certificates-and-services.pdf
[2] https://letsencrypt.org/
[3] 
https://www.eff.org/deeplinks/2017/06/lets-encrypt-has-issued-100-million-certificates

Thanks,
  Cos

On Wed, Jul 19, 2017 at 09:41PM, Aleksey Chetaev wrote:
> Hi,
> 
> A know GlobalSing support open source projects for
> free(https://www.globalsign.com/en/ssl/ssl-open-source/).
> We can request certificates from them, it will be more easy for me. Any
> objection?
> 
> 
> Denis Magda-2 wrote
> > Hi Cos,
> > 
> > Alexey Chetaev, please join the conversation and share your thoughts on
> > this.
> > 
> > —
> > Denis
> > 
> >> On Jul 19, 2017, at 9:44 AM, Konstantin Boudnik 
> 
> > cos@
> 
> >  wrote:
> >> 
> >> Hey guys.
> >> 
> >> I've noticed that https://ci.ignite.apache.org/ has two issues:
> >> - it has the invalid certificate
> >> - the CI server isn't responding on the https port (there's only ngnix)
> >> 
> >> I don't about the rest of the group here, but all my browsers are
> >> enforcing
> >> HTTPS connections for the obvious reasons. I have to add an exception
> >> for the CI server to get in, which is a minor inconvenience compared to
> >> the
> >> security risks. I suggest we fix both issues. 
> >> 1. Getting a valid certificate is easy and doesn't cost a dime nowadays.
> >>   Here's the very details set of instructions on how we do it for Apache
> >>   Bigtop. They are easily applicable in Ignite CI's case [1]. I'd be
> >> happy to
> >>   help with this.
> >> 2. Reconfiguring the server to respond only on HTTPS port. That's another
> >> easy
> >>   thing to do for anyone with the access to the box. I don't have this,
> >> so
> >>   it'd be someone else.
> >> 
> >> Thoughts?
> >>  Cos
> >> 
> >> [1]
> >> https://cwiki.apache.org/confluence/display/BIGTOP/Bigtop+CI+Setup+Guide#BigtopCISetupGuide-Advancedpart:SetupaSSLsecuredJenkinsmaster
> >>
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/SSL-certificate-for-the-CI-server-tp19830p19840.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.


signature.asc
Description: Digital signature

Re: Timeouts in atomic cache

[Valentin Kulichenko]

Any thoughts?

-Val

On Wed, Jul 19, 2017 at 4:21 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Folks,
>
> Do we currently have any way to set a timeout for an atomic operation? I
> don't see neither a way to do this nor any related documentation.
>
> In the code there are CacheAtomicUpdateTimeoutException and
> CacheAtomicUpdateTimeoutCheckedException, but I can't find a single place
> where it's created and/or thrown. Looks like we used to have this
> functionality, but it's not there anymore. Is this really the case or I
> missed something?
>
> I think having a way to timeout atomic operation is very important. For
> example, two concurrent putAll operations with keys in different order can
> completely hang the whole cluster forever, which is unacceptable. Is it
> possible to timeout one of the operations (or both of them) in this case?
>
> -Val
>

Re: "not null" constraint support

[Vladimir Ozerov]

Guys,

QueryEntity is already too complex. We will deprecate it soon in favor of
brand new SQL API. No need to design FieldConstraint or something similar
at the moment, let's just stick to "Set notNullFields".

On Fri, Jul 21, 2017 at 7:08 PM, Sergey Chugunov 
wrote:

> Sergey,
>
> It may be a good idea to distinguish between field constraints (like "not
> null" one) which can be applied to only one field; and more complex
> constraints that involves more than one field.
>
> In case of field constraints it is better to simplify our model and allow
> only one field to appear inside constraint entity class.
>
> Something like this:
> class QueryEntity {
> ...
>
> /** All constraints to be enforced on this QueryEntity. */
> Set fieldConstraints;
> }
>
> /** Describes all constraints that affect the field. */
> class FieldConstraint {
> /** Field name to be examined against all its constraints. */
> String fieldName;
>
> /** Indicates whether check for null is required. */
> boolean notNull;
>
> ... here we would add more flags corresponding to other constraints ...
> }
>
> This model has a flaw that if we want to enforce the same constraint on
> many fields we must define FieldConstraint entity for each of these fields.
> But it has its advantages too: first of all, its simplicity and therefore
> obvious usage patterns; and easy to implement validation.
>
> Thanks,
> Sergey Ch.
>
>
> On Fri, Jul 21, 2017 at 6:43 PM, Pavel Tupitsyn 
> wrote:
>
> > Sergey, looks good to me!
> >
> > I thought of something a bit different, where there is a base class
> > and each constraint type inherits it, but your design is actually better.
> >
> > Pavel
> >
> > On Fri, Jul 21, 2017 at 6:38 PM, Sergey Kalashnikov <
> zkilling...@gmail.com
> > >
> > wrote:
> >
> > > Hi Pavel,
> > >
> > > Good point! What if we make it the following way?
> > >
> > > class QueryEntity {
> > > ...
> > >
> > > /** All constraints to be enforced on this QueryEntity. */
> > > Set constraint;
> > > }
> > >
> > > /** Describes constraints that affect one or more fields. */
> > > class QueryConstraint {
> > > /** Names of fields to be checked. */
> > > Set fields;
> > >
> > > /** Indicates whether check for null is required. */
> > > boolean notNull;
> > >
> > > ... here we would add more flags corresponding to other constraints
> > ...
> > > }
> > >
> > > --
> > > Best Regards,
> > > Sergey
> > >
> > >
> > > 2017-07-21 10:54 GMT+03:00 Pavel Tupitsyn :
> > > > Hi Sergey,
> > > >
> > > > This one looks not very good to me:
> > > >
> > > >> class QueryEntity {
> > > >> ...
> > > >> Set notNullFields;
> > > >> }
> > > >
> > > > What if there are more constraints in future? UNIQUE, CHECK, etc etc?
> > > >
> > > > Instead we could do something like
> > > >
> > > > Set constraints;
> > > >
> > > > Which is easily extendable in future.
> > > >
> > > > Thoughts?
> > > >
> > > > Pavel
> > > >
> > > > On Thu, Jul 20, 2017 at 11:17 PM, Denis Magda 
> > wrote:
> > > >
> > > >> Hi Sergey,
> > > >>
> > > >> That will be an excellent addition to DDL features set.
> > > >>
> > > >> The proposed changes look good to from the public API standpoint.
> > > >>
> > > >> Alexander P., Sergi, Vovan, please share your thoughts.
> > > >>
> > > >> —
> > > >> Denis
> > > >>
> > > >> > On Jul 20, 2017, at 12:27 PM, Sergey Kalashnikov <
> > > zkilling...@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > Hi Igniters,
> > > >> >
> > > >> > I am working on the ticket
> > > >> > https://issues.apache.org/jira/browse/IGNITE-5648, which purpose
> is
> > > to
> > > >> > add support for NOT NULL constraint for any fields of key or value
> > > >> > stored in Ignite cache.
> > > >> >
> > > >> > I would appreciate your comments on the design approach I have
> > > described
> > > >> below.
> > > >> >
> > > >> > In my opinion, such checks should be enforced both by SQL DML and
> > > >> > cache API to be consistent.
> > > >> >
> > > >> > Here is my analysis of what needs to be done.
> > > >> >
> > > >> > 1. First, the SQL CREATE table will not throw exception anymore
> > > >> > whenever it encounters a column with "not null" modifier.
> > > >> > Instead, the resulting QueryEntity will now indicate which fields
> > have
> > > >> > such modifier.
> > > >> >
> > > >> > The proposed way of doing this is the following:
> > > >> > class QueryEntity {
> > > >> >...
> > > >> >Set notNullFields;
> > > >> > }
> > > >> >
> > > >> > Since QueryEntity is a part of public api, it becomes possible to
> > > >> > configure this constraint not only via DDL CREATE TABLE.
> > > >> >
> > > >> > 2. Then we need a special method on GridQueryProcessor that for
> the
> > > >> > given cacheName, key and value would perform the following things:
> > > >> > - Get a GridQueryTypeDescriptor that corresponds to given value
> > type;
> > > >> > - Delegate 

Re: Ignite internal events tracing

[Valentin Kulichenko]

Alex,

That's a great idea. I would also add an option to dump information on
demand, for case when operation hanged and can't complete.

-Val

On Fri, Jul 21, 2017 at 6:15 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Igniters,
>
> I've recently stumbled across a situation when occasionally Ignite
> transactions commit may take up to several seconds while in general most of
> the transactions completed in a period of milliseconds.
>
> After a few attempts to analyze this situation with logs, I realized that
> this is a no-go and I need a finer instrument for this. The idea is to
> introduce several trace points along the way of an Ignite operation and
> collect timings when an operation passes each of the trace points. When
> enabled, this information should be available upon the operation
> completion.
>
> I've implemented a prototype of this for TX commit operation, the
> implementation is available in ignite-5797 branch.
>
> I was wondering if something of this kind may be useful as a part of Ignite
> product and available to users. If so, I would like to discuss the public
> API for this so the feature can be finalized.
>
> Thanks,
> AG
>

[GitHub] ignite pull request #2337: IGNITE-GG-12512 Introduced explicit ordering of c...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-GG-12512 Introduced explicit ordering of caches start & stop.



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

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

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

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


commit a7b39e3694c366bcbbf42bc41c8144e6faec5a39
Author: Pavel Kovalenko 
Date:   2017-07-21T16:08:14Z

IGNITE-GG-12512 Introduced explicit ordering of caches start & stop.




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

Re: "not null" constraint support

[Sergey Chugunov]

Sergey,

It may be a good idea to distinguish between field constraints (like "not
null" one) which can be applied to only one field; and more complex
constraints that involves more than one field.

In case of field constraints it is better to simplify our model and allow
only one field to appear inside constraint entity class.

Something like this:
class QueryEntity {
...

/** All constraints to be enforced on this QueryEntity. */
Set fieldConstraints;
}

/** Describes all constraints that affect the field. */
class FieldConstraint {
/** Field name to be examined against all its constraints. */
String fieldName;

/** Indicates whether check for null is required. */
boolean notNull;

... here we would add more flags corresponding to other constraints ...
}

This model has a flaw that if we want to enforce the same constraint on
many fields we must define FieldConstraint entity for each of these fields.
But it has its advantages too: first of all, its simplicity and therefore
obvious usage patterns; and easy to implement validation.

Thanks,
Sergey Ch.


On Fri, Jul 21, 2017 at 6:43 PM, Pavel Tupitsyn 
wrote:

> Sergey, looks good to me!
>
> I thought of something a bit different, where there is a base class
> and each constraint type inherits it, but your design is actually better.
>
> Pavel
>
> On Fri, Jul 21, 2017 at 6:38 PM, Sergey Kalashnikov  >
> wrote:
>
> > Hi Pavel,
> >
> > Good point! What if we make it the following way?
> >
> > class QueryEntity {
> > ...
> >
> > /** All constraints to be enforced on this QueryEntity. */
> > Set constraint;
> > }
> >
> > /** Describes constraints that affect one or more fields. */
> > class QueryConstraint {
> > /** Names of fields to be checked. */
> > Set fields;
> >
> > /** Indicates whether check for null is required. */
> > boolean notNull;
> >
> > ... here we would add more flags corresponding to other constraints
> ...
> > }
> >
> > --
> > Best Regards,
> > Sergey
> >
> >
> > 2017-07-21 10:54 GMT+03:00 Pavel Tupitsyn :
> > > Hi Sergey,
> > >
> > > This one looks not very good to me:
> > >
> > >> class QueryEntity {
> > >> ...
> > >> Set notNullFields;
> > >> }
> > >
> > > What if there are more constraints in future? UNIQUE, CHECK, etc etc?
> > >
> > > Instead we could do something like
> > >
> > > Set constraints;
> > >
> > > Which is easily extendable in future.
> > >
> > > Thoughts?
> > >
> > > Pavel
> > >
> > > On Thu, Jul 20, 2017 at 11:17 PM, Denis Magda 
> wrote:
> > >
> > >> Hi Sergey,
> > >>
> > >> That will be an excellent addition to DDL features set.
> > >>
> > >> The proposed changes look good to from the public API standpoint.
> > >>
> > >> Alexander P., Sergi, Vovan, please share your thoughts.
> > >>
> > >> —
> > >> Denis
> > >>
> > >> > On Jul 20, 2017, at 12:27 PM, Sergey Kalashnikov <
> > zkilling...@gmail.com>
> > >> wrote:
> > >> >
> > >> > Hi Igniters,
> > >> >
> > >> > I am working on the ticket
> > >> > https://issues.apache.org/jira/browse/IGNITE-5648, which purpose is
> > to
> > >> > add support for NOT NULL constraint for any fields of key or value
> > >> > stored in Ignite cache.
> > >> >
> > >> > I would appreciate your comments on the design approach I have
> > described
> > >> below.
> > >> >
> > >> > In my opinion, such checks should be enforced both by SQL DML and
> > >> > cache API to be consistent.
> > >> >
> > >> > Here is my analysis of what needs to be done.
> > >> >
> > >> > 1. First, the SQL CREATE table will not throw exception anymore
> > >> > whenever it encounters a column with "not null" modifier.
> > >> > Instead, the resulting QueryEntity will now indicate which fields
> have
> > >> > such modifier.
> > >> >
> > >> > The proposed way of doing this is the following:
> > >> > class QueryEntity {
> > >> >...
> > >> >Set notNullFields;
> > >> > }
> > >> >
> > >> > Since QueryEntity is a part of public api, it becomes possible to
> > >> > configure this constraint not only via DDL CREATE TABLE.
> > >> >
> > >> > 2. Then we need a special method on GridQueryProcessor that for the
> > >> > given cacheName, key and value would perform the following things:
> > >> > - Get a GridQueryTypeDescriptor that corresponds to given value
> type;
> > >> > - Delegate that GridQueryTypeDescriptor a task to validate given key
> > and
> > >> value;
> > >> > - Type descriptor would itself delegate the validation to its
> > >> > GridQueryProperties that have "not null" constraint.
> > >> >
> > >> > 3. To enforce the constraints, the validation method should be
> called
> > >> > - In GridNearAtomicSingleUpdateFuture.mapSingleUpdate() and
> > >> > GridNearAtomicUpdateFuture.mapUpdate() when operation is CREATE or
> > >> > UPDATE.
> > >> > That would cover putIfAbsent(), getAndPut(), getAndPutIfAbsent(),
> > >> > replace(), getAndReplace(), putAll() operations on 

[GitHub] ignite pull request #2336: IGNITE-5770 Refactor PlatformProcessor to Platfor...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5770 Refactor PlatformProcessor to PlatformTarget mechanism



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

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

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

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


commit bb823171b1b96c86c59f25c9d03d197cebb2d5e3
Author: Pavel Tupitsyn 
Date:   2017-07-18T07:24:24Z

IGNITE-5770 Refactor PlatformProcessor to PlatformTarget mechanism

commit 32a4324fcd85beedb181da6c82d07d1cb694c882
Author: Pavel Tupitsyn 
Date:   2017-07-18T07:27:17Z

interface cleanup

commit 182501c55c139a4f511246357dd57db585b20608
Author: Pavel Tupitsyn 
Date:   2017-07-18T07:35:44Z

wip

commit b61cc51d4c2440cbe051d12e2e28a6f493d8c18d
Author: Pavel Tupitsyn 
Date:   2017-07-18T07:44:17Z

wip

commit 8d49160d384074d0b15d739194edf847956d60fe
Author: Pavel Tupitsyn 
Date:   2017-07-18T08:25:27Z

wip

commit b32f8e7d769c48902ee7909da8dc4768d5f95c3f
Author: Pavel Tupitsyn 
Date:   2017-07-18T08:28:04Z

wip

commit 45585d1e0860770c0116ba0595ce9eb3c4b10ef9
Author: Pavel Tupitsyn 
Date:   2017-07-18T08:31:09Z

wip

commit a9d7741854a8bdcb9a9bf42a7d4f60daaff44b04
Author: Pavel Tupitsyn 
Date:   2017-07-18T08:45:27Z

wip

commit 4b0bea27ca86193f154944ecf3bb03c304aa32f5
Author: Pavel Tupitsyn 
Date:   2017-07-18T08:47:55Z

wip

commit 938b0f210fa93c35c4f26bc9e17643ca2be3a979
Author: Pavel Tupitsyn 
Date:   2017-07-18T08:51:34Z

wip

commit 7d36cf51b0bc559659cb170025f9e57a35128057
Author: Pavel Tupitsyn 
Date:   2017-07-18T08:58:12Z

wip

commit 0246e1f18aac726e65f114953daae5814020f3a0
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:03:47Z

wip

commit 3be0c1bcee614552413608d13c04bb92178e0632
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:10:46Z

wip

commit 9153e788fe98c680645bf0ebd3c118a0260d3ab2
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:11:37Z

wip

commit a17e973efade36e16901e6cc153fa929c07bbf11
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:12:42Z

PlatformProcessorImpl refactored

commit bfaf39f1bb1f413feb0c209a8aa3e0e03a192b85
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:18:54Z

Fix NoopProcessor

commit 9f8e99962576a88ba05a76a4c26ebb484feaee80
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:21:23Z

Refactoring processor in .NET

commit d725cf5d1725bc5be411e69c921b202e2f7a90f7
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:22:55Z

wip

commit 9692d69d2613542739ccc0b92a72a1e440206bee
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:25:27Z

wip

commit 8a9be00a5ac3018de85817f9c1cddbd3d564
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:36:15Z

wip

commit 0ba521b591fd963191204d193f1d8074834be100
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:36:41Z

wip

commit 00b3e04ec4a17fc45002471abd431858f5cc472f
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:42:11Z

CPP cleanup

commit 1722e83c196f136b2d4d67b61538de30c6ac329b
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:44:39Z

CPP cleanup - fixed compilation

commit 2675dfdc7088cb3432e1713c5c195b7a653a
Author: Pavel Tupitsyn 
Date:   2017-07-18T09:49:00Z

wip

commit c1964377a16da5c6256b665bff1d83530e74
Author: Pavel Tupitsyn 
Date:   2017-07-18T11:08:42Z

wip

commit 4a8b6fb8a0a7504baa37bff3fa43a5c20e0fbdf9
Author: Pavel Tupitsyn 
Date:   2017-07-18T11:10:35Z

wip releaseStart

commit f7be712622a203dbd7c4ad9a4275dce67f2c3a12
Author: Pavel Tupitsyn 
Date:   2017-07-18T11:14:01Z

Fix ReleaseStart

commit c1c974ae98572256808a01e5381a9ba5bdabafec
Author: Pavel Tupitsyn 
Date:   2017-07-18T11:18:40Z

wip

commit 66eccf22e358e48c39b7a0802b5bf146e08b4340
Author: Pavel Tupitsyn 
Date:   2017-07-18T11:26:47Z

Fix logging

commit c06bcbb60338a62b47fd13ab03b4363c8247f78c
Author: Pavel Tupitsyn 
Date:   2017-07-18T11:27:44Z

Fix logger




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the 

Re: "not null" constraint support

[Pavel Tupitsyn]

Sergey, looks good to me!

I thought of something a bit different, where there is a base class
and each constraint type inherits it, but your design is actually better.

Pavel

On Fri, Jul 21, 2017 at 6:38 PM, Sergey Kalashnikov 
wrote:

> Hi Pavel,
>
> Good point! What if we make it the following way?
>
> class QueryEntity {
> ...
>
> /** All constraints to be enforced on this QueryEntity. */
> Set constraint;
> }
>
> /** Describes constraints that affect one or more fields. */
> class QueryConstraint {
> /** Names of fields to be checked. */
> Set fields;
>
> /** Indicates whether check for null is required. */
> boolean notNull;
>
> ... here we would add more flags corresponding to other constraints ...
> }
>
> --
> Best Regards,
> Sergey
>
>
> 2017-07-21 10:54 GMT+03:00 Pavel Tupitsyn :
> > Hi Sergey,
> >
> > This one looks not very good to me:
> >
> >> class QueryEntity {
> >> ...
> >> Set notNullFields;
> >> }
> >
> > What if there are more constraints in future? UNIQUE, CHECK, etc etc?
> >
> > Instead we could do something like
> >
> > Set constraints;
> >
> > Which is easily extendable in future.
> >
> > Thoughts?
> >
> > Pavel
> >
> > On Thu, Jul 20, 2017 at 11:17 PM, Denis Magda  wrote:
> >
> >> Hi Sergey,
> >>
> >> That will be an excellent addition to DDL features set.
> >>
> >> The proposed changes look good to from the public API standpoint.
> >>
> >> Alexander P., Sergi, Vovan, please share your thoughts.
> >>
> >> —
> >> Denis
> >>
> >> > On Jul 20, 2017, at 12:27 PM, Sergey Kalashnikov <
> zkilling...@gmail.com>
> >> wrote:
> >> >
> >> > Hi Igniters,
> >> >
> >> > I am working on the ticket
> >> > https://issues.apache.org/jira/browse/IGNITE-5648, which purpose is
> to
> >> > add support for NOT NULL constraint for any fields of key or value
> >> > stored in Ignite cache.
> >> >
> >> > I would appreciate your comments on the design approach I have
> described
> >> below.
> >> >
> >> > In my opinion, such checks should be enforced both by SQL DML and
> >> > cache API to be consistent.
> >> >
> >> > Here is my analysis of what needs to be done.
> >> >
> >> > 1. First, the SQL CREATE table will not throw exception anymore
> >> > whenever it encounters a column with "not null" modifier.
> >> > Instead, the resulting QueryEntity will now indicate which fields have
> >> > such modifier.
> >> >
> >> > The proposed way of doing this is the following:
> >> > class QueryEntity {
> >> >...
> >> >Set notNullFields;
> >> > }
> >> >
> >> > Since QueryEntity is a part of public api, it becomes possible to
> >> > configure this constraint not only via DDL CREATE TABLE.
> >> >
> >> > 2. Then we need a special method on GridQueryProcessor that for the
> >> > given cacheName, key and value would perform the following things:
> >> > - Get a GridQueryTypeDescriptor that corresponds to given value type;
> >> > - Delegate that GridQueryTypeDescriptor a task to validate given key
> and
> >> value;
> >> > - Type descriptor would itself delegate the validation to its
> >> > GridQueryProperties that have "not null" constraint.
> >> >
> >> > 3. To enforce the constraints, the validation method should be called
> >> > - In GridNearAtomicSingleUpdateFuture.mapSingleUpdate() and
> >> > GridNearAtomicUpdateFuture.mapUpdate() when operation is CREATE or
> >> > UPDATE.
> >> > That would cover putIfAbsent(), getAndPut(), getAndPutIfAbsent(),
> >> > replace(), getAndReplace(), putAll() operations on atomic cache.
> >> > And in GridNearTxLocal.enlistWriteEntry() when operation is CREATE or
> >> > UPDATE for the case of transactional cache.
> >> >
> >> > - Right after EntryProcessor.process() in
> >> > GridCacheMapEntry.AtomicCacheUpdateClosure.runEntryProcessor() as
> part
> >> > of invoke(), invokeAll() operations on atomic cache.
> >> > And in GridDhtTxPrepareFuture.onEntriesLocked() for the case of
> >> > transactional cache.
> >> >
> >> > 4. DML processor changes
> >> >  The DMLStatementProcessor methods doInsert(), doUpdate(), doMerge()
> >> > must also incorporate such checks to avoid attempts
> >> >  to insert values that are known to be rejected by cache.
> >> >
> >> > Thoughts?
> >> >
> >> > --
> >> > Best regards,
> >> > Sergey
> >>
> >>
>

Re: "not null" constraint support

[Sergey Kalashnikov]

Hi Pavel,

Good point! What if we make it the following way?

class QueryEntity {
...

/** All constraints to be enforced on this QueryEntity. */
Set constraint;
}

/** Describes constraints that affect one or more fields. */
class QueryConstraint {
/** Names of fields to be checked. */
Set fields;

/** Indicates whether check for null is required. */
boolean notNull;

... here we would add more flags corresponding to other constraints ...
}

--
Best Regards,
Sergey


2017-07-21 10:54 GMT+03:00 Pavel Tupitsyn :
> Hi Sergey,
>
> This one looks not very good to me:
>
>> class QueryEntity {
>> ...
>> Set notNullFields;
>> }
>
> What if there are more constraints in future? UNIQUE, CHECK, etc etc?
>
> Instead we could do something like
>
> Set constraints;
>
> Which is easily extendable in future.
>
> Thoughts?
>
> Pavel
>
> On Thu, Jul 20, 2017 at 11:17 PM, Denis Magda  wrote:
>
>> Hi Sergey,
>>
>> That will be an excellent addition to DDL features set.
>>
>> The proposed changes look good to from the public API standpoint.
>>
>> Alexander P., Sergi, Vovan, please share your thoughts.
>>
>> —
>> Denis
>>
>> > On Jul 20, 2017, at 12:27 PM, Sergey Kalashnikov 
>> wrote:
>> >
>> > Hi Igniters,
>> >
>> > I am working on the ticket
>> > https://issues.apache.org/jira/browse/IGNITE-5648, which purpose is to
>> > add support for NOT NULL constraint for any fields of key or value
>> > stored in Ignite cache.
>> >
>> > I would appreciate your comments on the design approach I have described
>> below.
>> >
>> > In my opinion, such checks should be enforced both by SQL DML and
>> > cache API to be consistent.
>> >
>> > Here is my analysis of what needs to be done.
>> >
>> > 1. First, the SQL CREATE table will not throw exception anymore
>> > whenever it encounters a column with "not null" modifier.
>> > Instead, the resulting QueryEntity will now indicate which fields have
>> > such modifier.
>> >
>> > The proposed way of doing this is the following:
>> > class QueryEntity {
>> >...
>> >Set notNullFields;
>> > }
>> >
>> > Since QueryEntity is a part of public api, it becomes possible to
>> > configure this constraint not only via DDL CREATE TABLE.
>> >
>> > 2. Then we need a special method on GridQueryProcessor that for the
>> > given cacheName, key and value would perform the following things:
>> > - Get a GridQueryTypeDescriptor that corresponds to given value type;
>> > - Delegate that GridQueryTypeDescriptor a task to validate given key and
>> value;
>> > - Type descriptor would itself delegate the validation to its
>> > GridQueryProperties that have "not null" constraint.
>> >
>> > 3. To enforce the constraints, the validation method should be called
>> > - In GridNearAtomicSingleUpdateFuture.mapSingleUpdate() and
>> > GridNearAtomicUpdateFuture.mapUpdate() when operation is CREATE or
>> > UPDATE.
>> > That would cover putIfAbsent(), getAndPut(), getAndPutIfAbsent(),
>> > replace(), getAndReplace(), putAll() operations on atomic cache.
>> > And in GridNearTxLocal.enlistWriteEntry() when operation is CREATE or
>> > UPDATE for the case of transactional cache.
>> >
>> > - Right after EntryProcessor.process() in
>> > GridCacheMapEntry.AtomicCacheUpdateClosure.runEntryProcessor() as part
>> > of invoke(), invokeAll() operations on atomic cache.
>> > And in GridDhtTxPrepareFuture.onEntriesLocked() for the case of
>> > transactional cache.
>> >
>> > 4. DML processor changes
>> >  The DMLStatementProcessor methods doInsert(), doUpdate(), doMerge()
>> > must also incorporate such checks to avoid attempts
>> >  to insert values that are known to be rejected by cache.
>> >
>> > Thoughts?
>> >
>> > --
>> > Best regards,
>> > Sergey
>>
>>

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Semyon Boikov]

+1 binding

On Fri, Jul 21, 2017 at 1:09 PM, Yakov Zhdanov  wrote:

> +1 binding
>
> Checked maven build, imported and built examples project in IDEA and run
> several compute exampled and started 2 nodes with default config.
>
> --Yakov
>
> 2017-07-21 12:21 GMT+03:00 Anton Vinogradov :
>
> > +1 (binding)
> >
> > On Fri, Jul 21, 2017 at 12:08 PM, Pavel Tupitsyn 
> > wrote:
> >
> > > +1
> > >
> > > Checked .NET: nodes start and join from exe file, bat file, NuGet, user
> > > project.
> > >
> > > On Fri, Jul 21, 2017 at 11:49 AM, Vyacheslav Daradur <
> > daradu...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > Build success now. Node starts without issues.
> > > >
> > > > 2017-07-21 11:38 GMT+03:00 Kozlov Maxim :
> > > >
> > > > > +1
> > > > >
> > > > > > 21 июля 2017 г., в 7:48, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> написал(а):
> > > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > On Thu, Jul 20, 2017 at 9:35 PM, Sasha Belyak <
> rtsfo...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > >> +1
> > > > > >>
> > > > > >> 2017-07-21 5:34 GMT+07:00 Denis Magda :
> > > > > >>
> > > > > >>> Igniters,
> > > > > >>>
> > > > > >>> Setting off the vote one more time. Hope I’ll be successful
> this
> > > > time,
> > > > > >>> keeping fingers crossed :)
> > > > > >>>
> > > > > >>> We have uploaded a 2.1.0 release candidate to
> > > > > >>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> > > > > >>>
> > > > > >>> Git tag name is
> > > > > >>> 2.1.0-rc3
> > > > > >>>
> > > > > >>> This release includes the following changes:
> > > > > >>>
> > > > > >>> Ignite:
> > > > > >>> * Persistent cache store
> > > > > >>> * Added IgniteFuture.listenAsync() and
> IgniteFuture.chainAsync()
> > > > > mehtods
> > > > > >>> * Deprecated IgniteConfiguration.marshaller
> > > > > >>> * Updated Lucene dependency to version 5.5.2
> > > > > >>> * Machine learning: implemented K-means clusterization
> algorithm
> > > > > >> optimized
> > > > > >>> for distributed storages
> > > > > >>> * SQL: CREATE TABLE and DROP TABLE commands support
> > > > > >>> * SQL: New thin JDBC driver
> > > > > >>> * SQL: Improved performance of certain queries, when affinity
> > node
> > > > can
> > > > > be
> > > > > >>> calculated in advance
> > > > > >>> * SQL: Fixed return type of AVG() function
> > > > > >>> * SQL: BLOB type support added to thick JDBC driver
> > > > > >>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support
> > for
> > > > > Java 8
> > > > > >>> * SQL: Added FieldsQueryCursor interface to get fields metadata
> > for
> > > > > >>> SqlFieldsQuery
> > > > > >>> * ODBC: Implemented DML statement batching
> > > > > >>> * Massive performance and stability improvements
> > > > > >>>
> > > > > >>> Ignite.NET:
> > > > > >>> * Automatic remote assembly loading
> > > > > >>> * NuGet-based standalone node deployment
> > > > > >>> * Added conditional data removeal via LINQ DeleteAll
> > > > > >>> * Added TimestampAttribute to control DateTime serialization
> mode
> > > > > >>> * Added local collections joins support to LINQ.
> > > > > >>>
> > > > > >>> Ignite CPP:
> > > > > >>> * Added Compute::Call and Compute::Broadcast methods
> > > > > >>>
> > > > > >>> Web Console:
> > > > > >>> * Implemented support for UNIQUE indexes for key fields on
> import
> > > > model
> > > > > >>> from RDBMS
> > > > > >>> * Added option to show full stack trace on Queries screen
> > > > > >>> * Added PK alias generation on Models screen.
> > > > > >>>
> > > > > >>> Complete list of closed issues:
> > > > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > > > > 3D%20IGNITE%20AND%
> > > > > >>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > > > > >>> 20closed%20or%20status%20%3D%
> > > > > >>> 20resolved)
> > > > > >>>
> > > > > >>> DEVNOTES
> > > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > > >>> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> > > > > >>>
> > > > > >>> RELEASE NOTES
> > > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> > > > > >>>
> > > > > >>> Please start voting.
> > > > > >>>
> > > > > >>> +1 - to accept Apache Ignite 2.1.0-rc3
> > > > > >>> 0 - don't care either way
> > > > > >>> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
> > > > > >>>
> > > > > >>> This vote will go for 72 hours.
> > > > > >>>
> > > > > >>> —
> > > > > >>> Denis
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > > --
> > > > > Best Regards,
> > > > > Max K.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> >
>

[GitHub] ignite pull request #2335: IGNITE-5806: removed assertion failing Ignite Cac...

[dspavlov]

GitHub user dspavlov opened a pull request:

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

IGNITE-5806: removed assertion failing Ignite Cache 5 suite



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

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

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

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


commit 085adf75de2747987d562ce37fabdf462756fec5
Author: dspavlov 
Date:   2017-07-21T14:51:50Z

IGNITE-5806: removed assertion failing Ignite Cache 5 suite




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

[GitHub] ignite pull request #2334: IGNITE-5712: implementation of context switching ...

[nizhikov]

GitHub user nizhikov opened a pull request:

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

IGNITE-5712: implementation of context switching for transactions.



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

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

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

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


commit 5f44aae9e61bca0a8445f6257b7275ac95988e1d
Author: Nikolay Izhikov 
Date:   2017-07-21T14:03:14Z

IGNITE-5712: implementation of context switching for transactions.




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

[GitHub] ignite pull request #2297: IGNITE-5752 Fixed GridDhtPartitionMap updateSeque...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] ignite pull request #2313: IGNITE-5772

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] ignite pull request #2331: IGNITE-5786 .NET: Fix cache store session handlin...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Created] (IGNITE-5806) IgniteCache5 suite timed out, assertions in sessions close logic

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-5806:
--

 Summary: IgniteCache5 suite timed out, assertions in sessions 
close logic
 Key: IGNITE-5806
 URL: https://issues.apache.org/jira/browse/IGNITE-5806
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Pavlov
Priority: Blocker


Ignite Cache 5 timeouts observed in master

http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgniteCache5_Ignite20Tests=%3Cdefault%3E=buildTypeStatusDiv
Reproduced for builds 725, 740 and 748 
Log contains assertion coming from 
{code}
!sesHolder.get().ended(store); 
{code}
at
{noformat} [2017-07-21 
07:59:44,774][ERROR][sys-stripe-3-#117%cache.CacheSerializableTransactionsTest2%][G]
 Failed to execute runnable.
 
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.sessionEnd0(GridCacheStoreManagerAdapter.java:878)
at 
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:335)
at 
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:282)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.readThrough(GridCacheMapEntry.java:445)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:699)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:461)
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2333: ignite-4181

[x-kreator]

GitHub user x-kreator opened a pull request:

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

ignite-4181



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

$ git pull https://github.com/x-kreator/ignite ignite-4181

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

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


commit 476d4f29fa148ce9192d772ce0092169e74ddc5b
Author: Dmitry Sorokin 
Date:   2017-07-20T11:51:56Z

IGNITE-4181 challenge: + simple test

commit 2fe2377c2b3d1ef62f1287c24f60ddd144b63d11
Author: Dmitry Sorokin 
Date:   2017-07-21T12:51:04Z

IGNITE-4181 Reproducing test after-review corrections.




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

[GitHub] ignite pull request #2332: Ignite 1094

[voipp]

GitHub user voipp opened a pull request:

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

Ignite 1094



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

$ git pull https://github.com/voipp/ignite ignite-1094

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

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


commit d2b47591319967264d8e0b7364494cc8208c016a
Author: Pavel Tupitsyn 
Date:   2017-06-26T14:40:41Z

IGNITE-5588 .NET: Inject resources in ScanQuery

commit caa4f25e989528249f4755cd59c9758dc1c31641
Author: Dmitriy Shabalin 
Date:   2017-06-27T08:32:13Z

IGNITE-4467 fixed table header scrolling with content

commit a9db2ad01c0ec04a5edc42890acd535653bd6f88
Author: sboikov 
Date:   2017-06-27T09:27:34Z

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

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite2.java

commit fd09d301b14a2e20774503359bcef4280a67da92
Author: sboikov 
Date:   2017-06-27T09:27:45Z

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

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite2.java

commit f2a5a93f0748f905ede77ff84787947a0893c3f8
Author: sboikov 
Date:   2017-06-27T10:43:13Z

Quick fix for NPE in PageMemoryImpl.loadedPages

commit acf0441b043a04cd01200d955e64d73e40436cd0
Author: sboikov 
Date:   2017-06-27T11:10:41Z

Added test for concurrent activation and node join.

commit 07bf0f6f3ab5333ba42808c6b39000cf13b77f5c
Author: Igor Seliverstov 
Date:   2017-06-21T12:05:05Z

IGNITE-5548 Deadlock Detection uses IgniteCheckedException instead of 
TransactionTimeoutException

commit 1d88bec2da02b6343ee867e4fbc25b00e67c1fd6
Author: Dmitriy Govorukhin 
Date:   2017-06-27T13:13:30Z

ignite-gg-12052 code comments

commit 4adfca9dcbbb8709744dce5a986e193ba4015eb1
Author: Sergey Chugunov 
Date:   2017-06-27T14:04:16Z

GG-12347 restoring binary metadata at correct moment of 
ObjectBinaryProcessor startup process

commit eec0fcf313c6631b44098e203365e7f5cfd34d54
Author: Alexander Paschenko 
Date:   2017-06-27T14:53:55Z

IGNITE-5279 Name case sensitivity tests for CREATE INDEX and CREATE TABLE.

commit ff151e5fd1b0d9782b53e88b46fb7aab9dd019a7
Author: Alexander Paschenko 
Date:   2017-06-27T15:07:00Z

IGNITE-5449 DML+DDL complex test.

commit 1cb9772833261a14afc8aae3e6005df7fb28b83f
Author: vsisko 
Date:   2017-06-28T03:44:33Z

IGNITE-5577 Added missed fields to DTO.

commit 3cd30f0640fb9b77d4db739a8291055c2207aa4f
Author: anovikov 
Date:   2017-06-28T04:47:25Z

IGNITE-5461 Support for Memory metrics and fixed cache metrics.

commit cff23a99b655bc353e93fee5b2d87c5f76ff8d7b
Author: vsisko 
Date:   2017-06-28T05:04:58Z

IGNITE-5599 Added check that node URL is valid. Added warning about 
ignite-rest-http.

commit 8445b315663710507e6e3996223f01748f9674a6
Author: sboikov 
Date:   2017-06-28T05:58:09Z

ignite-5595 Client event exchange optimization

commit f0f59631ec05a281af671f6cc246ca3ef443e083
Author: sboikov 
Date:   2017-06-28T06:06:23Z

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

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtPartitionTopologyImpl.java

commit 764eeeaa387f1800d0501cc1e7060c1125b3ad72
Author: sboikov 
Date:   2017-06-28T06:07:17Z

Merge remote-tracking branch 'community/ignite-2.1.2' into ignite-2.1.2

commit 3dbeac440591c8404bdbea78fc46cdff7c2f432e
Author: vsisko 
Date:   2017-06-28T08:07:30Z

IGNITE-5536 Fixed Docker file generation.

commit d6972e95367d93c1015b6bab8dd4dc78ae2fc1e6
Author: sboikov 
Date:   2017-06-28T08:30:47Z

ignite-2.1.2 Limit amount of debug logging

commit 1ced55b6fabfd009e98a2d2010bf6e9a01a30fb9
Author: sboikov 
Date:   2017-06-28T08:31:18Z

Merge remote-tracking branch 'community/ignite-2.1.2' into ignite-2.1.2

commit f618640e6972ed28153e72ce0eb0747d87b83018
Author: sboikov 
Date:   

[GitHub] ignite pull request #2325: ignite-4181

[x-kreator]

Github user x-kreator closed the pull request at:

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


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

Re: Cache start ordering during cluster activation

[Alexey Goncharuk]

Agree,

Since we rely on cache start order during the node start, the same order
should be preserved during activation.

2017-07-21 15:24 GMT+03:00 Jokser :

> Hello Igniters,
>
> Currently order of cache starts/stops operations is not determined during
> cluster activation.
> Some of the cache components can be depended on system or utility caches.
> If
> such component starts earlier than system cache on what it's depended, it
> can lead to unpredictable errors (e.g. NullPointerException)
> I would like to introduce strict order of cache start/stop operations as it
> is already implemented during normal node join process.
> If we form cache start requests they should be ordered (first we should
> start system caches then user), for cache stop requests order should be
> reverse (first user caches then system).
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Cache-start-ordering-
> during-cluster-activation-tp19910.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

Ignite internal events tracing

[Alexey Goncharuk]

Igniters,

I've recently stumbled across a situation when occasionally Ignite
transactions commit may take up to several seconds while in general most of
the transactions completed in a period of milliseconds.

After a few attempts to analyze this situation with logs, I realized that
this is a no-go and I need a finer instrument for this. The idea is to
introduce several trace points along the way of an Ignite operation and
collect timings when an operation passes each of the trace points. When
enabled, this information should be available upon the operation completion.

I've implemented a prototype of this for TX commit operation, the
implementation is available in ignite-5797 branch.

I was wondering if something of this kind may be useful as a part of Ignite
product and available to users. If so, I would like to discuss the public
API for this so the feature can be finalized.

Thanks,
AG

Re: Changing public IgniteCompute API to improve changes in 5037 ticket

[Kozlov Maxim]

Valentin,

The author of tiket wants to see to provide some API allows to map ComputeJobs 
to partitions or keys. If we use @AffinityKeyMapped then you need to enter the 
cache name parameter, I think this is not convenient for the user. Therefore, I 
propose to extend the existing API.
Having consulted with Anton V. decided to make a separate interface 
ReducibleTask, which will allow us to have different map logic at each 
inheritor.

Old method, allows to map to node
public interface ComputeTask extends ReducibleTask {
@Nullable public Map 
map(List subgrid, @Nullable T arg) throws IgniteException;
}

Brand new method with mapping to partitions, which solves topology change 
issues.
public interface AffinityComputeTask extends ReducibleTask {
@Nullable public Map map(@NotnullString 
cacheName, List partIds, @Nullable T arg) throws IgniteException;
}

public interface ReducibleTask extends Serializable {
public ComputeJobResultPolicy result(ComputeJobResult res, 
List rcvd) throws IgniteException;

@Nullable public R reduce(List results) throws 
IgniteException;
}

We also need to implement AffinityComputeTaskAdapter and 
AffinityComputeTaskSplitAdapter, for implementation by default. It is right?

In the IgniteCompute add:

@IgniteAsyncSupported
public  R affinityExecute(Class> 
taskCls, List partIds, @Nullable T arg) throws IgniteException;
@IgniteAsyncSupported
public  R affinityExecute(AffinityComputeTask task, List 
partIds, @Nullable T arg) throws IgniteException;

public  ComputeTaskFuture affinityExecuteAsync(Class> taskCls, List partIds, @Nullable T arg) 
throws IgniteException;
public  ComputeTaskFuture affinityExecuteAsync(AffinityComputeTask task, List partIds, @Nullable T arg) throws IgniteException;


How do you like this idea or do you insist that you need to use 
@AffinityKeyMapped to solve the problem?


> 13 июля 2017 г., в 6:36, Valentin Kulichenko  
> написал(а):
> 
> Hi Max,
> 
> This ticket doesn't assume any API changes, it's about broken
> functionality. I would start with checking what tests we have
> for @AffinityKeyMapped and creating missing one. From what I understand
> functionality is broken completely or almost completely, so I guess testing
> coverage is very weak there.
> 
> -Val
> 
> On Wed, Jul 12, 2017 at 4:27 PM, Kozlov Maxim  wrote:
> 
>> Igniters,
>> 
>> jira: https://issues.apache.org/jira/browse/IGNITE-5037 <
>> https://issues.apache.org/jira/browse/IGNITE-5037>
>> How do you look to solve this ticket by adding two methods to the public
>> IgniteCompute API?
>> 
>> @IgniteAsyncSupported
>> public void affinityRun(@NotNull Collection cacheNames,
>> Collection keys, IgniteRunnable job)
>>throws IgniteException;
>> 
>> @IgniteAsyncSupported
>> public  R affinityCall(@NotNull Collection cacheNames,
>> Collection keys, IgniteCallable job)
>>throws IgniteException;
>> 
>> There is also a question of how to act when changing the topology during
>> the execution of the job.
>> 1) complete with an exception;
>> 2) stop execution and wait until the topology is rebuilt and continue
>> execution;
>> 
>> I think the second way, do you think?
>> 
>> --
>> Best Regards,
>> Max K.
>> 
>> 
>> 
>> 
>> 

--
Best Regards,
Max K.

Cache start ordering during cluster activation

[Jokser]

Hello Igniters,

Currently order of cache starts/stops operations is not determined during
cluster activation.
Some of the cache components can be depended on system or utility caches. If
such component starts earlier than system cache on what it's depended, it
can lead to unpredictable errors (e.g. NullPointerException)
I would like to introduce strict order of cache start/stop operations as it
is already implemented during normal node join process.
If we form cache start requests they should be ordered (first we should
start system caches then user), for cache stop requests order should be
reverse (first user caches then system).



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Cache-start-ordering-during-cluster-activation-tp19910.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[jira] [Created] (IGNITE-5804) ScanQuery transformer applies to first results page only.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-5804:


 Summary: ScanQuery transformer applies to first results page only.
 Key: IGNITE-5804
 URL: https://issues.apache.org/jira/browse/IGNITE-5804
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Andrew Mashenkov
 Fix For: 2.2


Issue is successfully reproduces on GridCacheQueryTransformerSelfTest if 
set ScanQuery.pageSize much lower then cache size.

We should rework GridCacheQueryTransformerSelfTest to run test on larger 
dataset 
to make pagination used.

http://apache-ignite-users.70518.x6.nabble.com/Transformer-not-called-on-every-ScanQuery-td15171.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2326: Ignite-5791: Block matrix introduction

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] ignite pull request #2331: IGNITE-5786 .NET: Fix cache store session handlin...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5786 .NET: Fix cache store session handling for cross-cache 
transactions



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

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

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

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


commit 70d0f9918c708cb117e69163cc7b7c119c9a693c
Author: Dmitriy Shabalin 
Date:   2017-07-20T08:08:20Z

IGNITE-4728 Web Console: Saved last succeeded state and redirect to it on 
reload.

commit 02a1bdca57ce6af7fe7636b0a9f99048c89b88b6
Author: Andrey Novikov 
Date:   2017-07-20T08:47:49Z

IGNITE-5788 Web Console: Fixed dependencies for maven project with c3p0.

commit 162fd2258066543b95633daf81ca5f20e85e3562
Author: Pavel Tupitsyn 
Date:   2017-07-20T13:32:44Z

IGNITE-5786 .NET: Transaction fails with multiple write-through caches

commit fe3f524e1bf350266d19051c85991b7c39ded3ff
Author: Pavel Tupitsyn 
Date:   2017-07-20T13:57:17Z

wip

commit 611bb3eebeb5f9f256147e4beb1465687e63f900
Author: Pavel Tupitsyn 
Date:   2017-07-20T14:01:41Z

wip

commit e7d3b814bba56257a784c4ca488a64ad5063d355
Author: Pavel Tupitsyn 
Date:   2017-07-20T14:02:12Z

wip

commit 2e01158b9d3556e9e64eea02f1b07f0f28b41133
Author: Pavel Tupitsyn 
Date:   2017-07-20T14:05:28Z

tests done

commit 3217782591ae19e891e8b3edbfd0f3cc60aab710
Author: Pavel Tupitsyn 
Date:   2017-07-20T14:06:47Z

tests done

commit cc273a6e6e516d343b3157591f8cad72271abc60
Author: Pavel Tupitsyn 
Date:   2017-07-20T14:09:44Z

wip

commit b8663694cde0d0d2a7f39dca93bf3bc998655111
Author: Pavel Tupitsyn 
Date:   2017-07-20T19:29:25Z

wip

commit c69912dc315632a390bf9c31e1e7b65f631a1cd2
Author: Pavel Tupitsyn 
Date:   2017-07-20T19:29:50Z

wip

commit e795ef51815bd3d18c4f605d22bde19f9f54d6f8
Author: Pavel Tupitsyn 
Date:   2017-07-20T19:52:09Z

Fix tests according to "once per store instance" logic

commit cb0d75d525cbb9f90bd5ff52f917817d8611f4de
Author: Pavel Tupitsyn 
Date:   2017-07-20T19:56:27Z

wip TODO

commit 72000904844529401c9d80c50f59748b70e83219
Author: Pavel Tupitsyn 
Date:   2017-07-21T09:43:57Z

wip

commit 7b6a452615979caa9978cd23b7dabf6f74da9fa9
Author: Pavel Tupitsyn 
Date:   2017-07-21T10:07:02Z

wip

commit 3b2f0aa8f6eaa9273576809def8c5326067c32a4
Author: Pavel Tupitsyn 
Date:   2017-07-21T10:54:52Z

fix Java side

commit 98d7e65cf019a797ef5b0d2028615eaad5fa2ec2
Author: Pavel Tupitsyn 
Date:   2017-07-21T10:56:05Z

fix .NET

commit 38b4a3987e0e816ef514fc9f60a67c3be2c6f2b0
Author: Pavel Tupitsyn 
Date:   2017-07-21T11:32:41Z

fix NPE

commit 4212d0c85578ce481a01973dd6c1bb6bf391171c
Author: Pavel Tupitsyn 
Date:   2017-07-21T11:37:41Z

wip

commit ce5b2b410bab863d35cf9260ca15ea995e92180d
Author: Pavel Tupitsyn 
Date:   2017-07-21T11:47:52Z

Tests adjusted, all done




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

[jira] [Created] (IGNITE-5803) IgniteCacheTestSuite4: IgniteCacheInvokeReadThroughTest: 6 test failed, stable reproducible locally

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-5803:
--

 Summary: IgniteCacheTestSuite4: IgniteCacheInvokeReadThroughTest: 
6 test failed, stable reproducible locally
 Key: IGNITE-5803
 URL: https://issues.apache.org/jira/browse/IGNITE-5803
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov


org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.IgniteCacheInvokeReadThroughTest.testInvokeReadThroughAtomicReplicated
  details »
org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.IgniteCacheInvokeReadThroughTest.testInvokeReadThroughTx0
   details »
org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.IgniteCacheInvokeReadThroughTest.testInvokeReadThroughTx1
   details »
org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.IgniteCacheInvokeReadThroughTest.testInvokeReadThroughTx2
   details »
org.apache.ignite.testsuites.IgniteCacheTestSuite4: 
org.apache.ignite.internal.processors.cache.IgniteCacheInvokeReadThroughTest.testInvokeReadThroughTxReplicated





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5802) Fix all wrong TODO comments in component

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5802:
--

 Summary: Fix all wrong TODO comments in component
 Key: IGNITE-5802
 URL: https://issues.apache.org/jira/browse/IGNITE-5802
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak
Assignee: Yury Babak
 Fix For: 2.2


(i) 
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-TODOs

Not all TODOs in componet following those rules, that must be fixed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Make Teamcity Green Again

[Pavel Tupitsyn]

> Green Again
> Again
As if it ever was green :)

Of course +1 on this, let me know if you see any .NET-related failures.

On Fri, Jul 21, 2017 at 1:06 PM, Николай Ижиков 
wrote:

> Hello, Igniters.
>
> Also ready to help to #MakeTeamcityGreenAgain !
>
> 21 июля 2017 г. 12:56 PM пользователь "Vyacheslav Daradur" <
> daradu...@gmail.com> написал:
>
> > Hi guys.
> >
> > I vote for #MakeTeamcityGreenAgain. :-)
> >
> > FYI: it had been described and supported previously[1]
> >
> > After the completion of my current task I will try to help with this
> > activity.
> >
> > [1]
> > http://apache-ignite-developers.2346864.n4.nabble.
> > com/Test-failures-td14353.html
> >
> > 2017-07-21 12:39 GMT+03:00 Anton Vinogradov :
> >
> > > Nikolay,
> > >
> > > That's also a big problem for me, as reviewer, to accept changes and
> > merge
> > > them to master.
> > >
> > > Dmitriy,
> > >
> > > Currently we have some contributions *from community* blocked by red
> > >  Teamcity.
> > >
> > > On Fri, Jul 21, 2017 at 12:47 AM, Nikolay Izhikov <
> > nizhikov@gmail.com>
> > > wrote:
> > >
> > > > +1 to Dmitry Pavlov from me.
> > > >
> > > > Green team city would be very helpful.
> > > >
> > > >
> > > > > If you are a newcomer, please share your feeling: are you confused
> by
> > > > test
> > > > > failures on Teamcity?
> > > >
> > > > I'm working on my very first ignite issue
> > > > and it's not easy to understand TC build results.
> > > >
> > > >
> > > > 21.07.2017 00:30, Dmitriy Setrakyan пишет:
> > > >
> > > > I think the right question to ask is why do we have RED tests to
> begin
> > > >> with. In my view, TC should be green. If there are tests that do not
> > > pass,
> > > >> we should disable them and file blocker tickets for the next
> releases.
> > > >>
> > > >> D.
> > > >>
> > > >> On Thu, Jul 20, 2017 at 1:20 PM, Dmitry Pavlov <
> dpavlov@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> Hi Igniters,
> > > >>>
> > > >>> We all know that there are a lot of open tasks in Ignite project.
> To
> > be
> > > >>> able to handle all these tasks, we need to grow our community. And
> to
> > > >>> achieve that, we should pay special attention to new community
> > members.
> > > >>>
> > > >>> As recent newcomer I’ve faced the following problem: There is no
> way
> > to
> > > >>> find out by yourself whether your pull request changes are correct
> or
> > > >>> not.
> > > >>> Contributor can not distinguish pull request test failures and
> master
> > > >>> test
> > > >>> failures. Experienced Ignite contributor can estimate the damage,
> but
> > > how
> > > >>> it can be done by new community member?
> > > >>>
> > > >>> Once failing test is introduced to master it is multiplexed to all
> > > later
> > > >>> PRs. As a result, we have tons of failures and suites timeouts,
> which
> > > >>> waste
> > > >>> Teamcity agents time.
> > > >>>
> > > >>> I suggest to start new activity - MakeTeamcityGreenAgain. I’m sure
> > that
> > > >>> there are a lot of experienced developers in the community who
> > > understand
> > > >>> issues with tests very quickly. Please contact me if you are ready
> to
> > > >>> help
> > > >>> the community to fix current test issues.
> > > >>>
> > > >>> I would appreciate any ideas and sharing your vision how we can
> > achieve
> > > >>> green teamcity.
> > > >>>
> > > >>> If you are a newcomer, please share your feeling: are you confused
> by
> > > >>> test
> > > >>> failures on Teamcity?
> > > >>>
> > > >>> Sincerely,
> > > >>>
> > > >>> Dmitriy Pavlov
> > > >>>
> > > >>>
> > > >>
> > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[jira] [Created] (IGNITE-5801) Externalization for offheap vectors/matrices

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5801:
--

 Summary: Externalization for offheap vectors/matrices
 Key: IGNITE-5801
 URL: https://issues.apache.org/jira/browse/IGNITE-5801
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


Add externalization support for off-heap structures.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5800) Umbrella ticket for making Teamcity Green Again

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-5800:
--

 Summary: Umbrella ticket for making Teamcity Green Again
 Key: IGNITE-5800
 URL: https://issues.apache.org/jira/browse/IGNITE-5800
 Project: Ignite
  Issue Type: Wish
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


*Discussions*
http://apache-ignite-developers.2346864.n4.nabble.com/Test-failures-td14353.html
http://apache-ignite-developers.2346864.n4.nabble.com/Make-Teamcity-Green-Again-td19873.html

*Goal*
To allow community grow more quickly and from the CI perspective, failing tests 
should be the main concern

For Run All dependencies at Ignite 20 Tests
http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=%3Cdefault%3E
there should be no stable red suites. timed out suites and stable red tests.

*Priorities*
Following priorities are suggested for issues
- Test suite timeout - it hides real test failures from us and wastes agent time
- Stable failing test - 50-100% of failures - issue is to be created as blocked 
to the next release, test should be muted.
- Flaky tests 1%-50% of failures, which are considered by teamcity as flaky may 
be not muted for now because TC interface helps us to identify these tests.

*Scope*
TBD by JIRA queries




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5799) Caching for some intermediate calcs

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5799:
--

 Summary: Caching for some intermediate calcs
 Key: IGNITE-5799
 URL: https://issues.apache.org/jira/browse/IGNITE-5799
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Yury Babak


Check possibility and necessity of caching some intermediate calcs like 
decomposition for matrix determinant calculation



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5798) Logging Ignite configuration at startup

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-5798:
--

 Summary: Logging Ignite configuration at startup
 Key: IGNITE-5798
 URL: https://issues.apache.org/jira/browse/IGNITE-5798
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexandr Kuramshin
 Fix For: 2.1


I've found that IgniteConfiguration is not logged even when -DIGNITE_QUIET=false

When we starting Ignite with path to the xml, or InputStream, we have to 
ensure, that all configuration options were properly read. And also we would 
like to know actual values of uninitialized configuration properties (default 
values), which will be set only after Ignite get started.

Monitoring tools, like Visor or WebConsole, do not show all configuration 
options. And even though they will be updated to show all properties, when new 
configuration options appear, then tools update will be needed.

Logging IgniteConfiguration at startup gives a possibility to ensure that the 
right grid configuration has been applied and leads to better user support 
based on log analyzing.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Yakov Zhdanov]

+1 binding

Checked maven build, imported and built examples project in IDEA and run
several compute exampled and started 2 nodes with default config.

--Yakov

2017-07-21 12:21 GMT+03:00 Anton Vinogradov :

> +1 (binding)
>
> On Fri, Jul 21, 2017 at 12:08 PM, Pavel Tupitsyn 
> wrote:
>
> > +1
> >
> > Checked .NET: nodes start and join from exe file, bat file, NuGet, user
> > project.
> >
> > On Fri, Jul 21, 2017 at 11:49 AM, Vyacheslav Daradur <
> daradu...@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > Build success now. Node starts without issues.
> > >
> > > 2017-07-21 11:38 GMT+03:00 Kozlov Maxim :
> > >
> > > > +1
> > > >
> > > > > 21 июля 2017 г., в 7:48, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> написал(а):
> > > > >
> > > > > +1 (binding)
> > > > >
> > > > > On Thu, Jul 20, 2017 at 9:35 PM, Sasha Belyak 
> > > > wrote:
> > > > >
> > > > >> +1
> > > > >>
> > > > >> 2017-07-21 5:34 GMT+07:00 Denis Magda :
> > > > >>
> > > > >>> Igniters,
> > > > >>>
> > > > >>> Setting off the vote one more time. Hope I’ll be successful this
> > > time,
> > > > >>> keeping fingers crossed :)
> > > > >>>
> > > > >>> We have uploaded a 2.1.0 release candidate to
> > > > >>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> > > > >>>
> > > > >>> Git tag name is
> > > > >>> 2.1.0-rc3
> > > > >>>
> > > > >>> This release includes the following changes:
> > > > >>>
> > > > >>> Ignite:
> > > > >>> * Persistent cache store
> > > > >>> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
> > > > mehtods
> > > > >>> * Deprecated IgniteConfiguration.marshaller
> > > > >>> * Updated Lucene dependency to version 5.5.2
> > > > >>> * Machine learning: implemented K-means clusterization algorithm
> > > > >> optimized
> > > > >>> for distributed storages
> > > > >>> * SQL: CREATE TABLE and DROP TABLE commands support
> > > > >>> * SQL: New thin JDBC driver
> > > > >>> * SQL: Improved performance of certain queries, when affinity
> node
> > > can
> > > > be
> > > > >>> calculated in advance
> > > > >>> * SQL: Fixed return type of AVG() function
> > > > >>> * SQL: BLOB type support added to thick JDBC driver
> > > > >>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support
> for
> > > > Java 8
> > > > >>> * SQL: Added FieldsQueryCursor interface to get fields metadata
> for
> > > > >>> SqlFieldsQuery
> > > > >>> * ODBC: Implemented DML statement batching
> > > > >>> * Massive performance and stability improvements
> > > > >>>
> > > > >>> Ignite.NET:
> > > > >>> * Automatic remote assembly loading
> > > > >>> * NuGet-based standalone node deployment
> > > > >>> * Added conditional data removeal via LINQ DeleteAll
> > > > >>> * Added TimestampAttribute to control DateTime serialization mode
> > > > >>> * Added local collections joins support to LINQ.
> > > > >>>
> > > > >>> Ignite CPP:
> > > > >>> * Added Compute::Call and Compute::Broadcast methods
> > > > >>>
> > > > >>> Web Console:
> > > > >>> * Implemented support for UNIQUE indexes for key fields on import
> > > model
> > > > >>> from RDBMS
> > > > >>> * Added option to show full stack trace on Queries screen
> > > > >>> * Added PK alias generation on Models screen.
> > > > >>>
> > > > >>> Complete list of closed issues:
> > > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20IGNITE%20AND%
> > > > >>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > > > >>> 20closed%20or%20status%20%3D%
> > > > >>> 20resolved)
> > > > >>>
> > > > >>> DEVNOTES
> > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > >>> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> > > > >>>
> > > > >>> RELEASE NOTES
> > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> > > > >>>
> > > > >>> Please start voting.
> > > > >>>
> > > > >>> +1 - to accept Apache Ignite 2.1.0-rc3
> > > > >>> 0 - don't care either way
> > > > >>> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
> > > > >>>
> > > > >>> This vote will go for 72 hours.
> > > > >>>
> > > > >>> —
> > > > >>> Denis
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > > > --
> > > > Best Regards,
> > > > Max K.
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>

Re: Make Teamcity Green Again

[Николай Ижиков]

Hello, Igniters.

Also ready to help to #MakeTeamcityGreenAgain !

21 июля 2017 г. 12:56 PM пользователь "Vyacheslav Daradur" <
daradu...@gmail.com> написал:

> Hi guys.
>
> I vote for #MakeTeamcityGreenAgain. :-)
>
> FYI: it had been described and supported previously[1]
>
> After the completion of my current task I will try to help with this
> activity.
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.
> com/Test-failures-td14353.html
>
> 2017-07-21 12:39 GMT+03:00 Anton Vinogradov :
>
> > Nikolay,
> >
> > That's also a big problem for me, as reviewer, to accept changes and
> merge
> > them to master.
> >
> > Dmitriy,
> >
> > Currently we have some contributions *from community* blocked by red
> >  Teamcity.
> >
> > On Fri, Jul 21, 2017 at 12:47 AM, Nikolay Izhikov <
> nizhikov@gmail.com>
> > wrote:
> >
> > > +1 to Dmitry Pavlov from me.
> > >
> > > Green team city would be very helpful.
> > >
> > >
> > > > If you are a newcomer, please share your feeling: are you confused by
> > > test
> > > > failures on Teamcity?
> > >
> > > I'm working on my very first ignite issue
> > > and it's not easy to understand TC build results.
> > >
> > >
> > > 21.07.2017 00:30, Dmitriy Setrakyan пишет:
> > >
> > > I think the right question to ask is why do we have RED tests to begin
> > >> with. In my view, TC should be green. If there are tests that do not
> > pass,
> > >> we should disable them and file blocker tickets for the next releases.
> > >>
> > >> D.
> > >>
> > >> On Thu, Jul 20, 2017 at 1:20 PM, Dmitry Pavlov  >
> > >> wrote:
> > >>
> > >> Hi Igniters,
> > >>>
> > >>> We all know that there are a lot of open tasks in Ignite project. To
> be
> > >>> able to handle all these tasks, we need to grow our community. And to
> > >>> achieve that, we should pay special attention to new community
> members.
> > >>>
> > >>> As recent newcomer I’ve faced the following problem: There is no way
> to
> > >>> find out by yourself whether your pull request changes are correct or
> > >>> not.
> > >>> Contributor can not distinguish pull request test failures and master
> > >>> test
> > >>> failures. Experienced Ignite contributor can estimate the damage, but
> > how
> > >>> it can be done by new community member?
> > >>>
> > >>> Once failing test is introduced to master it is multiplexed to all
> > later
> > >>> PRs. As a result, we have tons of failures and suites timeouts, which
> > >>> waste
> > >>> Teamcity agents time.
> > >>>
> > >>> I suggest to start new activity - MakeTeamcityGreenAgain. I’m sure
> that
> > >>> there are a lot of experienced developers in the community who
> > understand
> > >>> issues with tests very quickly. Please contact me if you are ready to
> > >>> help
> > >>> the community to fix current test issues.
> > >>>
> > >>> I would appreciate any ideas and sharing your vision how we can
> achieve
> > >>> green teamcity.
> > >>>
> > >>> If you are a newcomer, please share your feeling: are you confused by
> > >>> test
> > >>> failures on Teamcity?
> > >>>
> > >>> Sincerely,
> > >>>
> > >>> Dmitriy Pavlov
> > >>>
> > >>>
> > >>
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Fix for enum marshalling

[Vyacheslav Daradur]

Hi Nikita.

Thanks for the contribution!

If you are curious in BinaryMarshaler and want to continue improve it,
please, take a look to a task [1]

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


2017-07-21 12:53 GMT+03:00 Nikita Amelchev :

> Hi, Igniters.
> I fixed issue 5087 - Enum comparison fails after marshal-unmarshal with
> BinaryMarshaller. The solution is check superclass on enum. I created new
> public method isEnum(Class cls) for resolve enum mode in binary class
> descriptor. Also I get class name through getDeclaringClass() for enum
> type. My changes was merged to master.
>
> --
> Best wishes,
> Amelchev Nikita
>



-- 
Best Regards, Vyacheslav D.

Re: Make Teamcity Green Again

[Vyacheslav Daradur]

Hi guys.

I vote for #MakeTeamcityGreenAgain. :-)

FYI: it had been described and supported previously[1]

After the completion of my current task I will try to help with this
activity.

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Test-failures-td14353.html

2017-07-21 12:39 GMT+03:00 Anton Vinogradov :

> Nikolay,
>
> That's also a big problem for me, as reviewer, to accept changes and merge
> them to master.
>
> Dmitriy,
>
> Currently we have some contributions *from community* blocked by red
>  Teamcity.
>
> On Fri, Jul 21, 2017 at 12:47 AM, Nikolay Izhikov 
> wrote:
>
> > +1 to Dmitry Pavlov from me.
> >
> > Green team city would be very helpful.
> >
> >
> > > If you are a newcomer, please share your feeling: are you confused by
> > test
> > > failures on Teamcity?
> >
> > I'm working on my very first ignite issue
> > and it's not easy to understand TC build results.
> >
> >
> > 21.07.2017 00:30, Dmitriy Setrakyan пишет:
> >
> > I think the right question to ask is why do we have RED tests to begin
> >> with. In my view, TC should be green. If there are tests that do not
> pass,
> >> we should disable them and file blocker tickets for the next releases.
> >>
> >> D.
> >>
> >> On Thu, Jul 20, 2017 at 1:20 PM, Dmitry Pavlov 
> >> wrote:
> >>
> >> Hi Igniters,
> >>>
> >>> We all know that there are a lot of open tasks in Ignite project. To be
> >>> able to handle all these tasks, we need to grow our community. And to
> >>> achieve that, we should pay special attention to new community members.
> >>>
> >>> As recent newcomer I’ve faced the following problem: There is no way to
> >>> find out by yourself whether your pull request changes are correct or
> >>> not.
> >>> Contributor can not distinguish pull request test failures and master
> >>> test
> >>> failures. Experienced Ignite contributor can estimate the damage, but
> how
> >>> it can be done by new community member?
> >>>
> >>> Once failing test is introduced to master it is multiplexed to all
> later
> >>> PRs. As a result, we have tons of failures and suites timeouts, which
> >>> waste
> >>> Teamcity agents time.
> >>>
> >>> I suggest to start new activity - MakeTeamcityGreenAgain. I’m sure that
> >>> there are a lot of experienced developers in the community who
> understand
> >>> issues with tests very quickly. Please contact me if you are ready to
> >>> help
> >>> the community to fix current test issues.
> >>>
> >>> I would appreciate any ideas and sharing your vision how we can achieve
> >>> green teamcity.
> >>>
> >>> If you are a newcomer, please share your feeling: are you confused by
> >>> test
> >>> failures on Teamcity?
> >>>
> >>> Sincerely,
> >>>
> >>> Dmitriy Pavlov
> >>>
> >>>
> >>
>



-- 
Best Regards, Vyacheslav D.

Fix for enum marshalling

[Nikita Amelchev]

Hi, Igniters.
I fixed issue 5087 - Enum comparison fails after marshal-unmarshal with
BinaryMarshaller. The solution is check superclass on enum. I created new
public method isEnum(Class cls) for resolve enum mode in binary class
descriptor. Also I get class name through getDeclaringClass() for enum
type. My changes was merged to master.

-- 
Best wishes,
Amelchev Nikita

Re: Make Teamcity Green Again

[Anton Vinogradov]

Nikolay,

That's also a big problem for me, as reviewer, to accept changes and merge
them to master.

Dmitriy,

Currently we have some contributions *from community* blocked by red
 Teamcity.

On Fri, Jul 21, 2017 at 12:47 AM, Nikolay Izhikov 
wrote:

> +1 to Dmitry Pavlov from me.
>
> Green team city would be very helpful.
>
>
> > If you are a newcomer, please share your feeling: are you confused by
> test
> > failures on Teamcity?
>
> I'm working on my very first ignite issue
> and it's not easy to understand TC build results.
>
>
> 21.07.2017 00:30, Dmitriy Setrakyan пишет:
>
> I think the right question to ask is why do we have RED tests to begin
>> with. In my view, TC should be green. If there are tests that do not pass,
>> we should disable them and file blocker tickets for the next releases.
>>
>> D.
>>
>> On Thu, Jul 20, 2017 at 1:20 PM, Dmitry Pavlov 
>> wrote:
>>
>> Hi Igniters,
>>>
>>> We all know that there are a lot of open tasks in Ignite project. To be
>>> able to handle all these tasks, we need to grow our community. And to
>>> achieve that, we should pay special attention to new community members.
>>>
>>> As recent newcomer I’ve faced the following problem: There is no way to
>>> find out by yourself whether your pull request changes are correct or
>>> not.
>>> Contributor can not distinguish pull request test failures and master
>>> test
>>> failures. Experienced Ignite contributor can estimate the damage, but how
>>> it can be done by new community member?
>>>
>>> Once failing test is introduced to master it is multiplexed to all later
>>> PRs. As a result, we have tons of failures and suites timeouts, which
>>> waste
>>> Teamcity agents time.
>>>
>>> I suggest to start new activity - MakeTeamcityGreenAgain. I’m sure that
>>> there are a lot of experienced developers in the community who understand
>>> issues with tests very quickly. Please contact me if you are ready to
>>> help
>>> the community to fix current test issues.
>>>
>>> I would appreciate any ideas and sharing your vision how we can achieve
>>> green teamcity.
>>>
>>> If you are a newcomer, please share your feeling: are you confused by
>>> test
>>> failures on Teamcity?
>>>
>>> Sincerely,
>>>
>>> Dmitriy Pavlov
>>>
>>>
>>

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Anton Vinogradov]

+1 (binding)

On Fri, Jul 21, 2017 at 12:08 PM, Pavel Tupitsyn 
wrote:

> +1
>
> Checked .NET: nodes start and join from exe file, bat file, NuGet, user
> project.
>
> On Fri, Jul 21, 2017 at 11:49 AM, Vyacheslav Daradur 
> wrote:
>
> > +1
> >
> > Build success now. Node starts without issues.
> >
> > 2017-07-21 11:38 GMT+03:00 Kozlov Maxim :
> >
> > > +1
> > >
> > > > 21 июля 2017 г., в 7:48, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> написал(а):
> > > >
> > > > +1 (binding)
> > > >
> > > > On Thu, Jul 20, 2017 at 9:35 PM, Sasha Belyak 
> > > wrote:
> > > >
> > > >> +1
> > > >>
> > > >> 2017-07-21 5:34 GMT+07:00 Denis Magda :
> > > >>
> > > >>> Igniters,
> > > >>>
> > > >>> Setting off the vote one more time. Hope I’ll be successful this
> > time,
> > > >>> keeping fingers crossed :)
> > > >>>
> > > >>> We have uploaded a 2.1.0 release candidate to
> > > >>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> > > >>>
> > > >>> Git tag name is
> > > >>> 2.1.0-rc3
> > > >>>
> > > >>> This release includes the following changes:
> > > >>>
> > > >>> Ignite:
> > > >>> * Persistent cache store
> > > >>> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
> > > mehtods
> > > >>> * Deprecated IgniteConfiguration.marshaller
> > > >>> * Updated Lucene dependency to version 5.5.2
> > > >>> * Machine learning: implemented K-means clusterization algorithm
> > > >> optimized
> > > >>> for distributed storages
> > > >>> * SQL: CREATE TABLE and DROP TABLE commands support
> > > >>> * SQL: New thin JDBC driver
> > > >>> * SQL: Improved performance of certain queries, when affinity node
> > can
> > > be
> > > >>> calculated in advance
> > > >>> * SQL: Fixed return type of AVG() function
> > > >>> * SQL: BLOB type support added to thick JDBC driver
> > > >>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
> > > Java 8
> > > >>> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> > > >>> SqlFieldsQuery
> > > >>> * ODBC: Implemented DML statement batching
> > > >>> * Massive performance and stability improvements
> > > >>>
> > > >>> Ignite.NET:
> > > >>> * Automatic remote assembly loading
> > > >>> * NuGet-based standalone node deployment
> > > >>> * Added conditional data removeal via LINQ DeleteAll
> > > >>> * Added TimestampAttribute to control DateTime serialization mode
> > > >>> * Added local collections joins support to LINQ.
> > > >>>
> > > >>> Ignite CPP:
> > > >>> * Added Compute::Call and Compute::Broadcast methods
> > > >>>
> > > >>> Web Console:
> > > >>> * Implemented support for UNIQUE indexes for key fields on import
> > model
> > > >>> from RDBMS
> > > >>> * Added option to show full stack trace on Queries screen
> > > >>> * Added PK alias generation on Models screen.
> > > >>>
> > > >>> Complete list of closed issues:
> > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20IGNITE%20AND%
> > > >>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > > >>> 20closed%20or%20status%20%3D%
> > > >>> 20resolved)
> > > >>>
> > > >>> DEVNOTES
> > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > >>> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> > > >>>
> > > >>> RELEASE NOTES
> > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> > > >>>
> > > >>> Please start voting.
> > > >>>
> > > >>> +1 - to accept Apache Ignite 2.1.0-rc3
> > > >>> 0 - don't care either way
> > > >>> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
> > > >>>
> > > >>> This vote will go for 72 hours.
> > > >>>
> > > >>> —
> > > >>> Denis
> > > >>>
> > > >>>
> > > >>
> > >
> > > --
> > > Best Regards,
> > > Max K.
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Pavel Tupitsyn]

+1

Checked .NET: nodes start and join from exe file, bat file, NuGet, user
project.

On Fri, Jul 21, 2017 at 11:49 AM, Vyacheslav Daradur 
wrote:

> +1
>
> Build success now. Node starts without issues.
>
> 2017-07-21 11:38 GMT+03:00 Kozlov Maxim :
>
> > +1
> >
> > > 21 июля 2017 г., в 7:48, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> написал(а):
> > >
> > > +1 (binding)
> > >
> > > On Thu, Jul 20, 2017 at 9:35 PM, Sasha Belyak 
> > wrote:
> > >
> > >> +1
> > >>
> > >> 2017-07-21 5:34 GMT+07:00 Denis Magda :
> > >>
> > >>> Igniters,
> > >>>
> > >>> Setting off the vote one more time. Hope I’ll be successful this
> time,
> > >>> keeping fingers crossed :)
> > >>>
> > >>> We have uploaded a 2.1.0 release candidate to
> > >>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> > >>>
> > >>> Git tag name is
> > >>> 2.1.0-rc3
> > >>>
> > >>> This release includes the following changes:
> > >>>
> > >>> Ignite:
> > >>> * Persistent cache store
> > >>> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
> > mehtods
> > >>> * Deprecated IgniteConfiguration.marshaller
> > >>> * Updated Lucene dependency to version 5.5.2
> > >>> * Machine learning: implemented K-means clusterization algorithm
> > >> optimized
> > >>> for distributed storages
> > >>> * SQL: CREATE TABLE and DROP TABLE commands support
> > >>> * SQL: New thin JDBC driver
> > >>> * SQL: Improved performance of certain queries, when affinity node
> can
> > be
> > >>> calculated in advance
> > >>> * SQL: Fixed return type of AVG() function
> > >>> * SQL: BLOB type support added to thick JDBC driver
> > >>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
> > Java 8
> > >>> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> > >>> SqlFieldsQuery
> > >>> * ODBC: Implemented DML statement batching
> > >>> * Massive performance and stability improvements
> > >>>
> > >>> Ignite.NET:
> > >>> * Automatic remote assembly loading
> > >>> * NuGet-based standalone node deployment
> > >>> * Added conditional data removeal via LINQ DeleteAll
> > >>> * Added TimestampAttribute to control DateTime serialization mode
> > >>> * Added local collections joins support to LINQ.
> > >>>
> > >>> Ignite CPP:
> > >>> * Added Compute::Call and Compute::Broadcast methods
> > >>>
> > >>> Web Console:
> > >>> * Implemented support for UNIQUE indexes for key fields on import
> model
> > >>> from RDBMS
> > >>> * Added option to show full stack trace on Queries screen
> > >>> * Added PK alias generation on Models screen.
> > >>>
> > >>> Complete list of closed issues:
> > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20IGNITE%20AND%
> > >>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > >>> 20closed%20or%20status%20%3D%
> > >>> 20resolved)
> > >>>
> > >>> DEVNOTES
> > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > >>> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> > >>>
> > >>> RELEASE NOTES
> > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> > >>>
> > >>> Please start voting.
> > >>>
> > >>> +1 - to accept Apache Ignite 2.1.0-rc3
> > >>> 0 - don't care either way
> > >>> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
> > >>>
> > >>> This vote will go for 72 hours.
> > >>>
> > >>> —
> > >>> Denis
> > >>>
> > >>>
> > >>
> >
> > --
> > Best Regards,
> > Max K.
> >
> >
> >
> >
> >
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Vyacheslav Daradur]

+1

Build success now. Node starts without issues.

2017-07-21 11:38 GMT+03:00 Kozlov Maxim :

> +1
>
> > 21 июля 2017 г., в 7:48, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> написал(а):
> >
> > +1 (binding)
> >
> > On Thu, Jul 20, 2017 at 9:35 PM, Sasha Belyak 
> wrote:
> >
> >> +1
> >>
> >> 2017-07-21 5:34 GMT+07:00 Denis Magda :
> >>
> >>> Igniters,
> >>>
> >>> Setting off the vote one more time. Hope I’ll be successful this time,
> >>> keeping fingers crossed :)
> >>>
> >>> We have uploaded a 2.1.0 release candidate to
> >>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
> >>>
> >>> Git tag name is
> >>> 2.1.0-rc3
> >>>
> >>> This release includes the following changes:
> >>>
> >>> Ignite:
> >>> * Persistent cache store
> >>> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
> mehtods
> >>> * Deprecated IgniteConfiguration.marshaller
> >>> * Updated Lucene dependency to version 5.5.2
> >>> * Machine learning: implemented K-means clusterization algorithm
> >> optimized
> >>> for distributed storages
> >>> * SQL: CREATE TABLE and DROP TABLE commands support
> >>> * SQL: New thin JDBC driver
> >>> * SQL: Improved performance of certain queries, when affinity node can
> be
> >>> calculated in advance
> >>> * SQL: Fixed return type of AVG() function
> >>> * SQL: BLOB type support added to thick JDBC driver
> >>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
> Java 8
> >>> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> >>> SqlFieldsQuery
> >>> * ODBC: Implemented DML statement batching
> >>> * Massive performance and stability improvements
> >>>
> >>> Ignite.NET:
> >>> * Automatic remote assembly loading
> >>> * NuGet-based standalone node deployment
> >>> * Added conditional data removeal via LINQ DeleteAll
> >>> * Added TimestampAttribute to control DateTime serialization mode
> >>> * Added local collections joins support to LINQ.
> >>>
> >>> Ignite CPP:
> >>> * Added Compute::Call and Compute::Broadcast methods
> >>>
> >>> Web Console:
> >>> * Implemented support for UNIQUE indexes for key fields on import model
> >>> from RDBMS
> >>> * Added option to show full stack trace on Queries screen
> >>> * Added PK alias generation on Models screen.
> >>>
> >>> Complete list of closed issues:
> >>> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20IGNITE%20AND%
> >>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> >>> 20closed%20or%20status%20%3D%
> >>> 20resolved)
> >>>
> >>> DEVNOTES
> >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> >>> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
> >>>
> >>> RELEASE NOTES
> >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
> >>>
> >>> Please start voting.
> >>>
> >>> +1 - to accept Apache Ignite 2.1.0-rc3
> >>> 0 - don't care either way
> >>> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
> >>>
> >>> This vote will go for 72 hours.
> >>>
> >>> —
> >>> Denis
> >>>
> >>>
> >>
>
> --
> Best Regards,
> Max K.
>
>
>
>
>


-- 
Best Regards, Vyacheslav D.

Re: [VOTE] Apache Ignite 2.1.0 RC3

[Kozlov Maxim]

+1

> 21 июля 2017 г., в 7:48, Valentin Kulichenko  
> написал(а):
> 
> +1 (binding)
> 
> On Thu, Jul 20, 2017 at 9:35 PM, Sasha Belyak  wrote:
> 
>> +1
>> 
>> 2017-07-21 5:34 GMT+07:00 Denis Magda :
>> 
>>> Igniters,
>>> 
>>> Setting off the vote one more time. Hope I’ll be successful this time,
>>> keeping fingers crossed :)
>>> 
>>> We have uploaded a 2.1.0 release candidate to
>>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc3/
>>> 
>>> Git tag name is
>>> 2.1.0-rc3
>>> 
>>> This release includes the following changes:
>>> 
>>> Ignite:
>>> * Persistent cache store
>>> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
>>> * Deprecated IgniteConfiguration.marshaller
>>> * Updated Lucene dependency to version 5.5.2
>>> * Machine learning: implemented K-means clusterization algorithm
>> optimized
>>> for distributed storages
>>> * SQL: CREATE TABLE and DROP TABLE commands support
>>> * SQL: New thin JDBC driver
>>> * SQL: Improved performance of certain queries, when affinity node can be
>>> calculated in advance
>>> * SQL: Fixed return type of AVG() function
>>> * SQL: BLOB type support added to thick JDBC driver
>>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
>>> * SQL: Added FieldsQueryCursor interface to get fields metadata for
>>> SqlFieldsQuery
>>> * ODBC: Implemented DML statement batching
>>> * Massive performance and stability improvements
>>> 
>>> Ignite.NET:
>>> * Automatic remote assembly loading
>>> * NuGet-based standalone node deployment
>>> * Added conditional data removeal via LINQ DeleteAll
>>> * Added TimestampAttribute to control DateTime serialization mode
>>> * Added local collections joins support to LINQ.
>>> 
>>> Ignite CPP:
>>> * Added Compute::Call and Compute::Broadcast methods
>>> 
>>> Web Console:
>>> * Implemented support for UNIQUE indexes for key fields on import model
>>> from RDBMS
>>> * Added option to show full stack trace on Queries screen
>>> * Added PK alias generation on Models screen.
>>> 
>>> Complete list of closed issues:
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
>>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
>>> 20closed%20or%20status%20%3D%
>>> 20resolved)
>>> 
>>> DEVNOTES
>>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
>>> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc3
>>> 
>>> RELEASE NOTES
>>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
>>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc3
>>> 
>>> Please start voting.
>>> 
>>> +1 - to accept Apache Ignite 2.1.0-rc3
>>> 0 - don't care either way
>>> -1 - DO NOT accept Apache Ignite 2.1.0-rc3 (explain why)
>>> 
>>> This vote will go for 72 hours.
>>> 
>>> —
>>> Denis
>>> 
>>> 
>> 

--
Best Regards,
Max K.

[jira] [Created] (IGNITE-5797) Add latency tracing capability for cache operations

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5797:


 Summary: Add latency tracing capability for cache operations
 Key: IGNITE-5797
 URL: https://issues.apache.org/jira/browse/IGNITE-5797
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.2


As a proof-of-concept, it would be great to add tracing capabilities for tx 
commit phase.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: "not null" constraint support

[Pavel Tupitsyn]

Hi Sergey,

This one looks not very good to me:

> class QueryEntity {
> ...
> Set notNullFields;
> }

What if there are more constraints in future? UNIQUE, CHECK, etc etc?

Instead we could do something like

Set constraints;

Which is easily extendable in future.

Thoughts?

Pavel

On Thu, Jul 20, 2017 at 11:17 PM, Denis Magda  wrote:

> Hi Sergey,
>
> That will be an excellent addition to DDL features set.
>
> The proposed changes look good to from the public API standpoint.
>
> Alexander P., Sergi, Vovan, please share your thoughts.
>
> —
> Denis
>
> > On Jul 20, 2017, at 12:27 PM, Sergey Kalashnikov 
> wrote:
> >
> > Hi Igniters,
> >
> > I am working on the ticket
> > https://issues.apache.org/jira/browse/IGNITE-5648, which purpose is to
> > add support for NOT NULL constraint for any fields of key or value
> > stored in Ignite cache.
> >
> > I would appreciate your comments on the design approach I have described
> below.
> >
> > In my opinion, such checks should be enforced both by SQL DML and
> > cache API to be consistent.
> >
> > Here is my analysis of what needs to be done.
> >
> > 1. First, the SQL CREATE table will not throw exception anymore
> > whenever it encounters a column with "not null" modifier.
> > Instead, the resulting QueryEntity will now indicate which fields have
> > such modifier.
> >
> > The proposed way of doing this is the following:
> > class QueryEntity {
> >...
> >Set notNullFields;
> > }
> >
> > Since QueryEntity is a part of public api, it becomes possible to
> > configure this constraint not only via DDL CREATE TABLE.
> >
> > 2. Then we need a special method on GridQueryProcessor that for the
> > given cacheName, key and value would perform the following things:
> > - Get a GridQueryTypeDescriptor that corresponds to given value type;
> > - Delegate that GridQueryTypeDescriptor a task to validate given key and
> value;
> > - Type descriptor would itself delegate the validation to its
> > GridQueryProperties that have "not null" constraint.
> >
> > 3. To enforce the constraints, the validation method should be called
> > - In GridNearAtomicSingleUpdateFuture.mapSingleUpdate() and
> > GridNearAtomicUpdateFuture.mapUpdate() when operation is CREATE or
> > UPDATE.
> > That would cover putIfAbsent(), getAndPut(), getAndPutIfAbsent(),
> > replace(), getAndReplace(), putAll() operations on atomic cache.
> > And in GridNearTxLocal.enlistWriteEntry() when operation is CREATE or
> > UPDATE for the case of transactional cache.
> >
> > - Right after EntryProcessor.process() in
> > GridCacheMapEntry.AtomicCacheUpdateClosure.runEntryProcessor() as part
> > of invoke(), invokeAll() operations on atomic cache.
> > And in GridDhtTxPrepareFuture.onEntriesLocked() for the case of
> > transactional cache.
> >
> > 4. DML processor changes
> >  The DMLStatementProcessor methods doInsert(), doUpdate(), doMerge()
> > must also incorporate such checks to avoid attempts
> >  to insert values that are known to be rejected by cache.
> >
> > Thoughts?
> >
> > --
> > Best regards,
> > Sergey
>
>