[jira] [Created] (IGNITE-4766) Relax worker thread wakeup logic in StipedExecutor

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4766:
---

 Summary: Relax worker thread wakeup logic in StipedExecutor
 Key: IGNITE-4766
 URL: https://issues.apache.org/jira/browse/IGNITE-4766
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.0
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.0


*Problem*
Worker threads in {{StripedExecutor}} have {{parked}} state flag. When set to 
{{true}} NIO threads will call {{LockSupport.unpark}} after submitting new task 
to a queue.

The problem is that this flag is only changed by worker thread. Thus, if NIO 
worker submitted a new task and called {{unpark}}, worker will clean up 
{{parked}} state only after real wake up what may take microseconds. All 
subsequent submits from NIO thread occurred during this time will also invoke 
{{unpark}} thus generating high contention on the underlying OS primitives. 
Namely, condition variables which ultimately delegates to {{futex}} on Linux.

*Solution*
NIO threads must be able to clear {{parked}} state as well. Some CAS magic will 
be required there. This way we will minimize number of {{unapark}} calls.



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

Re: IGNITE-4758 - introducing cache memory policies

[Sergey Chugunov]

Yes, they use the same PageMemory region.

On Wed, Mar 1, 2017 at 10:34 PM, Dmitriy Setrakyan 
wrote:

> When 2 caches share the same memory policy, does it mean that they are
> using the same Page Memory offheap space?
>
> On Tue, Feb 28, 2017 at 11:49 PM, Sergey Chugunov <
> sergey.chugu...@gmail.com
> > wrote:
>
> > Dmitriy,
> >
> > Correct, cache configuration may contain a name of memory policy to use
> for
> > this cache.
> > If memory policy is not specified, a default one is used.
> >
> > Thanks,
> > Sergey.
> >
> > On Wed, Mar 1, 2017 at 1:02 AM, Dmitriy Setrakyan  >
> > wrote:
> >
> > > Thanks Sergey!
> > >
> > > Just to confirm, the same memory policy could be shared between
> different
> > > caches, right?
> > >
> > > D.
> > >
> > > On Tue, Feb 28, 2017 at 1:28 AM, Sergey Chugunov <
> > > sergey.chugu...@gmail.com>
> > > wrote:
> > >
> > > > Hello Ignite devs,
> > > >
> > > > I created new subtask  > jira/browse/IGNITE-4758
> > > >
> > > > under IGNITE-3477  >
> > > with
> > > > my vision of how *MemoryPolicy* may be implemented.
> > > >
> > > > In a nutshell my idea is as follows: instead of having only one
> > instance
> > > of
> > > > *PageMemory* and managing a mapping [cacheId->pageMemory region] I
> > > suggest
> > > > introducing separate *PageMemory* instance (and corresponding
> > *FreeList*
> > > > and *ReuseList* structures) for each *MemoryPolicy* configuration.
> > > > This instance will be stored in individual cache contexts instead of
> > > shared
> > > > cache context as it is right now.
> > > >
> > > > I think this design is a very natural extension of *PageMemory*
> concept
> > > and
> > > > should not introduce any performance degradation as no changes are
> > > > introduced into *PageMemory* implementation itself.
> > > >
> > > > Please share any thoughts or concerns about suggested design in this
> > > thread
> > > > or in comments under the subtask
> > > > .
> > > >
> > > > Thanks,
> > > > Sergey.
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-4767) rollback exception hides the origin exception (e.g. commit)

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-4767:
--

 Summary: rollback exception hides the origin exception (e.g. 
commit)
 Key: IGNITE-4767
 URL: https://issues.apache.org/jira/browse/IGNITE-4767
 Project: Ignite
  Issue Type: Bug
  Components: cache, general
Affects Versions: 1.8
Reporter: Alexandr Kuramshin
 Fix For: 2.0


There is too much code places like:
{noformat}
try {
return txFuture.get();
}
catch (IgniteCheckedException e) {
tx.rollbackAsync();

throw e;
}
{noformat}
where an error upon rollback hides the actual exception {{e}}.

This should be implemented in the way like try-with-resources does:
{noformat}
try {
return txFuture.get();
}
catch (IgniteCheckedException e1) {
try {
tx.rollbackAsync();
}
catch (Throwable inner) {
e.addSuppressed(inner);
}

throw e;
}
{noformat}




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

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

[ALEKSEY KUZNETSOV]

lets review code at github rather than upsource later on. Because, the
later is too slow and bring no substantial benefits compared github

ср, 1 мар. 2017 г. в 18:04, Andrey Gura :

> Hi, Aleksey!
>
> Thank you for contribution!
>
> I've reviewed your changes and have some comments (mostly cosmetic).
> Could you please fix this comment? See review in Upsource for details.
>
> On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
>  wrote:
> > Plz, review my PR :
> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
> > or https://github.com/apache/ignite/pull/1545
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Additional SQL metrics

[Vladimir Ozerov]

Denis,

Query execution is complex process involving different stages which are not
very easy to match with each other. Especially provided that any node can
leave topology at any time. Another problem is that engine evolves and
metrics like "did a query do broadcast or unicast" may easily become
useless at some point, because for example there will be neither unicast,
nor broadast, but something different. On the other hand I completely agree
that performance monitoring is essential part of any mature DBMS.

I would start with metrics which are both very basic and easy to implement
at the same time. For example we can add fingerprint (hash) to every query
which will be used to join "map" and "reduce" parts with each other and add
the following basic metrics:
1) Execution count for particular query
2) Number of map nodes - min, max, avg
3) Map step duration (if applicable) - min, max, avg
4) Reduce step duration (if applicable) - min, max, avg

Once done users will be able to get statistics for particular queries.

Vladimir.


On Tue, Feb 28, 2017 at 3:12 AM, Denis Magda  wrote:

> BTW,
>
> What if we expose per-query metrics below as a part of EXPLAIN ANALYZE?
> Sergi, is this feasible?
>
> —
> Denis
>
> > On Feb 27, 2017, at 2:35 PM, Denis Magda  wrote:
> >
> > Igniters,
> >
> > Let’s shed more light on SQL query execution internals introducing a set
> of useful metrics (https://issues.apache.org/jira/browse/IGNITE-4757).
> >
> > Per-query metrics. Total history size is defined by *CacheConfiguration.
> getQueryDetailMetricsSize*:
> > * if a query was executed in the collocated or non-collocated mode.
> Three results are valid: collocated, non-collocated, simple query (no
> joins).
> > * non-collocated query: size of the data exchanged between the nodes to
> complete a join.
> > * non-collocated query: did a query do broadcast or unicast to get data
> needed to complete a join.
> > * non-collocated and collocated query: a part of the time spent joining
> the data.
> >
> > CacheMetrics:
> > * an average number of executed SQL queries (collocated, non-collocated,
> simple query (no joins)).
> >
> > Please don’t hesitate do share suggest another metrics or improve
> proposed ones.
> >
> > —
> > Denis
>
>

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

Denis, Sergey witch version of JDK8 do you use?

I got this exception with the lates jdk-8u121.

Building with flag "-Dmaven.javadoc.skip=true" works fine.

Look at "*New --allow-script-in-comments option for javadoc":*
http://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html



2017-03-02 10:53 GMT+03:00 Sergey Kozlov :

> Hi
>
> I confirm the issue. Unfortunately it was introduced with latest commits
> after the run of full set of tests.
>
> On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda  wrote:
>
> > Getting absolutely the same exception under JDK 8.
> >
> > —
> > Denis
> >
> > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> > >
> > > -1
> > >
> > > Building with 'mvn clean package -DskipTests' under JDK8 fails with the
> > > error below. JDK7 is fine, though.
> > >
> > > [INFO] 
> > > 
> > > [INFO] BUILD FAILURE
> > > [INFO] 
> > > 
> > > [INFO] Total time: 12.626 s
> > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
> > > [INFO] Final Memory: 80M/654M
> > > [INFO] 
> > > 
> > > [ERROR] Failed to execute goal org.apache.maven.plugins:
> > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project
> > ignite-tools:
> > > MavenReportException: Error while creating archive:
> > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
> > > --allow-script-in-comments
> > > [ERROR]
> > > [ERROR] Command line was: /Library/Java/JavaVirtualMachines/jdk1.8.0_
> > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> > > [ERROR]
> > > [ERROR] Refer to the generated Javadoc files in
> > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
> > modules/tools/target/apidocs'
> > > dir.
> > > [ERROR] -> [Help 1]
> > >
> > > -Val
> > >
> > > On Tue, Feb 28, 2017 at 11:51 PM, Антон Чураев 
> > wrote:
> > >
> > >> +1
> > >>
> > >> 2017-03-01 10:28 GMT+03:00 Anton Vinogradov :
> > >>
> > >>> Dear Sirs!
> > >>>
> > >>> We have uploaded the 1.9.0 release candidate to
> > >>> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
> > >>>
> > >>> Git tag name is
> > >>> 1.9.0-rc1
> > >>>
> > >>> This release includes the following changes:
> > >>>
> > >>> Ignite:
> > >>> * Added Data streamer mode for DML
> > >>> * Added Discovery SPI Implementation for Ignite Kubernetes Pods
> > >>> * SQL: Query can utilize multiple threads
> > >>> * SQL: Improved distributed SQL support
> > >>> * Benchmarking simplified and automated
> > >>> * Fixed licenses generation during build
> > >>> * ignite-spark module upgraded to Spark 2.0
> > >>>
> > >>> Ignite.NET:
> > >>> * DML support
> > >>> * TransactionScope API for Ignite transactions support
> > >>>
> > >>> Ignite CPP:
> > >>> * DML support
> > >>> * Implemented LoadCache
> > >>> * ContinuousQuery support
> > >>>
> > >>> Complete list of closed issues:
> > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20IGNITE%20AND%
> > >>> 20fixVersion%20%3D%201.9%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/1.9.0-rc1
> > >>>
> > >>> RELEASENOTES
> > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc1
> > >>>
> > >>> Please start voting.
> > >>>
> > >>> +1 - to accept Apache Ignite 1.9.0-rc1
> > >>> 0 - don't care either way
> > >>> -1 - DO NOT accept Apache Ignite 1.9.0-rc1 (explain why)
> > >>>
> > >>> This vote will go for 72 hours.
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> С уважением,
> > >> Чураев Антон
> > >>
> >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

[ALEKSEY KUZNETSOV]

Hi, Andrey! Have fixed the comments. Plz, Look up

чт, 2 мар. 2017 г. в 11:29, ALEKSEY KUZNETSOV :

> lets review code at github rather than upsource later on. Because, the
> later is too slow and bring no substantial benefits compared github
>
> ср, 1 мар. 2017 г. в 18:04, Andrey Gura :
>
> Hi, Aleksey!
>
> Thank you for contribution!
>
> I've reviewed your changes and have some comments (mostly cosmetic).
> Could you please fix this comment? See review in Upsource for details.
>
> On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
>  wrote:
> > Plz, review my PR :
> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
> > or https://github.com/apache/ignite/pull/1545
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Sergey Kozlov]

I used Oracle JDK 1.8.0_91

On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur 
wrote:

> Denis, Sergey witch version of JDK8 do you use?
>
> I got this exception with the lates jdk-8u121.
>
> Building with flag "-Dmaven.javadoc.skip=true" works fine.
>
> Look at "*New --allow-script-in-comments option for javadoc":*
> http://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html
>
>
>
> 2017-03-02 10:53 GMT+03:00 Sergey Kozlov :
>
> > Hi
> >
> > I confirm the issue. Unfortunately it was introduced with latest commits
> > after the run of full set of tests.
> >
> > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda  wrote:
> >
> > > Getting absolutely the same exception under JDK 8.
> > >
> > > —
> > > Denis
> > >
> > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > -1
> > > >
> > > > Building with 'mvn clean package -DskipTests' under JDK8 fails with
> the
> > > > error below. JDK7 is fine, though.
> > > >
> > > > [INFO] 
> > > > 
> > > > [INFO] BUILD FAILURE
> > > > [INFO] 
> > > > 
> > > > [INFO] Total time: 12.626 s
> > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
> > > > [INFO] Final Memory: 80M/654M
> > > > [INFO] 
> > > > 
> > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
> > > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project
> > > ignite-tools:
> > > > MavenReportException: Error while creating archive:
> > > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
> > > > --allow-script-in-comments
> > > > [ERROR]
> > > > [ERROR] Command line was: /Library/Java/
> JavaVirtualMachines/jdk1.8.0_
> > > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> > > > [ERROR]
> > > > [ERROR] Refer to the generated Javadoc files in
> > > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
> > > modules/tools/target/apidocs'
> > > > dir.
> > > > [ERROR] -> [Help 1]
> > > >
> > > > -Val
> > > >
> > > > On Tue, Feb 28, 2017 at 11:51 PM, Антон Чураев  >
> > > wrote:
> > > >
> > > >> +1
> > > >>
> > > >> 2017-03-01 10:28 GMT+03:00 Anton Vinogradov :
> > > >>
> > > >>> Dear Sirs!
> > > >>>
> > > >>> We have uploaded the 1.9.0 release candidate to
> > > >>> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
> > > >>>
> > > >>> Git tag name is
> > > >>> 1.9.0-rc1
> > > >>>
> > > >>> This release includes the following changes:
> > > >>>
> > > >>> Ignite:
> > > >>> * Added Data streamer mode for DML
> > > >>> * Added Discovery SPI Implementation for Ignite Kubernetes Pods
> > > >>> * SQL: Query can utilize multiple threads
> > > >>> * SQL: Improved distributed SQL support
> > > >>> * Benchmarking simplified and automated
> > > >>> * Fixed licenses generation during build
> > > >>> * ignite-spark module upgraded to Spark 2.0
> > > >>>
> > > >>> Ignite.NET:
> > > >>> * DML support
> > > >>> * TransactionScope API for Ignite transactions support
> > > >>>
> > > >>> Ignite CPP:
> > > >>> * DML support
> > > >>> * Implemented LoadCache
> > > >>> * ContinuousQuery support
> > > >>>
> > > >>> Complete list of closed issues:
> > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20IGNITE%20AND%
> > > >>> 20fixVersion%20%3D%201.9%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/1.9.0-rc1
> > > >>>
> > > >>> RELEASENOTES
> > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc1
> > > >>>
> > > >>> Please start voting.
> > > >>>
> > > >>> +1 - to accept Apache Ignite 1.9.0-rc1
> > > >>> 0 - don't care either way
> > > >>> -1 - DO NOT accept Apache Ignite 1.9.0-rc1 (explain why)
> > > >>>
> > > >>> This vote will go for 72 hours.
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> С уважением,
> > > >> Чураев Антон
> > > >>
> > >
> > >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Kozlov Maxim]

Andrey, 

Please review PR again.

> 1 марта 2017 г., в 18:47, Andrey Gura  написал(а):
> 
> I think that it is ok.
> 
> On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim  wrote:
>> Ok. What do you say for the rest?
>> 
>>> 1 марта 2017 г., в 18:15, Andrey Gura  написал(а):
>>> 
>>> Maxim,
>>> 
>>> I think that during renaming we should not lose "Atomic" prefix.
>>> 
>>> 
>>> On Wed, Mar 1, 2017 at 5:16 PM, Kozlov Maxim  wrote:
 Andrey, ok.
 
 Also remove in the modules/platform/dotnet CacheAtomicWriteOrderMode.cs?
 
 Rename classes:
 
 GridCacheAtomicNearCacheSelfTest.startGrids -> 
 GridCacheAtomicNearCacheSelfTest.startGridsLocal (commit)
 IgniteCacheAtomicPrimaryWriteOrderWithStoreInvokeTest -> 
 IgniteCacheWithStoreInvokeTest
 IgniteCacheAtomicPrimaryWriteOrderInvokeTest -> IgniteCacheInvokeTest
 IgniteCacheAtomicPrimaryWriteOrderNearEnabledStoreValueTest -> 
 IgniteCacheNearEnabledStoreValueTest
 GridCacheAtomicPrimaryWriteOrderNearRemoveFailureTest -> 
 GridCacheNearRemoveFailureTest
 GridCacheAtomicPrimaryWriteOrderRemoveFailureTest -> 
 GridCacheRemoveFailureTest
 GridCacheAtomicPrimaryWriteOrderFailoverSelfTest -> 
 GridCacheFailoverSelfTest
 GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest -> 
 GridCacheValueConsistencyNearEnabledSelfTest
 CacheContinuousQueryAsyncFailoverAtomicPrimaryWriteOrderSelfTest -> 
 CacheContinuousQueryAsyncFailoverSelfTest
 CacheContinuousQueryFailoverAtomicPrimaryWriteOrderSelfTest -> 
 CacheContinuousQueryFailoverSelfTest
 GridCacheAtomicNearCacheSelfTest.testNoBackupsPrimaryWriteOrder -> 
 GridCacheAtomicNearCacheSelfTest.testNoBackups
 GridCacheAtomicNearCacheSelfTest.testWithBackupsPrimaryWriteOrder -> 
 GridCacheAtomicNearCacheSelfTest.testWithBackups
 
 Remove classes:
 
 IgniteCacheAtomicPrimaryWriteOrderStoreValueTest
 GridCacheReplicatedAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
 GridCacheAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
 GridCacheAtomicPrimaryWriteOrderMultiNodeP2PDisabledFullApiSelfTest
 GridCacheAtomicPrimaryWrityOrderOffHeapMultiNodeFullApiSelfTest
 GridCacheAtomicPrimaryWriteOrderOffHeapFullApiSelfTest
 GridCacheAtomicPrimaryWriteOrderFullApiSelfTest
 GridCacheAtomicPrimaryWriteOrderReloadAllSelfTest
 IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest
 GridCacheValueConsistencyAtomicPrimaryWriteOrderSelfTest
 IgniteCacheAtomicPrimaryWriteOrderExpiryPolicyTest
 
 ok? :)
 
> 1 марта 2017 г., в 2:04, Andrey Gura  написал(а):
> 
> No, it should be removed. If somebody use entry last update time (e.g.
> for conflict resolving) they should store this time as entry field.
> 
> On Wed, Mar 1, 2017 at 12:57 AM, Dmitriy Setrakyan
>  wrote:
>> Do we still need GridClockSyncProcessor?
>> 
>> On Tue, Feb 28, 2017 at 5:26 AM, Andrey Gura  wrote:
>> 
>>> Maxim,
>>> 
>>> Yes, this setting doesn't make sense anymore. So we need remove all
>>> related methods.
>>> 
>>> Also there is component called GridClockSyncProcessor that also should
>>> be removed. It will lead to removing globalTime field from
>>> GridCacheVersion class and some related methods.
>>> 
>>> On Tue, Feb 28, 2017 at 3:21 PM, Kozlov Maxim 
>>> wrote:
 Valentin,
 
 Then there is no need for setting 
 CacheConfiguration.atomicWriteOrderMode.
>>> What do you think, remove it and and related methods?
 
> 28 февр. 2017 г., в 2:49, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> написал(а):
> 
> Hi Max,
> 
> In case we remove the CLOCK mode, I think we should remove the enum
>>> too, as
> well as configuration properties and other code using this enum. 
> Having
> enum with one value doesn't make sense to me.
> 
> -Val
> 
> On Mon, Feb 27, 2017 at 5:09 AM, Kozlov Maxim 
>>> wrote:
> 
>> Hi Igniters,
>> 
>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now
>>> only
>> one value PRIMARY. Andrey Gura, proposition remove
>> CacheAtomicWriteOrderMode enum. Will there be something special for
>>> this
>> purpose is enum?
>> 
>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 <
>> https://issues.apache.org/jira/browse/IGNITE-4587>
>> 
>> --
>> Best Regards,
>> Max K.
>> 
>> 
>> 
>> 
>> 
 
 --
 Best Regards,
 Max K.
 
 
 
 
>>> 
 
 --
 Best Regards,
 Max K.
 
 
 
 
>> 
>> --
>> Best Regards,
>> Max K.
>> 
>> 
>> 
>> 

--
Best Regards,
Max K.

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

I checked it:

jdk8u121_x64 - *fine*
jdk8u91_x64 - *fail*

It is strange.

2017-03-02 11:53 GMT+03:00 Sergey Kozlov :

> I used Oracle JDK 1.8.0_91
>
> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur 
> wrote:
>
> > Denis, Sergey witch version of JDK8 do you use?
> >
> > I got this exception with the lates jdk-8u121.
> >
> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
> >
> > Look at "*New --allow-script-in-comments option for javadoc":*
> > http://www.oracle.com/technetwork/java/javase/8u121-
> relnotes-3315208.html
> >
> >
> >
> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov :
> >
> > > Hi
> > >
> > > I confirm the issue. Unfortunately it was introduced with latest
> commits
> > > after the run of full set of tests.
> > >
> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda  wrote:
> > >
> > > > Getting absolutely the same exception under JDK 8.
> > > >
> > > > —
> > > > Denis
> > > >
> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > -1
> > > > >
> > > > > Building with 'mvn clean package -DskipTests' under JDK8 fails with
> > the
> > > > > error below. JDK7 is fine, though.
> > > > >
> > > > > [INFO] --
> --
> > > > > 
> > > > > [INFO] BUILD FAILURE
> > > > > [INFO] --
> --
> > > > > 
> > > > > [INFO] Total time: 12.626 s
> > > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
> > > > > [INFO] Final Memory: 80M/654M
> > > > > [INFO] --
> --
> > > > > 
> > > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
> > > > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project
> > > > ignite-tools:
> > > > > MavenReportException: Error while creating archive:
> > > > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
> > > > > --allow-script-in-comments
> > > > > [ERROR]
> > > > > [ERROR] Command line was: /Library/Java/
> > JavaVirtualMachines/jdk1.8.0_
> > > > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> > > > > [ERROR]
> > > > > [ERROR] Refer to the generated Javadoc files in
> > > > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
> > > > modules/tools/target/apidocs'
> > > > > dir.
> > > > > [ERROR] -> [Help 1]
> > > > >
> > > > > -Val
> > > > >
> > > > > On Tue, Feb 28, 2017 at 11:51 PM, Антон Чураев <
> churaev...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > >> +1
> > > > >>
> > > > >> 2017-03-01 10:28 GMT+03:00 Anton Vinogradov :
> > > > >>
> > > > >>> Dear Sirs!
> > > > >>>
> > > > >>> We have uploaded the 1.9.0 release candidate to
> > > > >>> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
> > > > >>>
> > > > >>> Git tag name is
> > > > >>> 1.9.0-rc1
> > > > >>>
> > > > >>> This release includes the following changes:
> > > > >>>
> > > > >>> Ignite:
> > > > >>> * Added Data streamer mode for DML
> > > > >>> * Added Discovery SPI Implementation for Ignite Kubernetes Pods
> > > > >>> * SQL: Query can utilize multiple threads
> > > > >>> * SQL: Improved distributed SQL support
> > > > >>> * Benchmarking simplified and automated
> > > > >>> * Fixed licenses generation during build
> > > > >>> * ignite-spark module upgraded to Spark 2.0
> > > > >>>
> > > > >>> Ignite.NET:
> > > > >>> * DML support
> > > > >>> * TransactionScope API for Ignite transactions support
> > > > >>>
> > > > >>> Ignite CPP:
> > > > >>> * DML support
> > > > >>> * Implemented LoadCache
> > > > >>> * ContinuousQuery support
> > > > >>>
> > > > >>> Complete list of closed issues:
> > > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20IGNITE%20AND%
> > > > >>> 20fixVersion%20%3D%201.9%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/1.9.0-rc1
> > > > >>>
> > > > >>> RELEASENOTES
> > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc1
> > > > >>>
> > > > >>> Please start voting.
> > > > >>>
> > > > >>> +1 - to accept Apache Ignite 1.9.0-rc1
> > > > >>> 0 - don't care either way
> > > > >>> -1 - DO NOT accept Apache Ignite 1.9.0-rc1 (explain why)
> > > > >>>
> > > > >>> This vote will go for 72 hours.
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> С уважением,
> > > > >> Чураев Антон
> > > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Kozlov Maxim]

Andrey, 

When removed parameter globalTime, in method:

public IgniteUuid asGridUuid() {
return new IgniteUuid(new UUID(((long)topVer << 32) | nodeOrderDrId, 
globalTime), order);
}

globalTime parameter replaced by something or remove this method?


> 2 марта 2017 г., в 12:07, Kozlov Maxim  написал(а):
> 
> Andrey, 
> 
> Please review PR again.
> 
>> 1 марта 2017 г., в 18:47, Andrey Gura  написал(а):
>> 
>> I think that it is ok.
>> 
>> On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim  wrote:
>>> Ok. What do you say for the rest?
>>> 
 1 марта 2017 г., в 18:15, Andrey Gura  написал(а):
 
 Maxim,
 
 I think that during renaming we should not lose "Atomic" prefix.
 
 
 On Wed, Mar 1, 2017 at 5:16 PM, Kozlov Maxim  wrote:
> Andrey, ok.
> 
> Also remove in the modules/platform/dotnet CacheAtomicWriteOrderMode.cs?
> 
> Rename classes:
> 
> GridCacheAtomicNearCacheSelfTest.startGrids -> 
> GridCacheAtomicNearCacheSelfTest.startGridsLocal (commit)
> IgniteCacheAtomicPrimaryWriteOrderWithStoreInvokeTest -> 
> IgniteCacheWithStoreInvokeTest
> IgniteCacheAtomicPrimaryWriteOrderInvokeTest -> IgniteCacheInvokeTest
> IgniteCacheAtomicPrimaryWriteOrderNearEnabledStoreValueTest -> 
> IgniteCacheNearEnabledStoreValueTest
> GridCacheAtomicPrimaryWriteOrderNearRemoveFailureTest -> 
> GridCacheNearRemoveFailureTest
> GridCacheAtomicPrimaryWriteOrderRemoveFailureTest -> 
> GridCacheRemoveFailureTest
> GridCacheAtomicPrimaryWriteOrderFailoverSelfTest -> 
> GridCacheFailoverSelfTest
> GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest -> 
> GridCacheValueConsistencyNearEnabledSelfTest
> CacheContinuousQueryAsyncFailoverAtomicPrimaryWriteOrderSelfTest -> 
> CacheContinuousQueryAsyncFailoverSelfTest
> CacheContinuousQueryFailoverAtomicPrimaryWriteOrderSelfTest -> 
> CacheContinuousQueryFailoverSelfTest
> GridCacheAtomicNearCacheSelfTest.testNoBackupsPrimaryWriteOrder -> 
> GridCacheAtomicNearCacheSelfTest.testNoBackups
> GridCacheAtomicNearCacheSelfTest.testWithBackupsPrimaryWriteOrder -> 
> GridCacheAtomicNearCacheSelfTest.testWithBackups
> 
> Remove classes:
> 
> IgniteCacheAtomicPrimaryWriteOrderStoreValueTest
> GridCacheReplicatedAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
> GridCacheAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
> GridCacheAtomicPrimaryWriteOrderMultiNodeP2PDisabledFullApiSelfTest
> GridCacheAtomicPrimaryWrityOrderOffHeapMultiNodeFullApiSelfTest
> GridCacheAtomicPrimaryWriteOrderOffHeapFullApiSelfTest
> GridCacheAtomicPrimaryWriteOrderFullApiSelfTest
> GridCacheAtomicPrimaryWriteOrderReloadAllSelfTest
> IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest
> GridCacheValueConsistencyAtomicPrimaryWriteOrderSelfTest
> IgniteCacheAtomicPrimaryWriteOrderExpiryPolicyTest
> 
> ok? :)
> 
>> 1 марта 2017 г., в 2:04, Andrey Gura  написал(а):
>> 
>> No, it should be removed. If somebody use entry last update time (e.g.
>> for conflict resolving) they should store this time as entry field.
>> 
>> On Wed, Mar 1, 2017 at 12:57 AM, Dmitriy Setrakyan
>>  wrote:
>>> Do we still need GridClockSyncProcessor?
>>> 
>>> On Tue, Feb 28, 2017 at 5:26 AM, Andrey Gura  wrote:
>>> 
 Maxim,
 
 Yes, this setting doesn't make sense anymore. So we need remove all
 related methods.
 
 Also there is component called GridClockSyncProcessor that also should
 be removed. It will lead to removing globalTime field from
 GridCacheVersion class and some related methods.
 
 On Tue, Feb 28, 2017 at 3:21 PM, Kozlov Maxim 
 wrote:
> Valentin,
> 
> Then there is no need for setting 
> CacheConfiguration.atomicWriteOrderMode.
 What do you think, remove it and and related methods?
> 
>> 28 февр. 2017 г., в 2:49, Valentin Kulichenko <
 valentin.kuliche...@gmail.com> написал(а):
>> 
>> Hi Max,
>> 
>> In case we remove the CLOCK mode, I think we should remove the enum
 too, as
>> well as configuration properties and other code using this enum. 
>> Having
>> enum with one value doesn't make sense to me.
>> 
>> -Val
>> 
>> On Mon, Feb 27, 2017 at 5:09 AM, Kozlov Maxim 
 wrote:
>> 
>>> Hi Igniters,
>>> 
>>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now
 only
>>> one value PRIMARY. Andrey Gura, proposition remove
>>> CacheAtomicWriteOrderMode enum. Will there be something special for
 this
>>> purpose is enum?
>>> 
>>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 <
>>> https://issues.apache.org/jira/browse

code refactoring suggestion

[ALEKSEY KUZNETSOV]

Hi all ! During pessimistic transaction we execute prepare phase at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#commitAsync
after executing prepareAsync();
We bind listener on prepare future.
Perhaps its better initially bind listener and then execute fut.prepare(); ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

Guys, I found that.

apache-ignite-1.9.0-src\parent\pom.xml

line: 940

We need to remove flag "--allow-script-in-comments",
it is new, and not capability with version less than jdk8u121_x64

I can create PR with fix, or you can just fix it yourself.

2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur :

> I checked it:
>
> jdk8u121_x64 - *fine*
> jdk8u91_x64 - *fail*
>
> It is strange.
>
> 2017-03-02 11:53 GMT+03:00 Sergey Kozlov :
>
>> I used Oracle JDK 1.8.0_91
>>
>> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur 
>> wrote:
>>
>> > Denis, Sergey witch version of JDK8 do you use?
>> >
>> > I got this exception with the lates jdk-8u121.
>> >
>> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
>> >
>> > Look at "*New --allow-script-in-comments option for javadoc":*
>> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
>> -3315208.html
>> >
>> >
>> >
>> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov :
>> >
>> > > Hi
>> > >
>> > > I confirm the issue. Unfortunately it was introduced with latest
>> commits
>> > > after the run of full set of tests.
>> > >
>> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda 
>> wrote:
>> > >
>> > > > Getting absolutely the same exception under JDK 8.
>> > > >
>> > > > —
>> > > > Denis
>> > > >
>> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
>> > > > valentin.kuliche...@gmail.com> wrote:
>> > > > >
>> > > > > -1
>> > > > >
>> > > > > Building with 'mvn clean package -DskipTests' under JDK8 fails
>> with
>> > the
>> > > > > error below. JDK7 is fine, though.
>> > > > >
>> > > > > [INFO] --
>> --
>> > > > > 
>> > > > > [INFO] BUILD FAILURE
>> > > > > [INFO] --
>> --
>> > > > > 
>> > > > > [INFO] Total time: 12.626 s
>> > > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
>> > > > > [INFO] Final Memory: 80M/654M
>> > > > > [INFO] --
>> --
>> > > > > 
>> > > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
>> > > > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project
>> > > > ignite-tools:
>> > > > > MavenReportException: Error while creating archive:
>> > > > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
>> > > > > --allow-script-in-comments
>> > > > > [ERROR]
>> > > > > [ERROR] Command line was: /Library/Java/
>> > JavaVirtualMachines/jdk1.8.0_
>> > > > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
>> > > > > [ERROR]
>> > > > > [ERROR] Refer to the generated Javadoc files in
>> > > > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
>> > > > modules/tools/target/apidocs'
>> > > > > dir.
>> > > > > [ERROR] -> [Help 1]
>> > > > >
>> > > > > -Val
>> > > > >
>> > > > > On Tue, Feb 28, 2017 at 11:51 PM, Антон Чураев <
>> churaev...@gmail.com
>> > >
>> > > > wrote:
>> > > > >
>> > > > >> +1
>> > > > >>
>> > > > >> 2017-03-01 10:28 GMT+03:00 Anton Vinogradov :
>> > > > >>
>> > > > >>> Dear Sirs!
>> > > > >>>
>> > > > >>> We have uploaded the 1.9.0 release candidate to
>> > > > >>> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
>> > > > >>>
>> > > > >>> Git tag name is
>> > > > >>> 1.9.0-rc1
>> > > > >>>
>> > > > >>> This release includes the following changes:
>> > > > >>>
>> > > > >>> Ignite:
>> > > > >>> * Added Data streamer mode for DML
>> > > > >>> * Added Discovery SPI Implementation for Ignite Kubernetes Pods
>> > > > >>> * SQL: Query can utilize multiple threads
>> > > > >>> * SQL: Improved distributed SQL support
>> > > > >>> * Benchmarking simplified and automated
>> > > > >>> * Fixed licenses generation during build
>> > > > >>> * ignite-spark module upgraded to Spark 2.0
>> > > > >>>
>> > > > >>> Ignite.NET:
>> > > > >>> * DML support
>> > > > >>> * TransactionScope API for Ignite transactions support
>> > > > >>>
>> > > > >>> Ignite CPP:
>> > > > >>> * DML support
>> > > > >>> * Implemented LoadCache
>> > > > >>> * ContinuousQuery support
>> > > > >>>
>> > > > >>> Complete list of closed issues:
>> > > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
>> > > > 3D%20IGNITE%20AND%
>> > > > >>> 20fixVersion%20%3D%201.9%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/1.9.0-rc1
>> > > > >>>
>> > > > >>> RELEASENOTES
>> > > > >>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
>> > > > >>> plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc1
>> > > > >>>
>> > > > >>> Please start voting.
>> > > > >>>
>> > > > >>> +1 - to accept Apache Ignite 1.9.0-rc1
>> > > > >>> 0 - don't care either way
>> > > > >>> -1 - DO NOT accept Apache Ignite 1.9.0-rc1 (explain why)
>> > > > >>>
>> > > > >>> This vote will go for 72 hours.
>> > > > >>>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> --
>> > >

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

Folks,
Right before vote I faced with compilation error at 1.8.0_121-b13, that's
why this flag was added.

Vyacheslav,
at first message you told
>> I got this exception with the lates jdk-8u121.

at next one
>> jdk8u121_x64 - *fine*
>> jdk8u91_x64 - *fail*

Which one is true?

I have no compilation errors at latest 1.8.0_121-b13

Anyways, I'm looking for better solution.

On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur 
wrote:

> Guys, I found that.
>
> apache-ignite-1.9.0-src\parent\pom.xml
>
> line: 940
>
> We need to remove flag "--allow-script-in-comments",
> it is new, and not capability with version less than jdk8u121_x64
>
> I can create PR with fix, or you can just fix it yourself.
>
> 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur :
>
> > I checked it:
> >
> > jdk8u121_x64 - *fine*
> > jdk8u91_x64 - *fail*
> >
> > It is strange.
> >
> > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov :
> >
> >> I used Oracle JDK 1.8.0_91
> >>
> >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
> daradu...@gmail.com>
> >> wrote:
> >>
> >> > Denis, Sergey witch version of JDK8 do you use?
> >> >
> >> > I got this exception with the lates jdk-8u121.
> >> >
> >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
> >> >
> >> > Look at "*New --allow-script-in-comments option for javadoc":*
> >> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
> >> -3315208.html
> >> >
> >> >
> >> >
> >> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov :
> >> >
> >> > > Hi
> >> > >
> >> > > I confirm the issue. Unfortunately it was introduced with latest
> >> commits
> >> > > after the run of full set of tests.
> >> > >
> >> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda 
> >> wrote:
> >> > >
> >> > > > Getting absolutely the same exception under JDK 8.
> >> > > >
> >> > > > —
> >> > > > Denis
> >> > > >
> >> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
> >> > > > valentin.kuliche...@gmail.com> wrote:
> >> > > > >
> >> > > > > -1
> >> > > > >
> >> > > > > Building with 'mvn clean package -DskipTests' under JDK8 fails
> >> with
> >> > the
> >> > > > > error below. JDK7 is fine, though.
> >> > > > >
> >> > > > > [INFO] --
> >> --
> >> > > > > 
> >> > > > > [INFO] BUILD FAILURE
> >> > > > > [INFO] --
> >> --
> >> > > > > 
> >> > > > > [INFO] Total time: 12.626 s
> >> > > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
> >> > > > > [INFO] Final Memory: 80M/654M
> >> > > > > [INFO] --
> >> --
> >> > > > > 
> >> > > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
> >> > > > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project
> >> > > > ignite-tools:
> >> > > > > MavenReportException: Error while creating archive:
> >> > > > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
> >> > > > > --allow-script-in-comments
> >> > > > > [ERROR]
> >> > > > > [ERROR] Command line was: /Library/Java/
> >> > JavaVirtualMachines/jdk1.8.0_
> >> > > > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> >> > > > > [ERROR]
> >> > > > > [ERROR] Refer to the generated Javadoc files in
> >> > > > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
> >> > > > modules/tools/target/apidocs'
> >> > > > > dir.
> >> > > > > [ERROR] -> [Help 1]
> >> > > > >
> >> > > > > -Val
> >> > > > >
> >> > > > > On Tue, Feb 28, 2017 at 11:51 PM, Антон Чураев <
> >> churaev...@gmail.com
> >> > >
> >> > > > wrote:
> >> > > > >
> >> > > > >> +1
> >> > > > >>
> >> > > > >> 2017-03-01 10:28 GMT+03:00 Anton Vinogradov :
> >> > > > >>
> >> > > > >>> Dear Sirs!
> >> > > > >>>
> >> > > > >>> We have uploaded the 1.9.0 release candidate to
> >> > > > >>> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
> >> > > > >>>
> >> > > > >>> Git tag name is
> >> > > > >>> 1.9.0-rc1
> >> > > > >>>
> >> > > > >>> This release includes the following changes:
> >> > > > >>>
> >> > > > >>> Ignite:
> >> > > > >>> * Added Data streamer mode for DML
> >> > > > >>> * Added Discovery SPI Implementation for Ignite Kubernetes
> Pods
> >> > > > >>> * SQL: Query can utilize multiple threads
> >> > > > >>> * SQL: Improved distributed SQL support
> >> > > > >>> * Benchmarking simplified and automated
> >> > > > >>> * Fixed licenses generation during build
> >> > > > >>> * ignite-spark module upgraded to Spark 2.0
> >> > > > >>>
> >> > > > >>> Ignite.NET:
> >> > > > >>> * DML support
> >> > > > >>> * TransactionScope API for Ignite transactions support
> >> > > > >>>
> >> > > > >>> Ignite CPP:
> >> > > > >>> * DML support
> >> > > > >>> * Implemented LoadCache
> >> > > > >>> * ContinuousQuery support
> >> > > > >>>
> >> > > > >>> Complete list of closed issues:
> >> > > > >>> https://issues.apache.org/jira/issues/?jql=project%20%
> >> > > > 3D%20IGNITE%20AND%
> >> > > > >>> 20fixVersion%20%3D%201.9%20AND%20(status%20%3D%
> >> > > > >

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

>> I got this exception with the lates jdk-8u121.
I had this problem earlier, not with RC.
Sorry for misleading

>> Which one is true?

This one true for https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1:
jdk8u121_x64 - *fine*
jdk8u91_x64 - *fail





2017-03-02 12:46 GMT+03:00 Anton Vinogradov :

> Folks,
> Right before vote I faced with compilation error at 1.8.0_121-b13, that's
> why this flag was added.
>
> Vyacheslav,
> at first message you told
> >> I got this exception with the lates jdk-8u121.
>
> at next one
> >> jdk8u121_x64 - *fine*
> >> jdk8u91_x64 - *fail*
>
> Which one is true?
>
> I have no compilation errors at latest 1.8.0_121-b13
>
> Anyways, I'm looking for better solution.
>
> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur 
> wrote:
>
> > Guys, I found that.
> >
> > apache-ignite-1.9.0-src\parent\pom.xml
> >
> > line: 940
> >
> > We need to remove flag "--allow-script-in-comments",
> > it is new, and not capability with version less than jdk8u121_x64
> >
> > I can create PR with fix, or you can just fix it yourself.
> >
> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur :
> >
> > > I checked it:
> > >
> > > jdk8u121_x64 - *fine*
> > > jdk8u91_x64 - *fail*
> > >
> > > It is strange.
> > >
> > > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov :
> > >
> > >> I used Oracle JDK 1.8.0_91
> > >>
> > >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
> > daradu...@gmail.com>
> > >> wrote:
> > >>
> > >> > Denis, Sergey witch version of JDK8 do you use?
> > >> >
> > >> > I got this exception with the lates jdk-8u121.
> > >> >
> > >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
> > >> >
> > >> > Look at "*New --allow-script-in-comments option for javadoc":*
> > >> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
> > >> -3315208.html
> > >> >
> > >> >
> > >> >
> > >> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov :
> > >> >
> > >> > > Hi
> > >> > >
> > >> > > I confirm the issue. Unfortunately it was introduced with latest
> > >> commits
> > >> > > after the run of full set of tests.
> > >> > >
> > >> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda 
> > >> wrote:
> > >> > >
> > >> > > > Getting absolutely the same exception under JDK 8.
> > >> > > >
> > >> > > > —
> > >> > > > Denis
> > >> > > >
> > >> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
> > >> > > > valentin.kuliche...@gmail.com> wrote:
> > >> > > > >
> > >> > > > > -1
> > >> > > > >
> > >> > > > > Building with 'mvn clean package -DskipTests' under JDK8 fails
> > >> with
> > >> > the
> > >> > > > > error below. JDK7 is fine, though.
> > >> > > > >
> > >> > > > > [INFO] --
> > >> --
> > >> > > > > 
> > >> > > > > [INFO] BUILD FAILURE
> > >> > > > > [INFO] --
> > >> --
> > >> > > > > 
> > >> > > > > [INFO] Total time: 12.626 s
> > >> > > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
> > >> > > > > [INFO] Final Memory: 80M/654M
> > >> > > > > [INFO] --
> > >> --
> > >> > > > > 
> > >> > > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
> > >> > > > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project
> > >> > > > ignite-tools:
> > >> > > > > MavenReportException: Error while creating archive:
> > >> > > > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
> > >> > > > > --allow-script-in-comments
> > >> > > > > [ERROR]
> > >> > > > > [ERROR] Command line was: /Library/Java/
> > >> > JavaVirtualMachines/jdk1.8.0_
> > >> > > > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> > >> > > > > [ERROR]
> > >> > > > > [ERROR] Refer to the generated Javadoc files in
> > >> > > > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
> > >> > > > modules/tools/target/apidocs'
> > >> > > > > dir.
> > >> > > > > [ERROR] -> [Help 1]
> > >> > > > >
> > >> > > > > -Val
> > >> > > > >
> > >> > > > > On Tue, Feb 28, 2017 at 11:51 PM, Антон Чураев <
> > >> churaev...@gmail.com
> > >> > >
> > >> > > > wrote:
> > >> > > > >
> > >> > > > >> +1
> > >> > > > >>
> > >> > > > >> 2017-03-01 10:28 GMT+03:00 Anton Vinogradov :
> > >> > > > >>
> > >> > > > >>> Dear Sirs!
> > >> > > > >>>
> > >> > > > >>> We have uploaded the 1.9.0 release candidate to
> > >> > > > >>> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
> > >> > > > >>>
> > >> > > > >>> Git tag name is
> > >> > > > >>> 1.9.0-rc1
> > >> > > > >>>
> > >> > > > >>> This release includes the following changes:
> > >> > > > >>>
> > >> > > > >>> Ignite:
> > >> > > > >>> * Added Data streamer mode for DML
> > >> > > > >>> * Added Discovery SPI Implementation for Ignite Kubernetes
> > Pods
> > >> > > > >>> * SQL: Query can utilize multiple threads
> > >> > > > >>> * SQL: Improved distributed SQL support
> > >> > > > >>> * Benchmarking simplified and automated
> > >> > > > >>> * Fixed licenses generation during buil

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

>> Which one is true?

This one true for https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1:
jdk8u121_x64 - *fine*
jdk8u91_x64 - *fail

2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur :

> >> I got this exception with the lates jdk-8u121.
> I had this problem earlier, not with RC.
> Sorry for misleading
>
> >> Which one is true?
>
> This one true for https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1:
> jdk8u121_x64 - *fine*
> jdk8u91_x64 - *fail
>
>
>
>
>
> 2017-03-02 12:46 GMT+03:00 Anton Vinogradov :
>
>> Folks,
>> Right before vote I faced with compilation error at 1.8.0_121-b13, that's
>> why this flag was added.
>>
>> Vyacheslav,
>> at first message you told
>> >> I got this exception with the lates jdk-8u121.
>>
>> at next one
>> >> jdk8u121_x64 - *fine*
>> >> jdk8u91_x64 - *fail*
>>
>> Which one is true?
>>
>> I have no compilation errors at latest 1.8.0_121-b13
>>
>> Anyways, I'm looking for better solution.
>>
>> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur 
>> wrote:
>>
>> > Guys, I found that.
>> >
>> > apache-ignite-1.9.0-src\parent\pom.xml
>> >
>> > line: 940
>> >
>> > We need to remove flag "--allow-script-in-comments",
>> > it is new, and not capability with version less than jdk8u121_x64
>> >
>> > I can create PR with fix, or you can just fix it yourself.
>> >
>> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur :
>> >
>> > > I checked it:
>> > >
>> > > jdk8u121_x64 - *fine*
>> > > jdk8u91_x64 - *fail*
>> > >
>> > > It is strange.
>> > >
>> > > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov :
>> > >
>> > >> I used Oracle JDK 1.8.0_91
>> > >>
>> > >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
>> > daradu...@gmail.com>
>> > >> wrote:
>> > >>
>> > >> > Denis, Sergey witch version of JDK8 do you use?
>> > >> >
>> > >> > I got this exception with the lates jdk-8u121.
>> > >> >
>> > >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
>> > >> >
>> > >> > Look at "*New --allow-script-in-comments option for javadoc":*
>> > >> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
>> > >> -3315208.html
>> > >> >
>> > >> >
>> > >> >
>> > >> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov :
>> > >> >
>> > >> > > Hi
>> > >> > >
>> > >> > > I confirm the issue. Unfortunately it was introduced with latest
>> > >> commits
>> > >> > > after the run of full set of tests.
>> > >> > >
>> > >> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda 
>> > >> wrote:
>> > >> > >
>> > >> > > > Getting absolutely the same exception under JDK 8.
>> > >> > > >
>> > >> > > > —
>> > >> > > > Denis
>> > >> > > >
>> > >> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
>> > >> > > > valentin.kuliche...@gmail.com> wrote:
>> > >> > > > >
>> > >> > > > > -1
>> > >> > > > >
>> > >> > > > > Building with 'mvn clean package -DskipTests' under JDK8
>> fails
>> > >> with
>> > >> > the
>> > >> > > > > error below. JDK7 is fine, though.
>> > >> > > > >
>> > >> > > > > [INFO] --
>> > >> --
>> > >> > > > > 
>> > >> > > > > [INFO] BUILD FAILURE
>> > >> > > > > [INFO] --
>> > >> --
>> > >> > > > > 
>> > >> > > > > [INFO] Total time: 12.626 s
>> > >> > > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
>> > >> > > > > [INFO] Final Memory: 80M/654M
>> > >> > > > > [INFO] --
>> > >> --
>> > >> > > > > 
>> > >> > > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
>> > >> > > > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project
>> > >> > > > ignite-tools:
>> > >> > > > > MavenReportException: Error while creating archive:
>> > >> > > > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
>> > >> > > > > --allow-script-in-comments
>> > >> > > > > [ERROR]
>> > >> > > > > [ERROR] Command line was: /Library/Java/
>> > >> > JavaVirtualMachines/jdk1.8.0_
>> > >> > > > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
>> > >> > > > > [ERROR]
>> > >> > > > > [ERROR] Refer to the generated Javadoc files in
>> > >> > > > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
>> > >> > > > modules/tools/target/apidocs'
>> > >> > > > > dir.
>> > >> > > > > [ERROR] -> [Help 1]
>> > >> > > > >
>> > >> > > > > -Val
>> > >> > > > >
>> > >> > > > > On Tue, Feb 28, 2017 at 11:51 PM, Антон Чураев <
>> > >> churaev...@gmail.com
>> > >> > >
>> > >> > > > wrote:
>> > >> > > > >
>> > >> > > > >> +1
>> > >> > > > >>
>> > >> > > > >> 2017-03-01 10:28 GMT+03:00 Anton Vinogradov > >:
>> > >> > > > >>
>> > >> > > > >>> Dear Sirs!
>> > >> > > > >>>
>> > >> > > > >>> We have uploaded the 1.9.0 release candidate to
>> > >> > > > >>> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1/
>> > >> > > > >>>
>> > >> > > > >>> Git tag name is
>> > >> > > > >>> 1.9.0-rc1
>> > >> > > > >>>
>> > >> > > > >>> This release includes the following changes:
>> > >> > > > >>>
>> > >> > > > >>> Ignite:
>> > >>

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

Vyacheslav,

Do you have Ideas why we got
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar (module-javadoc)
on project ignite-tools: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains
JavaScript.
[ERROR] Use --allow-script-in-comments to allow use of JavaScript.

at 1.8.0_121-b13 without --allow-script-in-comments flag?

On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur 
wrote:

> >> Which one is true?
>
> This one true for https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1:
> jdk8u121_x64 - *fine*
> jdk8u91_x64 - *fail
>
> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur :
>
> > >> I got this exception with the lates jdk-8u121.
> > I had this problem earlier, not with RC.
> > Sorry for misleading
> >
> > >> Which one is true?
> >
> > This one true for https://dist.apache.org/repos/
> dist/dev/ignite/1.9.0-rc1:
> > jdk8u121_x64 - *fine*
> > jdk8u91_x64 - *fail
> >
> >
> >
> >
> >
> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov :
> >
> >> Folks,
> >> Right before vote I faced with compilation error at 1.8.0_121-b13,
> that's
> >> why this flag was added.
> >>
> >> Vyacheslav,
> >> at first message you told
> >> >> I got this exception with the lates jdk-8u121.
> >>
> >> at next one
> >> >> jdk8u121_x64 - *fine*
> >> >> jdk8u91_x64 - *fail*
> >>
> >> Which one is true?
> >>
> >> I have no compilation errors at latest 1.8.0_121-b13
> >>
> >> Anyways, I'm looking for better solution.
> >>
> >> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur <
> daradu...@gmail.com>
> >> wrote:
> >>
> >> > Guys, I found that.
> >> >
> >> > apache-ignite-1.9.0-src\parent\pom.xml
> >> >
> >> > line: 940
> >> >
> >> > We need to remove flag "--allow-script-in-comments",
> >> > it is new, and not capability with version less than jdk8u121_x64
> >> >
> >> > I can create PR with fix, or you can just fix it yourself.
> >> >
> >> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur :
> >> >
> >> > > I checked it:
> >> > >
> >> > > jdk8u121_x64 - *fine*
> >> > > jdk8u91_x64 - *fail*
> >> > >
> >> > > It is strange.
> >> > >
> >> > > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov :
> >> > >
> >> > >> I used Oracle JDK 1.8.0_91
> >> > >>
> >> > >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
> >> > daradu...@gmail.com>
> >> > >> wrote:
> >> > >>
> >> > >> > Denis, Sergey witch version of JDK8 do you use?
> >> > >> >
> >> > >> > I got this exception with the lates jdk-8u121.
> >> > >> >
> >> > >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
> >> > >> >
> >> > >> > Look at "*New --allow-script-in-comments option for javadoc":*
> >> > >> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
> >> > >> -3315208.html
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov :
> >> > >> >
> >> > >> > > Hi
> >> > >> > >
> >> > >> > > I confirm the issue. Unfortunately it was introduced with
> latest
> >> > >> commits
> >> > >> > > after the run of full set of tests.
> >> > >> > >
> >> > >> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda  >
> >> > >> wrote:
> >> > >> > >
> >> > >> > > > Getting absolutely the same exception under JDK 8.
> >> > >> > > >
> >> > >> > > > —
> >> > >> > > > Denis
> >> > >> > > >
> >> > >> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
> >> > >> > > > valentin.kuliche...@gmail.com> wrote:
> >> > >> > > > >
> >> > >> > > > > -1
> >> > >> > > > >
> >> > >> > > > > Building with 'mvn clean package -DskipTests' under JDK8
> >> fails
> >> > >> with
> >> > >> > the
> >> > >> > > > > error below. JDK7 is fine, though.
> >> > >> > > > >
> >> > >> > > > > [INFO] --
> >> > >> --
> >> > >> > > > > 
> >> > >> > > > > [INFO] BUILD FAILURE
> >> > >> > > > > [INFO] --
> >> > >> --
> >> > >> > > > > 
> >> > >> > > > > [INFO] Total time: 12.626 s
> >> > >> > > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
> >> > >> > > > > [INFO] Final Memory: 80M/654M
> >> > >> > > > > [INFO] --
> >> > >> --
> >> > >> > > > > 
> >> > >> > > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
> >> > >> > > > > maven-javadoc-plugin:2.10.1:jar (module-javadoc) on
> project
> >> > >> > > > ignite-tools:
> >> > >> > > > > MavenReportException: Error while creating archive:
> >> > >> > > > > [ERROR] Exit code: 1 - javadoc: error - invalid flag:
> >> > >> > > > > --allow-script-in-comments
> >> > >> > > > > [ERROR]
> >> > >> > > > > [ERROR] Command line was: /Library/Java/
> >> > >> > JavaVirtualMachines/jdk1.8.0_
> >> > >> > > > > 92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
> >> > >> > > > > [ERROR]
> >> > >> > > > > [ERROR] Refer to the generated Javadoc files in
> >> > >> > > > > '/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/
> >> > >> > > >

[GitHub] ignite pull request #1536: IGNITE-4577 Add sort for virtual interface addres...

[ezhuravl]

Github user ezhuravl closed the pull request at:

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


---
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: [VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

I found the reason,

Thats because of  tag content at parent/pom.xml:455
It contains
!function(d,s,id){var
js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);
js.id=id;js.src=p+'://
platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document,
'script', 'twitter-wjs');

Do we really need it?

On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov 
wrote:

> Vyacheslav,
>
> Do you have Ideas why we got
> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project ignite-tools:
> MavenReportException: Error while creating archive:
> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains
> JavaScript.
> [ERROR] Use --allow-script-in-comments to allow use of JavaScript.
>
> at 1.8.0_121-b13 without --allow-script-in-comments flag?
>
> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur 
> wrote:
>
>> >> Which one is true?
>>
>> This one true for https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc1
>> :
>> jdk8u121_x64 - *fine*
>> jdk8u91_x64 - *fail
>>
>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur :
>>
>> > >> I got this exception with the lates jdk-8u121.
>> > I had this problem earlier, not with RC.
>> > Sorry for misleading
>> >
>> > >> Which one is true?
>> >
>> > This one true for https://dist.apache.org/repos/
>> dist/dev/ignite/1.9.0-rc1:
>> > jdk8u121_x64 - *fine*
>> > jdk8u91_x64 - *fail
>> >
>> >
>> >
>> >
>> >
>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov :
>> >
>> >> Folks,
>> >> Right before vote I faced with compilation error at 1.8.0_121-b13,
>> that's
>> >> why this flag was added.
>> >>
>> >> Vyacheslav,
>> >> at first message you told
>> >> >> I got this exception with the lates jdk-8u121.
>> >>
>> >> at next one
>> >> >> jdk8u121_x64 - *fine*
>> >> >> jdk8u91_x64 - *fail*
>> >>
>> >> Which one is true?
>> >>
>> >> I have no compilation errors at latest 1.8.0_121-b13
>> >>
>> >> Anyways, I'm looking for better solution.
>> >>
>> >> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur <
>> daradu...@gmail.com>
>> >> wrote:
>> >>
>> >> > Guys, I found that.
>> >> >
>> >> > apache-ignite-1.9.0-src\parent\pom.xml
>> >> >
>> >> > line: 940
>> >> >
>> >> > We need to remove flag "--allow-script-in-comments",
>> >> > it is new, and not capability with version less than jdk8u121_x64
>> >> >
>> >> > I can create PR with fix, or you can just fix it yourself.
>> >> >
>> >> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur :
>> >> >
>> >> > > I checked it:
>> >> > >
>> >> > > jdk8u121_x64 - *fine*
>> >> > > jdk8u91_x64 - *fail*
>> >> > >
>> >> > > It is strange.
>> >> > >
>> >> > > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov :
>> >> > >
>> >> > >> I used Oracle JDK 1.8.0_91
>> >> > >>
>> >> > >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
>> >> > daradu...@gmail.com>
>> >> > >> wrote:
>> >> > >>
>> >> > >> > Denis, Sergey witch version of JDK8 do you use?
>> >> > >> >
>> >> > >> > I got this exception with the lates jdk-8u121.
>> >> > >> >
>> >> > >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
>> >> > >> >
>> >> > >> > Look at "*New --allow-script-in-comments option for javadoc":*
>> >> > >> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
>> >> > >> -3315208.html
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov > >:
>> >> > >> >
>> >> > >> > > Hi
>> >> > >> > >
>> >> > >> > > I confirm the issue. Unfortunately it was introduced with
>> latest
>> >> > >> commits
>> >> > >> > > after the run of full set of tests.
>> >> > >> > >
>> >> > >> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda <
>> dma...@apache.org>
>> >> > >> wrote:
>> >> > >> > >
>> >> > >> > > > Getting absolutely the same exception under JDK 8.
>> >> > >> > > >
>> >> > >> > > > —
>> >> > >> > > > Denis
>> >> > >> > > >
>> >> > >> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
>> >> > >> > > > valentin.kuliche...@gmail.com> wrote:
>> >> > >> > > > >
>> >> > >> > > > > -1
>> >> > >> > > > >
>> >> > >> > > > > Building with 'mvn clean package -DskipTests' under JDK8
>> >> fails
>> >> > >> with
>> >> > >> > the
>> >> > >> > > > > error below. JDK7 is fine, though.
>> >> > >> > > > >
>> >> > >> > > > > [INFO] --
>> >> > >> --
>> >> > >> > > > > 
>> >> > >> > > > > [INFO] BUILD FAILURE
>> >> > >> > > > > [INFO] --
>> >> > >> --
>> >> > >> > > > > 
>> >> > >> > > > > [INFO] Total time: 12.626 s
>> >> > >> > > > > [INFO] Finished at: 2017-03-01T14:05:08-08:00
>> >> > >> > > > > [INFO] Final Memory: 80M/654M
>> >> > >> > > > > [INFO] --
>> >> > >> --
>> >> > >> > > > > 
>> >> > >> > > > > [ERROR] Failed to execute goal org.apache.maven.plugins:
>> >> > >> > > > > maven-javadoc-plugin:2.10.1:

[GitHub] ignite pull request #1550: IGNITE-2310: additional docs for affinity jobs

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---
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: [VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

I propose to remove this script and keep only

https://twitter.com/ApacheIgnite";
class="twitter-follow-button" data-show-count="false"
data-size="large">Follow @ApacheIgnite

and fix this in proper way before next release.

Thoughts?

On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov 
wrote:

> I found the reason,
>
> Thats because of  tag content at parent/pom.xml:455
> It contains
> !function(d,s,id){var js,fjs=d.getElementsByTagName(
> s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
> d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://
> platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,
> fjs);}}(document
> <http://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);%7D%7D(document>,
> 'script', 'twitter-wjs');
>
> Do we really need it?
>
> On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
> avinogra...@gridgain.com> wrote:
>
>> Vyacheslav,
>>
>> Do you have Ideas why we got
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar
>> (module-javadoc) on project ignite-tools: MavenReportException: Error while
>> creating archive:
>> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains
>> JavaScript.
>> [ERROR] Use --allow-script-in-comments to allow use of JavaScript.
>>
>> at 1.8.0_121-b13 without --allow-script-in-comments flag?
>>
>> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur 
>> wrote:
>>
>>> >> Which one is true?
>>>
>>> This one true for https://dist.apache.org/repos/
>>> dist/dev/ignite/1.9.0-rc1:
>>> jdk8u121_x64 - *fine*
>>> jdk8u91_x64 - *fail
>>>
>>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur :
>>>
>>> > >> I got this exception with the lates jdk-8u121.
>>> > I had this problem earlier, not with RC.
>>> > Sorry for misleading
>>> >
>>> > >> Which one is true?
>>> >
>>> > This one true for https://dist.apache.org/repos/
>>> dist/dev/ignite/1.9.0-rc1:
>>> > jdk8u121_x64 - *fine*
>>> > jdk8u91_x64 - *fail
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov >> >:
>>> >
>>> >> Folks,
>>> >> Right before vote I faced with compilation error at 1.8.0_121-b13,
>>> that's
>>> >> why this flag was added.
>>> >>
>>> >> Vyacheslav,
>>> >> at first message you told
>>> >> >> I got this exception with the lates jdk-8u121.
>>> >>
>>> >> at next one
>>> >> >> jdk8u121_x64 - *fine*
>>> >> >> jdk8u91_x64 - *fail*
>>> >>
>>> >> Which one is true?
>>> >>
>>> >> I have no compilation errors at latest 1.8.0_121-b13
>>> >>
>>> >> Anyways, I'm looking for better solution.
>>> >>
>>> >> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur <
>>> daradu...@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > Guys, I found that.
>>> >> >
>>> >> > apache-ignite-1.9.0-src\parent\pom.xml
>>> >> >
>>> >> > line: 940
>>> >> >
>>> >> > We need to remove flag "--allow-script-in-comments",
>>> >> > it is new, and not capability with version less than jdk8u121_x64
>>> >> >
>>> >> > I can create PR with fix, or you can just fix it yourself.
>>> >> >
>>> >> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur >> >:
>>> >> >
>>> >> > > I checked it:
>>> >> > >
>>> >> > > jdk8u121_x64 - *fine*
>>> >> > > jdk8u91_x64 - *fail*
>>> >> > >
>>> >> > > It is strange.
>>> >> > >
>>> >> > > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov :
>>> >> > >
>>> >> > >> I used Oracle JDK 1.8.0_91
>>> >> > >>
>>> >> > >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
>>> >> > daradu...@gmail.com>
>>> >> > >> wrote:
>>> >> > >>
>>> >> > >> > Denis, Sergey witch version of JDK8 do you use?
>>> >> > >> >
>>> >> > >> > I got this exception with the lates jdk-8u121.
>>> >> > >> >
>>> >> > >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
>>> >> > >> >
>>> >> > >> > Look at "*New --allow-script-in-comments option for javadoc":*
>>> >> > >> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
>>> >> > >> -3315208.html
>>> >> > >> >
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov >> >:
>>> >> > >> >
>>> >> > >> > > Hi
>>> >> > >> > >
>>> >> > >> > > I confirm the issue. Unfortunately it was introduced with
>>> latest
>>> >> > >> commits
>>> >> > >> > > after the run of full set of tests.
>>> >> > >> > >
>>> >> > >> > > On Thu, Mar 2, 2017 at 6:38 AM, Denis Magda <
>>> dma...@apache.org>
>>> >> > >> wrote:
>>> >> > >> > >
>>> >> > >> > > > Getting absolutely the same exception under JDK 8.
>>> >> > >> > > >
>>> >> > >> > > > —
>>> >> > >> > > > Denis
>>> >> > >> > > >
>>> >> > >> > > > > On Mar 1, 2017, at 3:12 PM, Valentin Kulichenko <
>>> >> > >> > > > valentin.kuliche...@gmail.com> wrote:
>>> >> > >> > > > >
>>> >> > >> > > > > -1
>>> >> > >> > > > >
>>> >> > >> > > > > Building with 'mvn clean package -DskipTests' under JDK8
>>> >> fails
>>> >> > >> with
>>> >> > >> > the
>>> >> > >> > > > > error below. JDK7 is fine, though.
>>> >> > >> > > > >
>>> >> > >> > > > > [INFO] -

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

Anton, I found it too.

And I confirm, it is the main reason of building-error.

If remove ., then:
"mvn clean package -DskipTests"
jdk1.8.0_121_x64 - fine
jdk1.8.0_91_x64 - fine

As I understood, this script create a link to Ignite-twitter.
I think it is not very important.

I am trying another solution. (change of building order)

2017-03-02 13:38 GMT+03:00 Anton Vinogradov :

> I propose to remove this script and keep only
>
> https://twitter.com/ApacheIgnite";
> class="twitter-follow-button" data-show-count="false"
> data-size="large">Follow @ApacheIgnite
>
> and fix this in proper way before next release.
>
> Thoughts?
>
> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov  >
> wrote:
>
> > I found the reason,
> >
> > Thats because of  tag content at parent/pom.xml:455
> > It contains
> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://
> > platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,
> > fjs);}}(document
> > <http://platform.twitter.com/widgets.js';fjs.parentNode.
> insertBefore(js,fjs);%7D%7D(document>,
> > 'script', 'twitter-wjs');
> >
> > Do we really need it?
> >
> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
> > avinogra...@gridgain.com> wrote:
> >
> >> Vyacheslav,
> >>
> >> Do you have Ideas why we got
> >> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-javadoc-plugin:2.10.1:jar
> >> (module-javadoc) on project ignite-tools: MavenReportException: Error
> while
> >> creating archive:
> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains
> >> JavaScript.
> >> [ERROR] Use --allow-script-in-comments to allow use of JavaScript.
> >>
> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
> >>
> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
> daradu...@gmail.com>
> >> wrote:
> >>
> >>> >> Which one is true?
> >>>
> >>> This one true for https://dist.apache.org/repos/
> >>> dist/dev/ignite/1.9.0-rc1:
> >>> jdk8u121_x64 - *fine*
> >>> jdk8u91_x64 - *fail
> >>>
> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur :
> >>>
> >>> > >> I got this exception with the lates jdk-8u121.
> >>> > I had this problem earlier, not with RC.
> >>> > Sorry for misleading
> >>> >
> >>> > >> Which one is true?
> >>> >
> >>> > This one true for https://dist.apache.org/repos/
> >>> dist/dev/ignite/1.9.0-rc1:
> >>> > jdk8u121_x64 - *fine*
> >>> > jdk8u91_x64 - *fail
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov <
> avinogra...@gridgain.com
> >>> >:
> >>> >
> >>> >> Folks,
> >>> >> Right before vote I faced with compilation error at 1.8.0_121-b13,
> >>> that's
> >>> >> why this flag was added.
> >>> >>
> >>> >> Vyacheslav,
> >>> >> at first message you told
> >>> >> >> I got this exception with the lates jdk-8u121.
> >>> >>
> >>> >> at next one
> >>> >> >> jdk8u121_x64 - *fine*
> >>> >> >> jdk8u91_x64 - *fail*
> >>> >>
> >>> >> Which one is true?
> >>> >>
> >>> >> I have no compilation errors at latest 1.8.0_121-b13
> >>> >>
> >>> >> Anyways, I'm looking for better solution.
> >>> >>
> >>> >> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur <
> >>> daradu...@gmail.com>
> >>> >> wrote:
> >>> >>
> >>> >> > Guys, I found that.
> >>> >> >
> >>> >> > apache-ignite-1.9.0-src\parent\pom.xml
> >>> >> >
> >>> >> > line: 940
> >>> >> >
> >>> >> > We need to remove flag "--allow-script-in-comments",
> >>> >> > it is new, and not capability with version less than jdk8u121_x64
> >>> >> >
> >>> >> > I can create PR with fix, or you can just fix it yourself.
> >>> >> >
> >>> >> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur <
> daradu...@gmail.com
> >>> >:
> >>> >> >
> >>> >> > > I checked it:
> >>> >> > >
> >>> >> > > jdk8u121_x64 - *fine*
> >>> >> > > jdk8u91_x64 - *fail*
> >>> >> > >
> >>> >> > > It is strange.
> >>> >> > >
> >>> >> > > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov  >:
> >>> >> > >
> >>> >> > >> I used Oracle JDK 1.8.0_91
> >>> >> > >>
> >>> >> > >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
> >>> >> > daradu...@gmail.com>
> >>> >> > >> wrote:
> >>> >> > >>
> >>> >> > >> > Denis, Sergey witch version of JDK8 do you use?
> >>> >> > >> >
> >>> >> > >> > I got this exception with the lates jdk-8u121.
> >>> >> > >> >
> >>> >> > >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
> >>> >> > >> >
> >>> >> > >> > Look at "*New --allow-script-in-comments option for
> javadoc":*
> >>> >> > >> > http://www.oracle.com/technetwork/java/javase/8u121-relnotes
> >>> >> > >> -3315208.html
> >>> >> > >> >
> >>> >> > >> >
> >>> >> > >> >
> >>> >> > >> > 2017-03-02 10:53 GMT+03:00 Sergey Kozlov <
> skoz...@gridgain.com
> >>> >:
> >>> >> > >> >
> >>> >> > >> > > Hi
> >>> >> > >> > >
> >>> >> > >> > > I confirm the issue. Unfortunately it was introduced with
> >>> latest
> >>> >> > >> commit

[GitHub] ignite pull request #1585: IGNITE 4577 filter non reachable addresses

[ezhuravl]

GitHub user ezhuravl opened a pull request:

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

IGNITE 4577 filter non reachable addresses



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

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

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

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


commit 8cb16404276edcc933d6d57edb38f7192810a2aa
Author: Evgenii Zhuravlev 
Date:   2017-03-02T10:22:07Z

IGNITE 4577 filter non reachable addresses




---
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: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

Anton, a workaround solution:



2017-03-02 13:39 GMT+03:00 Vyacheslav Daradur :

> Anton, I found it too.
>
> And I confirm, it is the main reason of building-error.
>
> If remove ., then:
> "mvn clean package -DskipTests"
> jdk1.8.0_121_x64 - fine
> jdk1.8.0_91_x64 - fine
>
> As I understood, this script create a link to Ignite-twitter.
> I think it is not very important.
>
> I am trying another solution. (change of building order)
>
> 2017-03-02 13:38 GMT+03:00 Anton Vinogradov :
>
>> I propose to remove this script and keep only
>>
>> https://twitter.com/ApacheIgnite";
>> class="twitter-follow-button" data-show-count="false"
>> data-size="large">Follow @ApacheIgnite
>>
>> and fix this in proper way before next release.
>>
>> Thoughts?
>>
>> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov <
>> avinogra...@gridgain.com>
>> wrote:
>>
>> > I found the reason,
>> >
>> > Thats because of  tag content at parent/pom.xml:455
>> > It contains
>> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
>> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
>> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://
>> > platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,
>> > fjs);}}(document
>> > <http://platform.twitter.com/widgets.js';fjs.parentNode.inse
>> rtBefore(js,fjs);%7D%7D(document>,
>> > 'script', 'twitter-wjs');
>> >
>> > Do we really need it?
>> >
>> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
>> > avinogra...@gridgain.com> wrote:
>> >
>> >> Vyacheslav,
>> >>
>> >> Do you have Ideas why we got
>> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
>> -javadoc-plugin:2.10.1:jar
>> >> (module-javadoc) on project ignite-tools: MavenReportException: Error
>> while
>> >> creating archive:
>> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains
>> >> JavaScript.
>> >> [ERROR] Use --allow-script-in-comments to allow use of JavaScript.
>> >>
>> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
>> >>
>> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
>> daradu...@gmail.com>
>> >> wrote:
>> >>
>> >>> >> Which one is true?
>> >>>
>> >>> This one true for https://dist.apache.org/repos/
>> >>> dist/dev/ignite/1.9.0-rc1:
>> >>> jdk8u121_x64 - *fine*
>> >>> jdk8u91_x64 - *fail
>> >>>
>> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur :
>> >>>
>> >>> > >> I got this exception with the lates jdk-8u121.
>> >>> > I had this problem earlier, not with RC.
>> >>> > Sorry for misleading
>> >>> >
>> >>> > >> Which one is true?
>> >>> >
>> >>> > This one true for https://dist.apache.org/repos/
>> >>> dist/dev/ignite/1.9.0-rc1:
>> >>> > jdk8u121_x64 - *fine*
>> >>> > jdk8u91_x64 - *fail
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov <
>> avinogra...@gridgain.com
>> >>> >:
>> >>> >
>> >>> >> Folks,
>> >>> >> Right before vote I faced with compilation error at 1.8.0_121-b13,
>> >>> that's
>> >>> >> why this flag was added.
>> >>> >>
>> >>> >> Vyacheslav,
>> >>> >> at first message you told
>> >>> >> >> I got this exception with the lates jdk-8u121.
>> >>> >>
>> >>> >> at next one
>> >>> >> >> jdk8u121_x64 - *fine*
>> >>> >> >> jdk8u91_x64 - *fail*
>> >>> >>
>> >>> >> Which one is true?
>> >>> >>
>> >>> >> I have no compilation errors at latest 1.8.0_121-b13
>> >>> >>
>> >>> >> Anyways, I'm looking for better solution.
>> >>> >>
>> >>> >> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur <
>> >>> daradu...@gmail.com>
>> >>> >> wrote:
>> >>> >>
>> >>> >> > Guys, I found that.
>> >>> >> >
>> >>> >> > apache-ignite-1.9.0-src\parent\pom.xml
>> >>> >> >
>> >>> >> > line: 940
>> >>> >> >
>> >>> >> > We need to remove flag "--allow-script-in-comments",
>> >>> >> > it is new, and not capability with version less than jdk8u121_x64
>> >>> >> >
>> >>> >> > I can create PR with fix, or you can just fix it yourself.
>> >>> >> >
>> >>> >> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur <
>> daradu...@gmail.com
>> >>> >:
>> >>> >> >
>> >>> >> > > I checked it:
>> >>> >> > >
>> >>> >> > > jdk8u121_x64 - *fine*
>> >>> >> > > jdk8u91_x64 - *fail*
>> >>> >> > >
>> >>> >> > > It is strange.
>> >>> >> > >
>> >>> >> > > 2017-03-02 11:53 GMT+03:00 Sergey Kozlov > >:
>> >>> >> > >
>> >>> >> > >> I used Oracle JDK 1.8.0_91
>> >>> >> > >>
>> >>> >> > >> On Thu, Mar 2, 2017 at 11:38 AM, Vyacheslav Daradur <
>> >>> >> > daradu...@gmail.com>
>> >>> >> > >> wrote:
>> >>> >> > >>
>> >>> >> > >> > Denis, Sergey witch version of JDK8 do you use?
>> >>> >> > >> >
>> >>> >> > >> > I got this exception with the lates jdk-8u121.
>> >>> >> > >> >
>> >>> >> > >> > Building with flag "-Dmaven.javadoc.skip=true" works fine.
>> >>> >> > >> >
>> >>> >> > >> > Look at "*New --allow-script-in-comments option for
>> javadoc":*
>> >>> >> > >> > http://www.oracle.com/technetw
>> ork/java/javase/8u121-relnotes
>> >>> >> > >> -3315208.html
>> >>> >> > >> >
>> >>

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

Vyacheslav,

I see strange spaces and newlines here, please make a pull request, to
solve possible formation issues.

On Thu, Mar 2, 2017 at 2:04 PM, Vyacheslav Daradur 
wrote:

> Anton, a workaround solution:
>
>  js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.
> location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);
> js.id=id;js.src=p+'://
> platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(
> document,
> 'script', 'twitter-wjs');-->
>
> 2017-03-02 13:39 GMT+03:00 Vyacheslav Daradur :
>
> > Anton, I found it too.
> >
> > And I confirm, it is the main reason of building-error.
> >
> > If remove ., then:
> > "mvn clean package -DskipTests"
> > jdk1.8.0_121_x64 - fine
> > jdk1.8.0_91_x64 - fine
> >
> > As I understood, this script create a link to Ignite-twitter.
> > I think it is not very important.
> >
> > I am trying another solution. (change of building order)
> >
> > 2017-03-02 13:38 GMT+03:00 Anton Vinogradov :
> >
> >> I propose to remove this script and keep only
> >>
> >> https://twitter.com/ApacheIgnite";
> >> class="twitter-follow-button" data-show-count="false"
> >> data-size="large">Follow @ApacheIgnite
> >>
> >> and fix this in proper way before next release.
> >>
> >> Thoughts?
> >>
> >> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov <
> >> avinogra...@gridgain.com>
> >> wrote:
> >>
> >> > I found the reason,
> >> >
> >> > Thats because of  tag content at parent/pom.xml:455
> >> > It contains
> >> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
> >> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
> >> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://
> >> > platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,
> >> > fjs);}}(document
> >> > <http://platform.twitter.com/widgets.js';fjs.parentNode.inse
> >> rtBefore(js,fjs);%7D%7D(document>,
> >> > 'script', 'twitter-wjs');
> >> >
> >> > Do we really need it?
> >> >
> >> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
> >> > avinogra...@gridgain.com> wrote:
> >> >
> >> >> Vyacheslav,
> >> >>
> >> >> Do you have Ideas why we got
> >> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
> >> -javadoc-plugin:2.10.1:jar
> >> >> (module-javadoc) on project ignite-tools: MavenReportException: Error
> >> while
> >> >> creating archive:
> >> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains
> >> >> JavaScript.
> >> >> [ERROR] Use --allow-script-in-comments to allow use of JavaScript.
> >> >>
> >> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
> >> >>
> >> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
> >> daradu...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> >> Which one is true?
> >> >>>
> >> >>> This one true for https://dist.apache.org/repos/
> >> >>> dist/dev/ignite/1.9.0-rc1:
> >> >>> jdk8u121_x64 - *fine*
> >> >>> jdk8u91_x64 - *fail
> >> >>>
> >> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur  >:
> >> >>>
> >> >>> > >> I got this exception with the lates jdk-8u121.
> >> >>> > I had this problem earlier, not with RC.
> >> >>> > Sorry for misleading
> >> >>> >
> >> >>> > >> Which one is true?
> >> >>> >
> >> >>> > This one true for https://dist.apache.org/repos/
> >> >>> dist/dev/ignite/1.9.0-rc1:
> >> >>> > jdk8u121_x64 - *fine*
> >> >>> > jdk8u91_x64 - *fail
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov <
> >> avinogra...@gridgain.com
> >> >>> >:
> >> >>> >
> >> >>> >> Folks,
> >> >>> >> Right before vote I faced with compilation error at
> 1.8.0_121-b13,
> >> >>> that's
> >> >>> >> why this flag was added.
> >> >>> >>
> >> >>> >> Vyacheslav,
> >> >>> >> at first message you told
> >> >>> >> >> I got this exception with the lates jdk-8u121.
> >> >>> >>
> >> >>> >> at next one
> >> >>> >> >> jdk8u121_x64 - *fine*
> >> >>> >> >> jdk8u91_x64 - *fail*
> >> >>> >>
> >> >>> >> Which one is true?
> >> >>> >>
> >> >>> >> I have no compilation errors at latest 1.8.0_121-b13
> >> >>> >>
> >> >>> >> Anyways, I'm looking for better solution.
> >> >>> >>
> >> >>> >> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur <
> >> >>> daradu...@gmail.com>
> >> >>> >> wrote:
> >> >>> >>
> >> >>> >> > Guys, I found that.
> >> >>> >> >
> >> >>> >> > apache-ignite-1.9.0-src\parent\pom.xml
> >> >>> >> >
> >> >>> >> > line: 940
> >> >>> >> >
> >> >>> >> > We need to remove flag "--allow-script-in-comments",
> >> >>> >> > it is new, and not capability with version less than
> jdk8u121_x64
> >> >>> >> >
> >> >>> >> > I can create PR with fix, or you can just fix it yourself.
> >> >>> >> >
> >> >>> >> > 2017-03-02 12:35 GMT+03:00 Vyacheslav Daradur <
> >> daradu...@gmail.com
> >> >>> >:
> >> >>> >> >
> >> >>> >> > > I checked it:
> >> >>> >> > >
> >> >>> >> > > jdk8u121_x64 - *fine*
> >> >>> >> > > jdk8u91_x64 - *fail*
> >> >>> >> > >
> >> >>> >> > > It is strange.
> >> >>> >> >

[jira] [Created] (IGNITE-4768) Tx cache protocol change: notify client node from backups

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-4768:


 Summary: Tx cache protocol change: notify client node from backups
 Key: IGNITE-4768
 URL: https://issues.apache.org/jira/browse/IGNITE-4768
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Semen Boikov
Assignee: Semen Boikov
 Fix For: 2.0


Currently on prepare and finish steps backups first reply to primary and then 
primary replies to client, need check if it is possible to notify client 
directly from backups.



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

[jira] [Created] (IGNITE-4769) Handle possibly duplicated discovery messages

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4769:
---

 Summary: Handle possibly duplicated discovery messages
 Key: IGNITE-4769
 URL: https://issues.apache.org/jira/browse/IGNITE-4769
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0


*Problem*
It is known that discovery message notifications could be invoked more than 
once in case of unsuccessful concurrent topology changes. We need to protect 
DDL logic from it somehow.

*Proposed solution*
1) Add bounded set holding unique operation IDs.
2) Ignore init/ack message when ID already exists in history set.
3) Control maximum history size through system property.



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

[jira] [Created] (IGNITE-4770) Script inside javadoc bottom cause compilation error at 1.8.0_121-b13

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-4770:


 Summary: Script inside javadoc bottom cause compilation error at 
1.8.0_121-b13
 Key: IGNITE-4770
 URL: https://issues.apache.org/jira/browse/IGNITE-4770
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Vinogradov


 parent/pom.xml:455 contained following:

{noformat}
!function(d,s,id){var 
js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document,
 'script', 'twitter-wjs');
{noformat}

this cause compilation error during
{noformat}
mvn clean package -DskipTests
{noformat}

error
{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar (module-javadoc) on 
project ignite-tools: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains 
JavaScript.
[ERROR] Use --allow-script-in-comments to allow use of JavaScript.
{noformat}



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

[jira] [Created] (IGNITE-4771) Building error - Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-4771:
--

 Summary: Building error - Apache Ignite 1.9.0 RC1
 Key: IGNITE-4771
 URL: https://issues.apache.org/jira/browse/IGNITE-4771
 Project: Ignite
  Issue Type: Bug
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Priority: Blocker


Valentin Kulichenko:
Building with 'mvn clean package -DskipTests' under JDK8 fails with the
error below. JDK7 is fine, though.
{CODE}
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 12.626 s
[INFO] Finished at: 2017-03-01T14:05:08-08:00
[INFO] Final Memory: 80M/654M
[INFO] 

[ERROR] Failed to execute goal org.apache.maven.plugins:
maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project ignite-tools:
MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - javadoc: error - invalid flag:
--allow-script-in-comments
[ERROR]
[ERROR] Command line was: /Library/Java/JavaVirtualMachines/jdk1.8.0_
92.jdk/Contents/Home/jre/../bin/javadoc @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/Users/vkulichenko/Downloads/apache-ignite-1.9.0-src/modules/tools/target/apidocs'
dir.
[ERROR] -> [Help 1]
{CODE}

dev-list: 
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-1-9-0-RC1-td14985.html



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

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

I've created the issue
https://issues.apache.org/jira/browse/IGNITE-4770

On Thu, Mar 2, 2017 at 2:17 PM, Anton Vinogradov 
wrote:

> Vyacheslav,
>
> I see strange spaces and newlines here, please make a pull request, to
> solve possible formation issues.
>
> On Thu, Mar 2, 2017 at 2:04 PM, Vyacheslav Daradur 
> wrote:
>
>> Anton, a workaround solution:
>>
>> > js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.locati
>> on)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);
>> js.id=id;js.src=p+'://
>> platform.twitter.com/widgets.js';fjs.parentNode.insertBefore
>> (js,fjs);}}(document
>> 
>> ,
>> 'script', 'twitter-wjs');-->
>>
>> 2017-03-02 13:39 GMT+03:00 Vyacheslav Daradur :
>>
>> > Anton, I found it too.
>> >
>> > And I confirm, it is the main reason of building-error.
>> >
>> > If remove ., then:
>> > "mvn clean package -DskipTests"
>> > jdk1.8.0_121_x64 - fine
>> > jdk1.8.0_91_x64 - fine
>> >
>> > As I understood, this script create a link to Ignite-twitter.
>> > I think it is not very important.
>> >
>> > I am trying another solution. (change of building order)
>> >
>> > 2017-03-02 13:38 GMT+03:00 Anton Vinogradov :
>> >
>> >> I propose to remove this script and keep only
>> >>
>> >> https://twitter.com/ApacheIgnite";
>> >> class="twitter-follow-button" data-show-count="false"
>> >> data-size="large">Follow @ApacheIgnite
>> >>
>> >> and fix this in proper way before next release.
>> >>
>> >> Thoughts?
>> >>
>> >> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov <
>> >> avinogra...@gridgain.com>
>> >> wrote:
>> >>
>> >> > I found the reason,
>> >> >
>> >> > Thats because of  tag content at parent/pom.xml:455
>> >> > It contains
>> >> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
>> >> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
>> >> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://
>> >> > platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,
>> >> > fjs);}}(document
>> >> > <http://platform.twitter.com/widgets.js';fjs.parentNode.inse
>> >> rtBefore(js,fjs);%7D%7D(document>,
>> >> > 'script', 'twitter-wjs');
>> >> >
>> >> > Do we really need it?
>> >> >
>> >> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
>> >> > avinogra...@gridgain.com> wrote:
>> >> >
>> >> >> Vyacheslav,
>> >> >>
>> >> >> Do you have Ideas why we got
>> >> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
>> >> -javadoc-plugin:2.10.1:jar
>> >> >> (module-javadoc) on project ignite-tools: MavenReportException:
>> Error
>> >> while
>> >> >> creating archive:
>> >> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom
>> contains
>> >> >> JavaScript.
>> >> >> [ERROR] Use --allow-script-in-comments to allow use of JavaScript.
>> >> >>
>> >> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
>> >> >>
>> >> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
>> >> daradu...@gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >>> >> Which one is true?
>> >> >>>
>> >> >>> This one true for https://dist.apache.org/repos/
>> >> >>> dist/dev/ignite/1.9.0-rc1:
>> >> >>> jdk8u121_x64 - *fine*
>> >> >>> jdk8u91_x64 - *fail
>> >> >>>
>> >> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur > >:
>> >> >>>
>> >> >>> > >> I got this exception with the lates jdk-8u121.
>> >> >>> > I had this problem earlier, not with RC.
>> >> >>> > Sorry for misleading
>> >> >>> >
>> >> >>> > >> Which one is true?
>> >> >>> >
>> >> >>> > This one true for https://dist.apache.org/repos/
>> >> >>> dist/dev/ignite/1.9.0-rc1:
>> >> >>> > jdk8u121_x64 - *fine*
>> >> >>> > jdk8u91_x64 - *fail
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov <
>> >> avinogra...@gridgain.com
>> >> >>> >:
>> >> >>> >
>> >> >>> >> Folks,
>> >> >>> >> Right before vote I faced with compilation error at
>> 1.8.0_121-b13,
>> >> >>> that's
>> >> >>> >> why this flag was added.
>> >> >>> >>
>> >> >>> >> Vyacheslav,
>> >> >>> >> at first message you told
>> >> >>> >> >> I got this exception with the lates jdk-8u121.
>> >> >>> >>
>> >> >>> >> at next one
>> >> >>> >> >> jdk8u121_x64 - *fine*
>> >> >>> >> >> jdk8u91_x64 - *fail*
>> >> >>> >>
>> >> >>> >> Which one is true?
>> >> >>> >>
>> >> >>> >> I have no compilation errors at latest 1.8.0_121-b13
>> >> >>> >>
>> >> >>> >> Anyways, I'm looking for better solution.
>> >> >>> >>
>> >> >>> >> On Thu, Mar 2, 2017 at 12:42 PM, Vyacheslav Daradur <
>> >> >>> daradu...@gmail.com>
>> >> >>> >> wrote:
>> >> >>> >>
>> >> >>> >> > Guys, I found that.
>> >> >>> >> >
>> >> >>> >> > apache-ignite-1.9.0-src\parent\pom.xml
>> >> >>> >> >
>> >> >>> >> > line: 940
>> >> >>> >> >
>> >> >>> >> > We need to remove flag "--allow-script-in-comments",
>> >> >>> >> > it is new, and not capability with version less than
>> jdk8u121_x64
>> 

[GitHub] ignite pull request #1586: IGNITE-4770

[daradurvs]

GitHub user daradurvs opened a pull request:

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

IGNITE-4770



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

$ git pull https://github.com/daradurvs/ignite ignite-4770

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

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


commit ce3b7dab3aeeeca9e5f0357ab80309ecf75999ab
Author: Vyacheslav Daradur 
Date:   2017-03-02T12:24:32Z

ignite-4770: workaround solution




---
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: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

Anton, I think I found better way.

Please, look at:
https://github.com/apache/ignite/pull/1586/files

2017-03-02 15:19 GMT+03:00 Anton Vinogradov :

> I've created the issue
> https://issues.apache.org/jira/browse/IGNITE-4770
>
> On Thu, Mar 2, 2017 at 2:17 PM, Anton Vinogradov  >
> wrote:
>
> > Vyacheslav,
> >
> > I see strange spaces and newlines here, please make a pull request, to
> > solve possible formation issues.
> >
> > On Thu, Mar 2, 2017 at 2:04 PM, Vyacheslav Daradur 
> > wrote:
> >
> >> Anton, a workaround solution:
> >>
> >>  >> js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.locati
> >> on)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);
> >> js.id=id;js.src=p+'://
> >> platform.twitter.com/widgets.js';fjs.parentNode.insertBefore
> >> (js,fjs);}}(document
> >>  insertBefore(js,fjs);%7D%7D(document>
> >> ,
> >> 'script', 'twitter-wjs');-->
> >>
> >> 2017-03-02 13:39 GMT+03:00 Vyacheslav Daradur :
> >>
> >> > Anton, I found it too.
> >> >
> >> > And I confirm, it is the main reason of building-error.
> >> >
> >> > If remove ., then:
> >> > "mvn clean package -DskipTests"
> >> > jdk1.8.0_121_x64 - fine
> >> > jdk1.8.0_91_x64 - fine
> >> >
> >> > As I understood, this script create a link to Ignite-twitter.
> >> > I think it is not very important.
> >> >
> >> > I am trying another solution. (change of building order)
> >> >
> >> > 2017-03-02 13:38 GMT+03:00 Anton Vinogradov  >:
> >> >
> >> >> I propose to remove this script and keep only
> >> >>
> >> >> https://twitter.com/ApacheIgnite";
> >> >> class="twitter-follow-button" data-show-count="false"
> >> >> data-size="large">Follow @ApacheIgnite
> >> >>
> >> >> and fix this in proper way before next release.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov <
> >> >> avinogra...@gridgain.com>
> >> >> wrote:
> >> >>
> >> >> > I found the reason,
> >> >> >
> >> >> > Thats because of  tag content at parent/pom.xml:455
> >> >> > It contains
> >> >> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
> >> >> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
> >> >> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://
> >> >> > platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,
> >> >> > fjs);}}(document
> >> >> > <http://platform.twitter.com/widgets.js';fjs.parentNode.inse
> >> >> rtBefore(js,fjs);%7D%7D(document>,
> >> >> > 'script', 'twitter-wjs');
> >> >> >
> >> >> > Do we really need it?
> >> >> >
> >> >> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
> >> >> > avinogra...@gridgain.com> wrote:
> >> >> >
> >> >> >> Vyacheslav,
> >> >> >>
> >> >> >> Do you have Ideas why we got
> >> >> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
> >> >> -javadoc-plugin:2.10.1:jar
> >> >> >> (module-javadoc) on project ignite-tools: MavenReportException:
> >> Error
> >> >> while
> >> >> >> creating archive:
> >> >> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom
> >> contains
> >> >> >> JavaScript.
> >> >> >> [ERROR] Use --allow-script-in-comments to allow use of JavaScript.
> >> >> >>
> >> >> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
> >> >> >>
> >> >> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
> >> >> daradu...@gmail.com>
> >> >> >> wrote:
> >> >> >>
> >> >> >>> >> Which one is true?
> >> >> >>>
> >> >> >>> This one true for https://dist.apache.org/repos/
> >> >> >>> dist/dev/ignite/1.9.0-rc1:
> >> >> >>> jdk8u121_x64 - *fine*
> >> >> >>> jdk8u91_x64 - *fail
> >> >> >>>
> >> >> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur <
> daradu...@gmail.com
> >> >:
> >> >> >>>
> >> >> >>> > >> I got this exception with the lates jdk-8u121.
> >> >> >>> > I had this problem earlier, not with RC.
> >> >> >>> > Sorry for misleading
> >> >> >>> >
> >> >> >>> > >> Which one is true?
> >> >> >>> >
> >> >> >>> > This one true for https://dist.apache.org/repos/
> >> >> >>> dist/dev/ignite/1.9.0-rc1:
> >> >> >>> > jdk8u121_x64 - *fine*
> >> >> >>> > jdk8u91_x64 - *fail
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov <
> >> >> avinogra...@gridgain.com
> >> >> >>> >:
> >> >> >>> >
> >> >> >>> >> Folks,
> >> >> >>> >> Right before vote I faced with compilation error at
> >> 1.8.0_121-b13,
> >> >> >>> that's
> >> >> >>> >> why this flag was added.
> >> >> >>> >>
> >> >> >>> >> Vyacheslav,
> >> >> >>> >> at first message you told
> >> >> >>> >> >> I got this exception with the lates jdk-8u121.
> >> >> >>> >>
> >> >> >>> >> at next one
> >> >> >>> >> >> jdk8u121_x64 - *fine*
> >> >> >>> >> >> jdk8u91_x64 - *fail*
> >> >> >>> >>
> >> >> >>> >> Which one is true?
> >> >> >>> >>
> >> >> >>> >> I have no compilation errors at latest 1.8.0_121-b13
> >> >> >>> >>
> >> >> >>> >> Anyways, I'm looking for better 

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Vyacheslav Daradur]

Anton, please be careful: my PR doesn't contain the flag
"--allow-script-in-comments
flag"



2017-03-02 15:26 GMT+03:00 Vyacheslav Daradur :

> Anton, I think I found better way.
>
> Please, look at:
> https://github.com/apache/ignite/pull/1586/files
>
> 2017-03-02 15:19 GMT+03:00 Anton Vinogradov :
>
>> I've created the issue
>> https://issues.apache.org/jira/browse/IGNITE-4770
>>
>> On Thu, Mar 2, 2017 at 2:17 PM, Anton Vinogradov <
>> avinogra...@gridgain.com>
>> wrote:
>>
>> > Vyacheslav,
>> >
>> > I see strange spaces and newlines here, please make a pull request, to
>> > solve possible formation issues.
>> >
>> > On Thu, Mar 2, 2017 at 2:04 PM, Vyacheslav Daradur > >
>> > wrote:
>> >
>> >> Anton, a workaround solution:
>> >>
>> >> > >> js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.locati
>> >> on)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);
>> >> js.id=id;js.src=p+'://
>> >> platform.twitter.com/widgets.js';fjs.parentNode.insertBefore
>> >> (js,fjs);}}(document
>> >> > rtBefore(js,fjs);%7D%7D(document>
>> >> ,
>> >> 'script', 'twitter-wjs');-->
>> >>
>> >> 2017-03-02 13:39 GMT+03:00 Vyacheslav Daradur :
>> >>
>> >> > Anton, I found it too.
>> >> >
>> >> > And I confirm, it is the main reason of building-error.
>> >> >
>> >> > If remove ., then:
>> >> > "mvn clean package -DskipTests"
>> >> > jdk1.8.0_121_x64 - fine
>> >> > jdk1.8.0_91_x64 - fine
>> >> >
>> >> > As I understood, this script create a link to Ignite-twitter.
>> >> > I think it is not very important.
>> >> >
>> >> > I am trying another solution. (change of building order)
>> >> >
>> >> > 2017-03-02 13:38 GMT+03:00 Anton Vinogradov <
>> avinogra...@gridgain.com>:
>> >> >
>> >> >> I propose to remove this script and keep only
>> >> >>
>> >> >> https://twitter.com/ApacheIgnite";
>> >> >> class="twitter-follow-button" data-show-count="false"
>> >> >> data-size="large">Follow @ApacheIgnite
>> >> >>
>> >> >> and fix this in proper way before next release.
>> >> >>
>> >> >> Thoughts?
>> >> >>
>> >> >> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov <
>> >> >> avinogra...@gridgain.com>
>> >> >> wrote:
>> >> >>
>> >> >> > I found the reason,
>> >> >> >
>> >> >> > Thats because of  tag content at parent/pom.xml:455
>> >> >> > It contains
>> >> >> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
>> >> >> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
>> >> >> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=
>> p+'://
>> >> >> > platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,
>> >> >> > fjs);}}(document
>> >> >> > <http://platform.twitter.com/widgets.js';fjs.parentNode.inse
>> >> >> rtBefore(js,fjs);%7D%7D(document>,
>> >> >> > 'script', 'twitter-wjs');
>> >> >> >
>> >> >> > Do we really need it?
>> >> >> >
>> >> >> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
>> >> >> > avinogra...@gridgain.com> wrote:
>> >> >> >
>> >> >> >> Vyacheslav,
>> >> >> >>
>> >> >> >> Do you have Ideas why we got
>> >> >> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
>> >> >> -javadoc-plugin:2.10.1:jar
>> >> >> >> (module-javadoc) on project ignite-tools: MavenReportException:
>> >> Error
>> >> >> while
>> >> >> >> creating archive:
>> >> >> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom
>> >> contains
>> >> >> >> JavaScript.
>> >> >> >> [ERROR] Use --allow-script-in-comments to allow use of
>> JavaScript.
>> >> >> >>
>> >> >> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
>> >> >> >>
>> >> >> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
>> >> >> daradu...@gmail.com>
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >>> >> Which one is true?
>> >> >> >>>
>> >> >> >>> This one true for https://dist.apache.org/repos/
>> >> >> >>> dist/dev/ignite/1.9.0-rc1:
>> >> >> >>> jdk8u121_x64 - *fine*
>> >> >> >>> jdk8u91_x64 - *fail
>> >> >> >>>
>> >> >> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur <
>> daradu...@gmail.com
>> >> >:
>> >> >> >>>
>> >> >> >>> > >> I got this exception with the lates jdk-8u121.
>> >> >> >>> > I had this problem earlier, not with RC.
>> >> >> >>> > Sorry for misleading
>> >> >> >>> >
>> >> >> >>> > >> Which one is true?
>> >> >> >>> >
>> >> >> >>> > This one true for https://dist.apache.org/repos/
>> >> >> >>> dist/dev/ignite/1.9.0-rc1:
>> >> >> >>> > jdk8u121_x64 - *fine*
>> >> >> >>> > jdk8u91_x64 - *fail
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > 2017-03-02 12:46 GMT+03:00 Anton Vinogradov <
>> >> >> avinogra...@gridgain.com
>> >> >> >>> >:
>> >> >> >>> >
>> >> >> >>> >> Folks,
>> >> >> >>> >> Right before vote I faced with compilation error at
>> >> 1.8.0_121-b13,
>> >> >> >>> that's
>> >> >> >>> >> why this flag was added.
>> >> >> >>> >>
>> >> >> >>> >> Vyacheslav,
>> >> >> >>> >> at first message you told
>> >> >> >>> >> >> I got 

Re: code refactoring suggestion

[Andrey Gura]

Aleksey,

if you talk about fut.listen() then it doesn't make sense. listen()
call checks whether future is already completed and if it completed
invokes passed listener from current thread.

On Thu, Mar 2, 2017 at 12:42 PM, ALEKSEY KUZNETSOV
 wrote:
> Hi all ! During pessimistic transaction we execute prepare phase at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#commitAsync
> after executing prepareAsync();
> We bind listener on prepare future.
> Perhaps its better initially bind listener and then execute fut.prepare(); ?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*

Re: IGNITE-4758 - introducing cache memory policies

[Sergey Chugunov]

Hello igniters,

Working on the JIRA I found several situations not totally clear to me how
to handle properly.

First of all I introduced several validation rules for MemoryPolicy
configurations:

   - If user doesn't specify any MemoryPolicy, a default one is created
   implicitly.
   - If user specifies MemoryPolicy[ies] explicitly, one and only one
   default must be specified.
   - Two MemoryPolicies cannot have the same name.

But there are still several questions I would like to think over with
community:

   - What validation rule should be applied to MemoryPolicy size?
   Currently configuration requires to specify size in bytes, but obviously
   values like 1 or 2 don't make sense.

   I suggest to apply a lower limit of 1 MB.

   - If user doesn't specify any configuration what default MemoryPolicy
   size should be applied?

   Previously it was 1 GB, I suggest to use this value. Any arguments to
   change this?

   - Separate instance of PageMemory is needed for system caches which is
   created implicitly.
   What size should it have by default?
   Currently it is used only to store services and datastructures. If user
   doesn't need these it makes sense to use lower size by default.

   I think 100 MB would be enough. Surely this setting will be configurable
   via existing MemoryConfiguration interface.


Thanks,
Sergey.

On Thu, Mar 2, 2017 at 11:12 AM, Sergey Chugunov 
wrote:

> Yes, they use the same PageMemory region.
>
> On Wed, Mar 1, 2017 at 10:34 PM, Dmitriy Setrakyan 
> wrote:
>
>> When 2 caches share the same memory policy, does it mean that they are
>> using the same Page Memory offheap space?
>>
>> On Tue, Feb 28, 2017 at 11:49 PM, Sergey Chugunov <
>> sergey.chugu...@gmail.com
>> > wrote:
>>
>> > Dmitriy,
>> >
>> > Correct, cache configuration may contain a name of memory policy to use
>> for
>> > this cache.
>> > If memory policy is not specified, a default one is used.
>> >
>> > Thanks,
>> > Sergey.
>> >
>> > On Wed, Mar 1, 2017 at 1:02 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>> > wrote:
>> >
>> > > Thanks Sergey!
>> > >
>> > > Just to confirm, the same memory policy could be shared between
>> different
>> > > caches, right?
>> > >
>> > > D.
>> > >
>> > > On Tue, Feb 28, 2017 at 1:28 AM, Sergey Chugunov <
>> > > sergey.chugu...@gmail.com>
>> > > wrote:
>> > >
>> > > > Hello Ignite devs,
>> > > >
>> > > > I created new subtask > > jira/browse/IGNITE-4758
>> > > >
>> > > > under IGNITE-3477 > a/browse/IGNITE-3477>
>> > > with
>> > > > my vision of how *MemoryPolicy* may be implemented.
>> > > >
>> > > > In a nutshell my idea is as follows: instead of having only one
>> > instance
>> > > of
>> > > > *PageMemory* and managing a mapping [cacheId->pageMemory region] I
>> > > suggest
>> > > > introducing separate *PageMemory* instance (and corresponding
>> > *FreeList*
>> > > > and *ReuseList* structures) for each *MemoryPolicy* configuration.
>> > > > This instance will be stored in individual cache contexts instead of
>> > > shared
>> > > > cache context as it is right now.
>> > > >
>> > > > I think this design is a very natural extension of *PageMemory*
>> concept
>> > > and
>> > > > should not introduce any performance degradation as no changes are
>> > > > introduced into *PageMemory* implementation itself.
>> > > >
>> > > > Please share any thoughts or concerns about suggested design in this
>> > > thread
>> > > > or in comments under the subtask
>> > > > .
>> > > >
>> > > > Thanks,
>> > > > Sergey.
>> > > >
>> > >
>> >
>>
>
>

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Alexey Goncharuk]

Maxim,

I see several usages of asGridUuid() method, so I would just remove global
time and use nodeOrderDrId and topVer as different parts of high and low
parts of the embedded UUID.

--AG

2017-03-02 12:39 GMT+03:00 Kozlov Maxim :

> Andrey,
>
> When removed parameter globalTime, in method:
>
> public IgniteUuid asGridUuid() {
> return new IgniteUuid(new UUID(((long)topVer << 32) | nodeOrderDrId,
> globalTime), order);
> }
>
> globalTime parameter replaced by something or remove this method?
>
>
> > 2 марта 2017 г., в 12:07, Kozlov Maxim 
> написал(а):
> >
> > Andrey,
> >
> > Please review PR again.
> >
> >> 1 марта 2017 г., в 18:47, Andrey Gura  написал(а):
> >>
> >> I think that it is ok.
> >>
> >> On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim 
> wrote:
> >>> Ok. What do you say for the rest?
> >>>
>  1 марта 2017 г., в 18:15, Andrey Gura  написал(а):
> 
>  Maxim,
> 
>  I think that during renaming we should not lose "Atomic" prefix.
> 
> 
>  On Wed, Mar 1, 2017 at 5:16 PM, Kozlov Maxim 
> wrote:
> > Andrey, ok.
> >
> > Also remove in the modules/platform/dotnet
> CacheAtomicWriteOrderMode.cs?
> >
> > Rename classes:
> >
> > GridCacheAtomicNearCacheSelfTest.startGrids ->
> GridCacheAtomicNearCacheSelfTest.startGridsLocal (commit)
> > IgniteCacheAtomicPrimaryWriteOrderWithStoreInvokeTest ->
> IgniteCacheWithStoreInvokeTest
> > IgniteCacheAtomicPrimaryWriteOrderInvokeTest ->
> IgniteCacheInvokeTest
> > IgniteCacheAtomicPrimaryWriteOrderNearEnabledStoreValueTest ->
> IgniteCacheNearEnabledStoreValueTest
> > GridCacheAtomicPrimaryWriteOrderNearRemoveFailureTest ->
> GridCacheNearRemoveFailureTest
> > GridCacheAtomicPrimaryWriteOrderRemoveFailureTest ->
> GridCacheRemoveFailureTest
> > GridCacheAtomicPrimaryWriteOrderFailoverSelfTest ->
> GridCacheFailoverSelfTest
> > GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest
> -> GridCacheValueConsistencyNearEnabledSelfTest
> > CacheContinuousQueryAsyncFailoverAtomicPrimaryWriteOrderSelfTest ->
> CacheContinuousQueryAsyncFailoverSelfTest
> > CacheContinuousQueryFailoverAtomicPrimaryWriteOrderSelfTest ->
> CacheContinuousQueryFailoverSelfTest
> > GridCacheAtomicNearCacheSelfTest.testNoBackupsPrimaryWriteOrder ->
> GridCacheAtomicNearCacheSelfTest.testNoBackups
> > GridCacheAtomicNearCacheSelfTest.testWithBackupsPrimaryWriteOrder
> -> GridCacheAtomicNearCacheSelfTest.testWithBackups
> >
> > Remove classes:
> >
> > IgniteCacheAtomicPrimaryWriteOrderStoreValueTest
> > GridCacheReplicatedAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
> > GridCacheAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
> > GridCacheAtomicPrimaryWriteOrderMultiNodeP2PDisabledFullApiSelfTest
> > GridCacheAtomicPrimaryWrityOrderOffHeapMultiNodeFullApiSelfTest
> > GridCacheAtomicPrimaryWriteOrderOffHeapFullApiSelfTest
> > GridCacheAtomicPrimaryWriteOrderFullApiSelfTest
> > GridCacheAtomicPrimaryWriteOrderReloadAllSelfTest
> > IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest
> > GridCacheValueConsistencyAtomicPrimaryWriteOrderSelfTest
> > IgniteCacheAtomicPrimaryWriteOrderExpiryPolicyTest
> >
> > ok? :)
> >
> >> 1 марта 2017 г., в 2:04, Andrey Gura  написал(а):
> >>
> >> No, it should be removed. If somebody use entry last update time
> (e.g.
> >> for conflict resolving) they should store this time as entry field.
> >>
> >> On Wed, Mar 1, 2017 at 12:57 AM, Dmitriy Setrakyan
> >>  wrote:
> >>> Do we still need GridClockSyncProcessor?
> >>>
> >>> On Tue, Feb 28, 2017 at 5:26 AM, Andrey Gura 
> wrote:
> >>>
>  Maxim,
> 
>  Yes, this setting doesn't make sense anymore. So we need remove
> all
>  related methods.
> 
>  Also there is component called GridClockSyncProcessor that also
> should
>  be removed. It will lead to removing globalTime field from
>  GridCacheVersion class and some related methods.
> 
>  On Tue, Feb 28, 2017 at 3:21 PM, Kozlov Maxim <
> dreamx@gmail.com>
>  wrote:
> > Valentin,
> >
> > Then there is no need for setting CacheConfiguration.
> atomicWriteOrderMode.
>  What do you think, remove it and and related methods?
> >
> >> 28 февр. 2017 г., в 2:49, Valentin Kulichenko <
>  valentin.kuliche...@gmail.com> написал(а):
> >>
> >> Hi Max,
> >>
> >> In case we remove the CLOCK mode, I think we should remove the
> enum
>  too, as
> >> well as configuration properties and other code using this
> enum. Having
> >> enum with one value doesn't make sense to me.
> >>
> >> -Val
> >>
> >> On Mon, Feb 27, 2017 at 5:09 AM, Kozlov Maxim <
> dreamx@gmail.com>
>  wrote:
> >>
> >>> Hi Igniters,
> >>

[GitHub] ignite pull request #1586: IGNITE-4770

[daradurvs]

Github user daradurvs closed the pull request at:

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


---
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: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Andrey Gura]

+1

Removing of asGridUuid() method can lead to much code changes but it
should be avoided on this step.

On Thu, Mar 2, 2017 at 4:56 PM, Alexey Goncharuk
 wrote:
> Maxim,
>
> I see several usages of asGridUuid() method, so I would just remove global
> time and use nodeOrderDrId and topVer as different parts of high and low
> parts of the embedded UUID.
>
> --AG
>
> 2017-03-02 12:39 GMT+03:00 Kozlov Maxim :
>
>> Andrey,
>>
>> When removed parameter globalTime, in method:
>>
>> public IgniteUuid asGridUuid() {
>> return new IgniteUuid(new UUID(((long)topVer << 32) | nodeOrderDrId,
>> globalTime), order);
>> }
>>
>> globalTime parameter replaced by something or remove this method?
>>
>>
>> > 2 марта 2017 г., в 12:07, Kozlov Maxim 
>> написал(а):
>> >
>> > Andrey,
>> >
>> > Please review PR again.
>> >
>> >> 1 марта 2017 г., в 18:47, Andrey Gura  написал(а):
>> >>
>> >> I think that it is ok.
>> >>
>> >> On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim 
>> wrote:
>> >>> Ok. What do you say for the rest?
>> >>>
>>  1 марта 2017 г., в 18:15, Andrey Gura  написал(а):
>> 
>>  Maxim,
>> 
>>  I think that during renaming we should not lose "Atomic" prefix.
>> 
>> 
>>  On Wed, Mar 1, 2017 at 5:16 PM, Kozlov Maxim 
>> wrote:
>> > Andrey, ok.
>> >
>> > Also remove in the modules/platform/dotnet
>> CacheAtomicWriteOrderMode.cs?
>> >
>> > Rename classes:
>> >
>> > GridCacheAtomicNearCacheSelfTest.startGrids ->
>> GridCacheAtomicNearCacheSelfTest.startGridsLocal (commit)
>> > IgniteCacheAtomicPrimaryWriteOrderWithStoreInvokeTest ->
>> IgniteCacheWithStoreInvokeTest
>> > IgniteCacheAtomicPrimaryWriteOrderInvokeTest ->
>> IgniteCacheInvokeTest
>> > IgniteCacheAtomicPrimaryWriteOrderNearEnabledStoreValueTest ->
>> IgniteCacheNearEnabledStoreValueTest
>> > GridCacheAtomicPrimaryWriteOrderNearRemoveFailureTest ->
>> GridCacheNearRemoveFailureTest
>> > GridCacheAtomicPrimaryWriteOrderRemoveFailureTest ->
>> GridCacheRemoveFailureTest
>> > GridCacheAtomicPrimaryWriteOrderFailoverSelfTest ->
>> GridCacheFailoverSelfTest
>> > GridCacheValueConsistencyAtomicPrimaryWriteOrderNearEnabledSelfTest
>> -> GridCacheValueConsistencyNearEnabledSelfTest
>> > CacheContinuousQueryAsyncFailoverAtomicPrimaryWriteOrderSelfTest ->
>> CacheContinuousQueryAsyncFailoverSelfTest
>> > CacheContinuousQueryFailoverAtomicPrimaryWriteOrderSelfTest ->
>> CacheContinuousQueryFailoverSelfTest
>> > GridCacheAtomicNearCacheSelfTest.testNoBackupsPrimaryWriteOrder ->
>> GridCacheAtomicNearCacheSelfTest.testNoBackups
>> > GridCacheAtomicNearCacheSelfTest.testWithBackupsPrimaryWriteOrder
>> -> GridCacheAtomicNearCacheSelfTest.testWithBackups
>> >
>> > Remove classes:
>> >
>> > IgniteCacheAtomicPrimaryWriteOrderStoreValueTest
>> > GridCacheReplicatedAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
>> > GridCacheAtomicPrimaryWriteOrderMultiNodeFullApiSelfTest
>> > GridCacheAtomicPrimaryWriteOrderMultiNodeP2PDisabledFullApiSelfTest
>> > GridCacheAtomicPrimaryWrityOrderOffHeapMultiNodeFullApiSelfTest
>> > GridCacheAtomicPrimaryWriteOrderOffHeapFullApiSelfTest
>> > GridCacheAtomicPrimaryWriteOrderFullApiSelfTest
>> > GridCacheAtomicPrimaryWriteOrderReloadAllSelfTest
>> > IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest
>> > GridCacheValueConsistencyAtomicPrimaryWriteOrderSelfTest
>> > IgniteCacheAtomicPrimaryWriteOrderExpiryPolicyTest
>> >
>> > ok? :)
>> >
>> >> 1 марта 2017 г., в 2:04, Andrey Gura  написал(а):
>> >>
>> >> No, it should be removed. If somebody use entry last update time
>> (e.g.
>> >> for conflict resolving) they should store this time as entry field.
>> >>
>> >> On Wed, Mar 1, 2017 at 12:57 AM, Dmitriy Setrakyan
>> >>  wrote:
>> >>> Do we still need GridClockSyncProcessor?
>> >>>
>> >>> On Tue, Feb 28, 2017 at 5:26 AM, Andrey Gura 
>> wrote:
>> >>>
>>  Maxim,
>> 
>>  Yes, this setting doesn't make sense anymore. So we need remove
>> all
>>  related methods.
>> 
>>  Also there is component called GridClockSyncProcessor that also
>> should
>>  be removed. It will lead to removing globalTime field from
>>  GridCacheVersion class and some related methods.
>> 
>>  On Tue, Feb 28, 2017 at 3:21 PM, Kozlov Maxim <
>> dreamx@gmail.com>
>>  wrote:
>> > Valentin,
>> >
>> > Then there is no need for setting CacheConfiguration.
>> atomicWriteOrderMode.
>>  What do you think, remove it and and related methods?
>> >
>> >> 28 февр. 2017 г., в 2:49, Valentin Kulichenko <
>>  valentin.kuliche...@gmail.com> написал(а):
>> >>
>> >> Hi Max,
>> >>
>> >> In case we remove the CLOCK mode, I think we should remove the
>> enum
>>  too, as
>> >> well as configuration prope

[GitHub] ignite pull request #1587: IGNITE-3939 Compact long zero values binary repre...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3939 Compact long zero values binary representation



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

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

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

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


commit c893da70a9757b16b0799adc8eaa29fa1b03d06e
Author: tledkov-gridgain 
Date:   2016-12-21T11:54:33Z

IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and 
IgfsSecondaryFileSystemV2 interfaces. This closes #1346.

commit c5882a85f4e3a1f61723ac54fd92f087684df6da
Author: devozerov 
Date:   2016-12-26T11:15:42Z

Merge branch 'master' into ignite-2.0

commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be
Author: devozerov 
Date:   2016-12-28T09:54:47Z

Merge branch 'master' into ignite-2.0

commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f
Author: devozerov 
Date:   2016-12-28T09:58:11Z

IGNITE-3875: Introduced separate thread pool for data streamer. This closes 
#1173. This closes #1383.

commit a61b0eaff1817d84c0659e8a7e095f29e22800e1
Author: tledkov-gridgain 
Date:   2016-12-28T11:09:38Z

IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream 
and HadoopDirectDataInput classes. This closes #1358.

commit 2df39a80d80e2575be61a902ccd48615796fcde9
Author: tledkov-gridgain 
Date:   2016-12-28T13:47:24Z

IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This 
closes #1114. This closes #1252.

commit 2e691d80ea4870c3e7b5b127792b66c920f72c39
Author: tledkov-gridgain 
Date:   2016-12-29T08:00:01Z

IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes 
#1368.

commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5
Author: tledkov-gridgain 
Date:   2016-12-29T08:07:22Z

IGNITE-4459: Hadoop: weighted planned is default one from now on. This 
closes #1391.

commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This 
closes #1390.

commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89
Author: devozerov 
Date:   2017-01-05T09:23:06Z

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f
Author: Pavel Tupitsyn 
Date:   2017-01-19T10:34:59Z

Merge branch 'master' into ignite-2.0

commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9
Author: Ivan Veselovskiy 
Date:   2017-01-19T11:34:23Z

IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409.

commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7
Author: devozerov 
Date:   2017-01-19T11:34:43Z

Merge remote-tracking branch 'origin/ignite-2.0' into ignite-2.0

commit 4cd332b781cf700b99402eed2363f988f6403602
Author: Sergey Chugunov 
Date:   2017-01-19T12:05:09Z

IGNITE-4157 Use  discovery custom messages instead of marshaller cache - 
Fixes #1271.

Signed-off-by: Alexey Goncharuk 

commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765
Author: Pavel Tupitsyn 
Date:   2017-01-19T14:10:41Z

IGNITE-4441 Define plugin API in .NET

This closes #1362

commit 34a97833905a33bdb31b8e4580a576c2142313a7
Author: Alexey Goncharuk 
Date:   2017-01-19T15:04:23Z

IGNITE-4157 - Added mapping update listener stub

commit e8377167b7b8dd020a93d92c743e4541dcd000ed
Author: Pavel Tupitsyn 
Date:   2017-01-20T10:00:40Z

Merge branch 'master' into ignite-2.0

commit 38cb67d45eb91e20ad4b92a490747534f5e8febb
Author: Pavel Tupitsyn 
Date:   2017-01-20T13:09:57Z

Merge branch 'master' into ignite-2.0

commit 82857d0cb6e2984a5359b822a9c903874414aa67
Author: Pavel Tupitsyn 
Date:   2017-01-23T10:12:12Z

Merge branch 'master' into ignite-2.0

# Conflicts:
#   
modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v1/HadoopV1MapTask.java
#   
modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v1/HadoopV1ReduceTask.java

commit b0f84872945f36f240218636c298ecc9f765c152
Author: Pavel Tupitsyn 
Date:   2017-01-24T11:58:52Z

IGNITE-4592 .NET: Fix binary enum serialization

This closes #1456

commit b9901f02

Re: code refactoring suggestion

[voipp]

Hi all ! During pessimistic transaction we execute prepare phase at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#commitAsync
 
after executing prepareAsync(); 
We bind listener on prepare future. 
Perhaps its better initially bind listener and then execute fut.prepare(); ? 

No, what im talking about is at first place prepareAsync() is got executed,
then listener got binded.
Imagine the following flow :
1. execute prepareAsync();
2. prepare phase answer got
3. listener binded
So, listener would not be called.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/code-refactoring-suggestion-tp15045p15073.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[GitHub] ignite pull request #1588: ignite-4767

[akuramshingg]

GitHub user akuramshingg opened a pull request:

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

ignite-4767



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

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

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

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


commit 1ffd04aaedf09afa588a37479b6d74ced910137b
Author: Alexey Goncharuk 
Date:   2016-12-29T11:19:50Z

GG-11414 - Fixing compilation after merge.

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

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

commit 8852c80a0c6b52531ae6a287344f1ab776e3b32f
Author: Alexey Goncharuk 
Date:   2016-12-29T13:52:59Z

GG-11414 - Fixed cursor issue with expire time

commit 6f47f44c4b060d18f372a7d80bdd973a0ff02c7e
Author: sboikov 
Date:   2016-12-30T09:03:45Z

Fixed local cache size() method,

commit d139e6476d5ef6de3b79d2f33081821b50b2a969
Author: sboikov 
Date:   2016-12-30T09:11:22Z

Fixed 'directType' conflict for test message.

commit c66bb4f8f6a85607b262e863eb66489a56905b8c
Author: sboikov 
Date:   2016-12-30T10:11:34Z

- fixed lock order for interrupt lock/topology write lock
- GridCacheTtlManager: disable near cache eviction logic for local cache

commit 53b579f9487bb95b8b09064cd21087cb464bdf22
Author: sboikov 
Date:   2016-12-30T10:59:39Z

Need init page memory on clients for LOCAL caches.

commit f167a58eed911946df617c42d84878eb429175f0
Author: sboikov 
Date:   2016-12-30T11:55:55Z

Fixed GridDistributedTxRemoteAdapter.commitIfLocked (tx was not committed 
if write map was empty).

commit 5475bfda2b06feaa80e9060dfcd87f6cb819d20f
Author: sboikov 
Date:   2016-12-30T12:02:37Z

Fixed NPE in CacheContinuousQueryHandler.

commit a940fc3adbe36917ac80c06580a25ca0d0ba92c8
Author: sboikov 
Date:   2016-12-30T12:08:18Z

GridCacheContinuousQueryConcurrentTest: code style.

commit 81ba60fc38f6a880a3771ab50de31ff027f12811
Author: sboikov 
Date:   2016-12-30T14:07:12Z

Attempt to fix race between cache start and start future completion.

commit 7b6e6444d95445d88755804310417d5d5304599f
Author: Alexey Goncharuk 
Date:   2016-12-30T16:59:36Z

Fixed cache for query test

commit aa54b185c31600e4ac0934f5bad2fd431ea3d51f
Author: Alexey Goncharuk 
Date:   2016-12-30T16:59:54Z

Fixed invalid commented method in TTL manager

commit f8a152ef931e4334bfa44fca30c5d32151a8b470
Author: Alexey Goncharuk 
Date:   2016-12-30T19:03:37Z

Added removeExplicitNodeLocks lost during a merge.

commit c1c15a6db0bd84de49c0f828cdeab1aed4bcd863
Author: Dmitriy Govorukhin 
Date:   2017-01-03T16:59:44Z

ignite-gg-11414 Add iterator wrapper for cursor

commit 0f0158d3e887f0e130fca9807914a1711c1aa866
Author: Dmitriy Govorukhin 
Date:   2017-01-04T10:06:50Z

ignite gg 11208 fix test fail

commit 92dca1e80d1d238189e04b2b762671f70845547e
Author: sboikov 
Date:   2017-01-09T07:35:31Z

License headers.

commit 0e8cb00985c458faa24bbb60a379b491bd080042
Author: sboikov 
Date:   2017-01-09T08:22:15Z

Re-throw NodeStoppingException from GridDhtLocalPartition.tryEvict to avoid 
infinite loop in GridDhtPreloader.evictPartitionAsync.

commit d484a76ddfaca502f3f3997d5a98cd1eb9d136f2
Author: sboikov 
Date:   2017-01-09T08:42:39Z

IgniteCacheQueryNodeRestartSelfTest: increased test timeout.

commit 124ee7f19883e73e0fc7940d6fdbe216593fd505
Author: sboikov 
Date:   2017-01-09T08:56:22Z

ServerImpl: check attribute for null.

commit f3c723ce6ee0db9345304fd00e0e0df0e21383cd
Author: sboikov 
Date:   2017-01-09T09:10:33Z

Fixed CheckEntriesTask, disabled some tests.

commit ceff09cbccb4e0ab3e6b4234cc03bd0616894b1d
Author: sboikov 
Date:   2017-01-09T09:24:51Z

Disabled test since eviction is not implemented.

commit 06de699470092e0014a112617d44dbb57945fa08
Author: Alexey Goncharuk 
Date:   2017-01-09T09:42:53Z

Merge branch ignite-gg-8.0.2.ea2

commit 48b2653198070dd08ca1fdb878174b975c0b7fdc
Author: sboikov 
Date:   2017-01-09T09:51:36Z

Fixed  GridCacheTtlManager.expire for case when near cache is enabled.

commit a74d5ee23ed7ec0d0421f490f2baa42f13d584ec
Author: sboikov 
Date:   2017-01-09T09:51:58Z

Merge remote-tracking branch 'origin/ignite-3477' into ignite-3477

commit 57a002ad01d170d6219804430449b133a912a433
Author: sboikov 
Date:   2017-01-09T10:37:52Z

CacheLoadingConcurrentGridStartSelfTest: changed test to wait for data 
loading.

commit c1120927954079ff9dd4557b7a9c86b02fc85cc1
Author: sboikov 
Date:   2017-01-09T10:44:51Z

GridCacheAtomicInvalidPartitionHandlingSelfTest: fixed test to properly get 
cache entry.

commit 18caed3a393dd40aaec3302a6882c49923ca4c2e
Au

Re: IGNITE-603

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

Yakov, Okay. You can see result in JIRA
https://issues.apache.org/jira/browse/IGNITE-603

2017-02-28 19:31 GMT+03:00 Yakov Zhdanov :

> Denis, I can't say for sure, but the fact test was commented out for a long
> time is suspicious.
>
> Alexander, can you please uncomment, fix all the compilation errors and
> update the ticket with test run results. Make sure you have
> modules/ext-data projects built and all paths mentioned
> in modules/core/src/test/config/tests.properties are valid (you will need
> to set IGNITE_HOME env var most probably)
>
> --Yakov
>
> 2017-02-13 23:10 GMT+03:00 Denis Magda :
>
> > Hi Alexander,
> >
> > Looks like the test is commented for a while. GridDeploymentMode has
> > already been renamed to DeploymentMode.
> >
> > Yakov, is this test still relevant for the compute grid?
> >
> > —
> > Denis
> >
> > > On Feb 13, 2017, at 5:45 AM, Александр Меньшиков  >
> > wrote:
> > >
> > > Hello, everyone.
> > >
> > > I think the commented-out method "processSize2Test" can be removed.
> There
> > > aren't class "GridDeploymentMode" which used in arguments.
> > >
> > > Do you agree with me?
> >
> >
>

Re: [VOTE] Apache Ignite 1.9.0 RC1

[Anton Vinogradov]

This vote is closed.
Issues fixed and will be provided as a part of RC2 at upcoming vote.

On Thu, Mar 2, 2017 at 3:42 PM, Vyacheslav Daradur 
wrote:

> Anton, please be careful: my PR doesn't contain the flag
> "--allow-script-in-comments
> flag"
>
>
>
> 2017-03-02 15:26 GMT+03:00 Vyacheslav Daradur :
>
> > Anton, I think I found better way.
> >
> > Please, look at:
> > https://github.com/apache/ignite/pull/1586/files
> >
> > 2017-03-02 15:19 GMT+03:00 Anton Vinogradov :
> >
> >> I've created the issue
> >> https://issues.apache.org/jira/browse/IGNITE-4770
> >>
> >> On Thu, Mar 2, 2017 at 2:17 PM, Anton Vinogradov <
> >> avinogra...@gridgain.com>
> >> wrote:
> >>
> >> > Vyacheslav,
> >> >
> >> > I see strange spaces and newlines here, please make a pull request, to
> >> > solve possible formation issues.
> >> >
> >> > On Thu, Mar 2, 2017 at 2:04 PM, Vyacheslav Daradur <
> daradu...@gmail.com
> >> >
> >> > wrote:
> >> >
> >> >> Anton, a workaround solution:
> >> >>
> >> >>  >> >> js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.locati
> >> >> on)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);
> >> >> js.id=id;js.src=p+'://
> >> >> platform.twitter.com/widgets.js';fjs.parentNode.insertBefore
> >> >> (js,fjs);}}(document
> >> >>  >> rtBefore(js,fjs);%7D%7D(document>
> >> >> ,
> >> >> 'script', 'twitter-wjs');-->
> >> >>
> >> >> 2017-03-02 13:39 GMT+03:00 Vyacheslav Daradur :
> >> >>
> >> >> > Anton, I found it too.
> >> >> >
> >> >> > And I confirm, it is the main reason of building-error.
> >> >> >
> >> >> > If remove ., then:
> >> >> > "mvn clean package -DskipTests"
> >> >> > jdk1.8.0_121_x64 - fine
> >> >> > jdk1.8.0_91_x64 - fine
> >> >> >
> >> >> > As I understood, this script create a link to Ignite-twitter.
> >> >> > I think it is not very important.
> >> >> >
> >> >> > I am trying another solution. (change of building order)
> >> >> >
> >> >> > 2017-03-02 13:38 GMT+03:00 Anton Vinogradov <
> >> avinogra...@gridgain.com>:
> >> >> >
> >> >> >> I propose to remove this script and keep only
> >> >> >>
> >> >> >> https://twitter.com/ApacheIgnite";
> >> >> >> class="twitter-follow-button" data-show-count="false"
> >> >> >> data-size="large">Follow @ApacheIgnite
> >> >> >>
> >> >> >> and fix this in proper way before next release.
> >> >> >>
> >> >> >> Thoughts?
> >> >> >>
> >> >> >> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov <
> >> >> >> avinogra...@gridgain.com>
> >> >> >> wrote:
> >> >> >>
> >> >> >> > I found the reason,
> >> >> >> >
> >> >> >> > Thats because of  tag content at parent/pom.xml:455
> >> >> >> > It contains
> >> >> >> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
> >> >> >> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
> >> >> >> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=
> >> p+'://
> >> >> >> > platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js
> ,
> >> >> >> > fjs);}}(document
> >> >> >> > <http://platform.twitter.com/widgets.js';fjs.parentNode.inse
> >> >> >> rtBefore(js,fjs);%7D%7D(document>,
> >> >> >> > 'script', 'twitter-wjs');
> >> >> >> >
> >> >> >> > Do we really need it?
> >> >> >> >
> >> >> >> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
> >> >> >> > avinogra...@gridgain.com> wrote:
> >> >> >> >
> >> >> >> >> Vyacheslav,
> >> >> >> >>
> >> >> >> >> Do you have Ideas why we got
> >> >> >> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
> >> >> >> -javadoc-plugin:2.10.1:jar
> >> >> >> >> (module-javadoc) on project ignite-tools: MavenReportException:
> >> >> Error
> >> >> >> while
> >> >> >> >> creating archive:
> >> >> >> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom
> >> >> contains
> >> >> >> >> JavaScript.
> >> >> >> >> [ERROR] Use --allow-script-in-comments to allow use of
> >> JavaScript.
> >> >> >> >>
> >> >> >> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
> >> >> >> >>
> >> >> >> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
> >> >> >> daradu...@gmail.com>
> >> >> >> >> wrote:
> >> >> >> >>
> >> >> >> >>> >> Which one is true?
> >> >> >> >>>
> >> >> >> >>> This one true for https://dist.apache.org/repos/
> >> >> >> >>> dist/dev/ignite/1.9.0-rc1:
> >> >> >> >>> jdk8u121_x64 - *fine*
> >> >> >> >>> jdk8u91_x64 - *fail
> >> >> >> >>>
> >> >> >> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur <
> >> daradu...@gmail.com
> >> >> >:
> >> >> >> >>>
> >> >> >> >>> > >> I got this exception with the lates jdk-8u121.
> >> >> >> >>> > I had this problem earlier, not with RC.
> >> >> >> >>> > Sorry for misleading
> >> >> >> >>> >
> >> >> >> >>> > >> Which one is true?
> >> >> >> >>> >
> >> >> >> >>> > This one true for https://dist.apache.org/repos/
> >> >> >> >>> dist/dev/ignite/1.9.0-rc1:
> >> >> >> >>> > jdk8u121_x64 - *fine*
> >> >> >> >>> > jdk8u91_x64 - *fail
> >> >> >> >>> >
> >> >> >> >>> >

[VOTE] Apache Ignite 1.9.0 RC2

[Anton Vinogradov]

Dear Sirs!

We have uploaded the 1.9.0 release candidate to
https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc2/

Git tag name is
1.9.0-rc2

This release includes the following changes:

Ignite:
* Added Data streamer mode for DML
* Added Discovery SPI Implementation for Ignite Kubernetes Pods
* SQL: Query can utilize multiple threads
* SQL: Improved distributed SQL support
* Benchmarking simplified and automated
* Fixed licenses generation during build
* ignite-spark module upgraded to Spark 2.0

Ignite.NET:
* DML support
* TransactionScope API for Ignite transactions support

Ignite CPP:
* DML support
* Implemented LoadCache
* ContinuousQuery support

Complete list of closed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.9%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/1.9.0-rc2

RELEASENOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc2

Please start voting.

+1 - to accept Apache Ignite 1.9.0-rc2
0 - don't care either way
-1 - DO NOT accept Apache Ignite 1.9.0-rc2 (explain why)

This vote will go for 72 hours.

[CANCEL] [VOTE] Apache Ignite 1.9.0 RC1

[Dmitriy Setrakyan]

Officially cancelling the vote.

On Thu, Mar 2, 2017 at 8:18 AM, Anton Vinogradov 
wrote:

> This vote is closed.
> Issues fixed and will be provided as a part of RC2 at upcoming vote.
>
> On Thu, Mar 2, 2017 at 3:42 PM, Vyacheslav Daradur 
> wrote:
>
> > Anton, please be careful: my PR doesn't contain the flag
> > "--allow-script-in-comments
> > flag"
> >
> >
> >
> > 2017-03-02 15:26 GMT+03:00 Vyacheslav Daradur :
> >
> > > Anton, I think I found better way.
> > >
> > > Please, look at:
> > > https://github.com/apache/ignite/pull/1586/files
> > >
> > > 2017-03-02 15:19 GMT+03:00 Anton Vinogradov  >:
> > >
> > >> I've created the issue
> > >> https://issues.apache.org/jira/browse/IGNITE-4770
> > >>
> > >> On Thu, Mar 2, 2017 at 2:17 PM, Anton Vinogradov <
> > >> avinogra...@gridgain.com>
> > >> wrote:
> > >>
> > >> > Vyacheslav,
> > >> >
> > >> > I see strange spaces and newlines here, please make a pull request,
> to
> > >> > solve possible formation issues.
> > >> >
> > >> > On Thu, Mar 2, 2017 at 2:04 PM, Vyacheslav Daradur <
> > daradu...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> >> Anton, a workaround solution:
> > >> >>
> > >> >>  > >> >> js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.locati
> > >> >> on)?'http':'https';if(!d.getElementById(id)){js=d.
> createElement(s);
> > >> >> js.id=id;js.src=p+'://
> > >> >> platform.twitter.com/widgets.js';fjs.parentNode.insertBefore
> > >> >> (js,fjs);}}(document
> > >> >>  > >> rtBefore(js,fjs);%7D%7D(document>
> > >> >> ,
> > >> >> 'script', 'twitter-wjs');-->
> > >> >>
> > >> >> 2017-03-02 13:39 GMT+03:00 Vyacheslav Daradur  >:
> > >> >>
> > >> >> > Anton, I found it too.
> > >> >> >
> > >> >> > And I confirm, it is the main reason of building-error.
> > >> >> >
> > >> >> > If remove ., then:
> > >> >> > "mvn clean package -DskipTests"
> > >> >> > jdk1.8.0_121_x64 - fine
> > >> >> > jdk1.8.0_91_x64 - fine
> > >> >> >
> > >> >> > As I understood, this script create a link to Ignite-twitter.
> > >> >> > I think it is not very important.
> > >> >> >
> > >> >> > I am trying another solution. (change of building order)
> > >> >> >
> > >> >> > 2017-03-02 13:38 GMT+03:00 Anton Vinogradov <
> > >> avinogra...@gridgain.com>:
> > >> >> >
> > >> >> >> I propose to remove this script and keep only
> > >> >> >>
> > >> >> >> https://twitter.com/ApacheIgnite";
> > >> >> >> class="twitter-follow-button" data-show-count="false"
> > >> >> >> data-size="large">Follow @ApacheIgnite
> > >> >> >>
> > >> >> >> and fix this in proper way before next release.
> > >> >> >>
> > >> >> >> Thoughts?
> > >> >> >>
> > >> >> >> On Thu, Mar 2, 2017 at 1:05 PM, Anton Vinogradov <
> > >> >> >> avinogra...@gridgain.com>
> > >> >> >> wrote:
> > >> >> >>
> > >> >> >> > I found the reason,
> > >> >> >> >
> > >> >> >> > Thats because of  tag content at parent/pom.xml:455
> > >> >> >> > It contains
> > >> >> >> > !function(d,s,id){var js,fjs=d.getElementsByTagName(
> > >> >> >> > s)[0],p=/^http:/.test(d.location)?'http':'https';if(!
> > >> >> >> > d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=
> > >> p+'://
> > >> >> >> > platform.twitter.com/widgets.js';fjs.parentNode.
> insertBefore(js
> > ,
> > >> >> >> > fjs);}}(document
> > >> >> >> > <http://platform.twitter.com/widgets.js';fjs.parentNode.inse
> > >> >> >> rtBefore(js,fjs);%7D%7D(document>,
> > >> >> >> > 'script', 'twitter-wjs');
> > >> >> >> >
> > >> >> >> > Do we really need it?
> > >> >> >> >
> > >> >> >> > On Thu, Mar 2, 2017 at 12:57 PM, Anton Vinogradov <
> > >> >> >> > avinogra...@gridgain.com> wrote:
> > >> >> >> >
> > >> >> >> >> Vyacheslav,
> > >> >> >> >>
> > >> >> >> >> Do you have Ideas why we got
> > >> >> >> >> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
> > >> >> >> -javadoc-plugin:2.10.1:jar
> > >> >> >> >> (module-javadoc) on project ignite-tools:
> MavenReportException:
> > >> >> Error
> > >> >> >> while
> > >> >> >> >> creating archive:
> > >> >> >> >> [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom
> > >> >> contains
> > >> >> >> >> JavaScript.
> > >> >> >> >> [ERROR] Use --allow-script-in-comments to allow use of
> > >> JavaScript.
> > >> >> >> >>
> > >> >> >> >> at 1.8.0_121-b13 without --allow-script-in-comments flag?
> > >> >> >> >>
> > >> >> >> >> On Thu, Mar 2, 2017 at 12:53 PM, Vyacheslav Daradur <
> > >> >> >> daradu...@gmail.com>
> > >> >> >> >> wrote:
> > >> >> >> >>
> > >> >> >> >>> >> Which one is true?
> > >> >> >> >>>
> > >> >> >> >>> This one true for https://dist.apache.org/repos/
> > >> >> >> >>> dist/dev/ignite/1.9.0-rc1:
> > >> >> >> >>> jdk8u121_x64 - *fine*
> > >> >> >> >>> jdk8u91_x64 - *fail
> > >> >> >> >>>
> > >> >> >> >>> 2017-03-02 12:52 GMT+03:00 Vyacheslav Daradur <
> > >> daradu...@gmail.com
> > >> >> >:
> > >> >> >> >>>
> > >> >> >> >>> > >> I got this exception with the lates jdk-8u121.
> > >> >> 

[jira] [Created] (IGNITE-4772) CPP: Add documentation for LoadCache feature

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-4772:
---

 Summary: CPP: Add documentation for LoadCache feature
 Key: IGNITE-4772
 URL: https://issues.apache.org/jira/browse/IGNITE-4772
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Affects Versions: 1.8
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 1.9


{{LoadCache}} feature has been implemented recently for C++ client 
(IGNITE-4670) and needs proper documentation on the readme.io



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

Re: [VOTE] Apache Ignite 1.9.0 RC2

[Denis Magda]

+1 (binding)

—
Denis

> On Mar 2, 2017, at 9:02 AM, Anton Vinogradov  wrote:
> 
> Dear Sirs!
> 
> We have uploaded the 1.9.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc2/
> 
> Git tag name is
> 1.9.0-rc2
> 
> This release includes the following changes:
> 
> Ignite:
> * Added Data streamer mode for DML
> * Added Discovery SPI Implementation for Ignite Kubernetes Pods
> * SQL: Query can utilize multiple threads
> * SQL: Improved distributed SQL support
> * Benchmarking simplified and automated
> * Fixed licenses generation during build
> * ignite-spark module upgraded to Spark 2.0
> 
> Ignite.NET:
> * DML support
> * TransactionScope API for Ignite transactions support
> 
> Ignite CPP:
> * DML support
> * Implemented LoadCache
> * ContinuousQuery support
> 
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.9%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/1.9.0-rc2
> 
> RELEASENOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc2
> 
> Please start voting.
> 
> +1 - to accept Apache Ignite 1.9.0-rc2
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 1.9.0-rc2 (explain why)
> 
> This vote will go for 72 hours.

[GitHub] ignite pull request #1589: Ignite 4541c

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

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

Ignite 4541c



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

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

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

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


commit c893da70a9757b16b0799adc8eaa29fa1b03d06e
Author: tledkov-gridgain 
Date:   2016-12-21T11:54:33Z

IGNITE-4399: IGFS: Merged IgfsSecondaryFileSystem and 
IgfsSecondaryFileSystemV2 interfaces. This closes #1346.

commit c5882a85f4e3a1f61723ac54fd92f087684df6da
Author: devozerov 
Date:   2016-12-26T11:15:42Z

Merge branch 'master' into ignite-2.0

commit 7e73d0223a3f09cbe0b7094a2c04bdf9d63ca9be
Author: devozerov 
Date:   2016-12-28T09:54:47Z

Merge branch 'master' into ignite-2.0

commit 7d82d6a06b5e9f1f8cd2909b865e37d46b8da03f
Author: devozerov 
Date:   2016-12-28T09:58:11Z

IGNITE-3875: Introduced separate thread pool for data streamer. This closes 
#1173. This closes #1383.

commit a61b0eaff1817d84c0659e8a7e095f29e22800e1
Author: tledkov-gridgain 
Date:   2016-12-28T11:09:38Z

IGNITE-4405: Hadoop: implemented "readLine" method for HadoopDataInStream 
and HadoopDirectDataInput classes. This closes #1358.

commit 2df39a80d80e2575be61a902ccd48615796fcde9
Author: tledkov-gridgain 
Date:   2016-12-28T13:47:24Z

IGNITE-3961: IGFS: Added IgfsSecondaryFileSystem.affintiy() method. This 
closes #1114. This closes #1252.

commit 2e691d80ea4870c3e7b5b127792b66c920f72c39
Author: tledkov-gridgain 
Date:   2016-12-29T08:00:01Z

IGNITE-4462: IGFS: removed grid name from HadoopIgfsEndpoint. This closes 
#1368.

commit a9b1fc2b3840d47d7c978d9296e8ae6bdeb10be5
Author: tledkov-gridgain 
Date:   2016-12-29T08:07:22Z

IGNITE-4459: Hadoop: weighted planned is default one from now on. This 
closes #1391.

commit 1f743465d6875ef48b1835d03a78a0dbaf339bf6
Author: tledkov-gridgain 
Date:   2016-12-29T08:14:10Z

IGNITE-4458: Hadoop: "striped" shuffle mode is default from now on. This 
closes #1390.

commit 6090ebdfcd0ea3840b0d32cb10197b43615e1e89
Author: devozerov 
Date:   2017-01-05T09:23:06Z

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e08b6ff48916edfab2dbd5d62092be5a1f819a2f
Author: Pavel Tupitsyn 
Date:   2017-01-19T10:34:59Z

Merge branch 'master' into ignite-2.0

commit 43adf8a3f09c6b29fe3e70f62dbc58251d8d7cb9
Author: Ivan Veselovskiy 
Date:   2017-01-19T11:34:23Z

IGNITE-4219: Hadoop: fixed serialization of long strings. This closes #1409.

commit 454b9769e72775c5f6b44a36f0eef84bcce13bd7
Author: devozerov 
Date:   2017-01-19T11:34:43Z

Merge remote-tracking branch 'origin/ignite-2.0' into ignite-2.0

commit 4cd332b781cf700b99402eed2363f988f6403602
Author: Sergey Chugunov 
Date:   2017-01-19T12:05:09Z

IGNITE-4157 Use  discovery custom messages instead of marshaller cache - 
Fixes #1271.

Signed-off-by: Alexey Goncharuk 

commit d0a6c57aa26bca64ef68370c0ebdb5ce45bcc765
Author: Pavel Tupitsyn 
Date:   2017-01-19T14:10:41Z

IGNITE-4441 Define plugin API in .NET

This closes #1362

commit 34a97833905a33bdb31b8e4580a576c2142313a7
Author: Alexey Goncharuk 
Date:   2017-01-19T15:04:23Z

IGNITE-4157 - Added mapping update listener stub

commit e8377167b7b8dd020a93d92c743e4541dcd000ed
Author: Pavel Tupitsyn 
Date:   2017-01-20T10:00:40Z

Merge branch 'master' into ignite-2.0

commit 38cb67d45eb91e20ad4b92a490747534f5e8febb
Author: Pavel Tupitsyn 
Date:   2017-01-20T13:09:57Z

Merge branch 'master' into ignite-2.0

commit 82857d0cb6e2984a5359b822a9c903874414aa67
Author: Pavel Tupitsyn 
Date:   2017-01-23T10:12:12Z

Merge branch 'master' into ignite-2.0

# Conflicts:
#   
modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v1/HadoopV1MapTask.java
#   
modules/hadoop/src/main/java/org/apache/ignite/internal/processors/hadoop/impl/v1/HadoopV1ReduceTask.java

commit b0f84872945f36f240218636c298ecc9f765c152
Author: Pavel Tupitsyn 
Date:   2017-01-24T11:58:52Z

IGNITE-4592 .NET: Fix binary enum serialization

This closes #1456

commit b9901f02147319e811be21db1e3b9fd1970fa47d
Author: Pavel Tupitsy

Re: IGNITE-4758 - introducing cache memory policies

[Dmitriy Setrakyan]

Sergey, my comments are below...

On Thu, Mar 2, 2017 at 5:22 AM, Sergey Chugunov 
wrote:

> Hello igniters,
>
> Working on the JIRA I found several situations not totally clear to me how
> to handle properly.
>
> First of all I introduced several validation rules for MemoryPolicy
> configurations:
>
>- If user doesn't specify any MemoryPolicy, a default one is created
>implicitly.
>- If user specifies MemoryPolicy[ies] explicitly, one and only one
>default must be specified.
>- Two MemoryPolicies cannot have the same name.
>

All makes sense.


>
> But there are still several questions I would like to think over with
> community:
>
>- What validation rule should be applied to MemoryPolicy size?
>Currently configuration requires to specify size in bytes, but obviously
>values like 1 or 2 don't make sense.
>
>I suggest to apply a lower limit of 1 MB.
>
>- If user doesn't specify any configuration what default MemoryPolicy
>size should be applied?
>
>Previously it was 1 GB, I suggest to use this value. Any arguments to
>change this?
>

This sounds reasonable. We must explicitly print out a message in the log
that 1GB was selected for the default. Also, once the evictions start, i.e.
once we run out of space, we also must print out an explicit message in the
log.


>- Separate instance of PageMemory is needed for system caches which is
>created implicitly.
>What size should it have by default?
>Currently it is used only to store services and datastructures. If user
>doesn't need these it makes sense to use lower size by default.
>
>I think 100 MB would be enough. Surely this setting will be configurable
>via existing MemoryConfiguration interface.
>

100MB by default sounds reasonable to me. However, I would only initiate
this space if user creates his first data structure or his first service.
As usual, we must have a print out in the log that 100MB was allocated and
which config property should be used to change this value.


>
>
> Thanks,
> Sergey.
>
> On Thu, Mar 2, 2017 at 11:12 AM, Sergey Chugunov <
> sergey.chugu...@gmail.com>
> wrote:
>
> > Yes, they use the same PageMemory region.
> >
> > On Wed, Mar 1, 2017 at 10:34 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> >> When 2 caches share the same memory policy, does it mean that they are
> >> using the same Page Memory offheap space?
> >>
> >> On Tue, Feb 28, 2017 at 11:49 PM, Sergey Chugunov <
> >> sergey.chugu...@gmail.com
> >> > wrote:
> >>
> >> > Dmitriy,
> >> >
> >> > Correct, cache configuration may contain a name of memory policy to
> use
> >> for
> >> > this cache.
> >> > If memory policy is not specified, a default one is used.
> >> >
> >> > Thanks,
> >> > Sergey.
> >> >
> >> > On Wed, Mar 1, 2017 at 1:02 AM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> >> > wrote:
> >> >
> >> > > Thanks Sergey!
> >> > >
> >> > > Just to confirm, the same memory policy could be shared between
> >> different
> >> > > caches, right?
> >> > >
> >> > > D.
> >> > >
> >> > > On Tue, Feb 28, 2017 at 1:28 AM, Sergey Chugunov <
> >> > > sergey.chugu...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Hello Ignite devs,
> >> > > >
> >> > > > I created new subtask  >> > jira/browse/IGNITE-4758
> >> > > >
> >> > > > under IGNITE-3477  >> a/browse/IGNITE-3477>
> >> > > with
> >> > > > my vision of how *MemoryPolicy* may be implemented.
> >> > > >
> >> > > > In a nutshell my idea is as follows: instead of having only one
> >> > instance
> >> > > of
> >> > > > *PageMemory* and managing a mapping [cacheId->pageMemory region] I
> >> > > suggest
> >> > > > introducing separate *PageMemory* instance (and corresponding
> >> > *FreeList*
> >> > > > and *ReuseList* structures) for each *MemoryPolicy* configuration.
> >> > > > This instance will be stored in individual cache contexts instead
> of
> >> > > shared
> >> > > > cache context as it is right now.
> >> > > >
> >> > > > I think this design is a very natural extension of *PageMemory*
> >> concept
> >> > > and
> >> > > > should not introduce any performance degradation as no changes are
> >> > > > introduced into *PageMemory* implementation itself.
> >> > > >
> >> > > > Please share any thoughts or concerns about suggested design in
> this
> >> > > thread
> >> > > > or in comments under the subtask
> >> > > > .
> >> > > >
> >> > > > Thanks,
> >> > > > Sergey.
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Re: Additional SQL metrics

[Dmitriy Setrakyan]

I think some of the metrics specified by Denis also make sense, so I would
add them as well. See below...

On Thu, Mar 2, 2017 at 12:36 AM, Vladimir Ozerov 
wrote:

> Denis,
>
> Query execution is complex process involving different stages which are not
> very easy to match with each other. Especially provided that any node can
> leave topology at any time. Another problem is that engine evolves and
> metrics like "did a query do broadcast or unicast" may easily become
> useless at some point, because for example there will be neither unicast,
> nor broadast, but something different. On the other hand I completely agree
> that performance monitoring is essential part of any mature DBMS.
>
> I would start with metrics which are both very basic and easy to implement
> at the same time. For example we can add fingerprint (hash) to every query
> which will be used to join "map" and "reduce" parts with each other and add
> the following basic metrics:
> 1) Execution count for particular query
> 2) Number of map nodes - min, max, avg
>

(1) and (2) makes sense


> 3) Map step duration (if applicable) - min, max,

4) Reduce step duration (if applicable) - min, max, avg
>

Not sure if (3) and (4) are needed. I would only add them if they are easy
to implement.

I would also add these:

5) Collocated: yes/no
6) last execution time
7) min/max/average execution duration


>
> Once done users will be able to get statistics for particular queries.
>
> Vladimir.
>
>
> On Tue, Feb 28, 2017 at 3:12 AM, Denis Magda  wrote:
>
> > BTW,
> >
> > What if we expose per-query metrics below as a part of EXPLAIN ANALYZE?
> > Sergi, is this feasible?
> >
> > —
> > Denis
> >
> > > On Feb 27, 2017, at 2:35 PM, Denis Magda  wrote:
> > >
> > > Igniters,
> > >
> > > Let’s shed more light on SQL query execution internals introducing a
> set
> > of useful metrics (https://issues.apache.org/jira/browse/IGNITE-4757).
> > >
> > > Per-query metrics. Total history size is defined by
> *CacheConfiguration.
> > getQueryDetailMetricsSize*:
> > > * if a query was executed in the collocated or non-collocated mode.
> > Three results are valid: collocated, non-collocated, simple query (no
> > joins).
> > > * non-collocated query: size of the data exchanged between the nodes to
> > complete a join.
> > > * non-collocated query: did a query do broadcast or unicast to get data
> > needed to complete a join.
> > > * non-collocated and collocated query: a part of the time spent joining
> > the data.
> > >
> > > CacheMetrics:
> > > * an average number of executed SQL queries (collocated,
> non-collocated,
> > simple query (no joins)).
> > >
> > > Please don’t hesitate do share suggest another metrics or improve
> > proposed ones.
> > >
> > > —
> > > Denis
> >
> >
>

Re: Additional SQL metrics

[Denis Magda]

Vovan,

Your metrics make perfect sense to me. However, I see a high demand for JOINs 
based metrics especially from those who give a try to non-collocated joins in 
production  and want to measure them somehow. This is why, personally, I prefer 
to see the metrics below in the top priority list as well:

if a query was executed in the collocated or non-collocated mode. Three results 
are valid: collocated, non-collocated, simple query (no joins).
non-collocated query: size of the data exchanged between the nodes to complete 
a specific join. If there are multiple joins in the query we need to provide 
this metric for every of them.
non-collocated and collocated query: a part of the time spent joining the data. 
If there are multiple joins in the query we need to provide this metric for 
every of them.

As for “unicast” and “broadcast”, agree, let’s ignore it for now.

In any case, can we include timing information (map phase, reduce phase, join 
phase) into an execution plan produced by H2? Are there any implementation 
hooks?

—
Denis


> On Mar 2, 2017, at 12:02 PM, Dmitriy Setrakyan  wrote:
> 
> I think some of the metrics specified by Denis also make sense, so I would
> add them as well. See below...
> 
> On Thu, Mar 2, 2017 at 12:36 AM, Vladimir Ozerov  >
> wrote:
> 
>> Denis,
>> 
>> Query execution is complex process involving different stages which are not
>> very easy to match with each other. Especially provided that any node can
>> leave topology at any time. Another problem is that engine evolves and
>> metrics like "did a query do broadcast or unicast" may easily become
>> useless at some point, because for example there will be neither unicast,
>> nor broadast, but something different. On the other hand I completely agree
>> that performance monitoring is essential part of any mature DBMS.
>> 
>> I would start with metrics which are both very basic and easy to implement
>> at the same time. For example we can add fingerprint (hash) to every query
>> which will be used to join "map" and "reduce" parts with each other and add
>> the following basic metrics:
>> 1) Execution count for particular query
>> 2) Number of map nodes - min, max, avg
>> 
> 
> (1) and (2) makes sense
> 
> 
>> 3) Map step duration (if applicable) - min, max,
> 
> 4) Reduce step duration (if applicable) - min, max, avg
>> 
> 
> Not sure if (3) and (4) are needed. I would only add them if they are easy
> to implement.
> 
> I would also add these:
> 
> 5) Collocated: yes/no
> 6) last execution time
> 7) min/max/average execution duration
> 
> 
>> 
>> Once done users will be able to get statistics for particular queries.
>> 
>> Vladimir.
>> 
>> 
>> On Tue, Feb 28, 2017 at 3:12 AM, Denis Magda  wrote:
>> 
>>> BTW,
>>> 
>>> What if we expose per-query metrics below as a part of EXPLAIN ANALYZE?
>>> Sergi, is this feasible?
>>> 
>>> —
>>> Denis
>>> 
 On Feb 27, 2017, at 2:35 PM, Denis Magda  wrote:
 
 Igniters,
 
 Let’s shed more light on SQL query execution internals introducing a
>> set
>>> of useful metrics (https://issues.apache.org/jira/browse/IGNITE-4757).
 
 Per-query metrics. Total history size is defined by
>> *CacheConfiguration.
>>> getQueryDetailMetricsSize*:
 * if a query was executed in the collocated or non-collocated mode.
>>> Three results are valid: collocated, non-collocated, simple query (no
>>> joins).
 * non-collocated query: size of the data exchanged between the nodes to
>>> complete a join.
 * non-collocated query: did a query do broadcast or unicast to get data
>>> needed to complete a join.
 * non-collocated and collocated query: a part of the time spent joining
>>> the data.
 
 CacheMetrics:
 * an average number of executed SQL queries (collocated,
>> non-collocated,
>>> simple query (no joins)).
 
 Please don’t hesitate do share suggest another metrics or improve
>>> proposed ones.
 
 —
 Denis

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Denis Magda]

> On Mar 1, 2017, at 11:22 PM, Yakov Zhdanov  wrote:
> 
> I don't think new name makes things better.
> 
> Btw, what if we remove metrics from heartbeats at all and make metrics
> local and allow aggregations only via management console?
> 
What’s about compute engine load balancers then? They rely on the metrics 
received from remote nodes.

BTW, I’ve found this method suddenly - 
IgniteConfiguraion.getMetricsUpdateFrequency which defines frequency for job 
metrics.

What if we use this method to adjust frequency for metrics sent over 
heartbeats? It’s obvious that we need to align our API somehow.

—
Denis

> --Yakov
> 
> 2017-03-02 2:24 GMT+03:00 Denis Magda :
> 
>> Yasha,
>> 
>> Is there any other reason rather than compatibility that prevents us from
>> both improving documentation and renaming the parameter?
>> 
>> —
>> Denis
>> 
>>> On Mar 1, 2017, at 1:13 AM, Yakov Zhdanov  wrote:
>>> 
>>> I think we should not rename this, but properly document the behavior and
>>> all the relationships.
>>> 
>>> --Yakov
>>> 
>>> 2017-02-28 20:40 GMT+03:00 Dani Traphagen :
>>> 
 I had this thought when exploring this parameter at first and only was
>> able
 to change my understanding when evaluating it more deeply in the source
>> and
 reaching out to other users/devs.
 
 There could be an issue with new users who think increasing the hb
 frequency will impact inter-node failure detection - so people might
>> tweak
 it thinking it does something it doesn't. I think renaming it could help
 avoid this. This is because other systems use heartbeat frequencies for
 failure detection protocols under the hood so people may be coming with
 this understanding and think that's what this parameter is for.
 On Tue, Feb 28, 2017 at 9:16 AM Denis Magda  wrote:
 
> They expect exactly what the name of the
> TcpDiscoverySpi.heartbeatsFrequency method says - rate of heartbeats
 will
> be adjusted if you play with this parameter.
> 
> However, this is not true because the frequency of heartbeats is
> calculated from the failure detection timeout.
> 
> —
> Denis
> 
>> On Feb 28, 2017, at 7:28 AM, Yakov Zhdanov 
 wrote:
>> 
>> Denis, I did not get your last message. What did users expect from
> changing
>> hbFreq?
>> 
>> --Yakov
>> 
>> 2017-02-28 4:08 GMT+03:00 Dmitriy Setrakyan :
>> 
>>> Yakov, what do you think?
>>> 
>>> On Mon, Feb 27, 2017 at 4:17 PM, Denis Magda 
 wrote:
>>> 
 Frankly, I decided to initiate this discussion after talking to many
 Apache Ignite users who had initially thought that TcpDiscoverySpi.
>>> heartbeatsFrequency
 manages the heartbeats and they had tried to tweak it not getting a
>>> desired
 outcome. Even more, TcpDiscoverySpi.heartbeatsFrequenc’s javadoc
> already
 states that this is for metrics frequency only but looks like the
 guys
 hadn’t note this.
 
 So, personally, yes I would break the compatibility here which is
 fine
> to
 do in 2.0.
 
 —
 Denis
 
> On Feb 27, 2017, at 3:59 PM, Dmitriy Setrakyan <
 dsetrak...@apache.org
>> 
 wrote:
> 
> To me it sounds rather as an aesthetic change. Is it really worth
 breaking
> the API for this?
> 
> On Mon, Feb 27, 2017 at 3:30 PM, Denis Magda 
>>> wrote:
> 
>> The heartbeats frequency has to be lower than the failure
>> detection
>> timeout. This is why we decided to calculate the former basing on
>> a
 value
>> set for the latter rather than making a user to adjust both
> properties
>> properly. This is how both parameters became related some time ago
 :)
>> 
>> Honestly, I don’t think that the javadoc improvement will make
 things
>> clearer for the users. Hope you will agree that people pay
 attention
>>> to
 the
>> naming first and, only if the naming makes sense to them, learn
 more
 about
>> the details referring to the javadoc.
>> 
>> —
>> Denis
>> 
>>> On Feb 27, 2017, at 2:59 PM, Dmitriy Setrakyan <
>>> dsetrak...@apache.org>
>> wrote:
>>> 
>>> Hm... I don't think that heartbeat frequency has to be associated
>>> with
>>> failure detection. What if we just update the javadoc for this
 parameter,
>>> stating that it has to do with metrics update only?
>>> 
>>> On Mon, Feb 27, 2017 at 11:44 AM, Denis Magda >> 
 wrote:
>>> 
 Igniters,
 
 Long time ago we updated the logic in discovery SPI that issues
>> heartbeats
 messages from one node to another. Presently, heartbeats
 frequency
>>>

Re: [VOTE] Apache Ignite 1.9.0 RC2

[Valentin Kulichenko]

+1 (binding)

-Val

On Thu, Mar 2, 2017 at 11:33 AM, Denis Magda  wrote:

> +1 (binding)
>
> —
> Denis
>
> > On Mar 2, 2017, at 9:02 AM, Anton Vinogradov 
> wrote:
> >
> > Dear Sirs!
> >
> > We have uploaded the 1.9.0 release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/1.9.0-rc2/
> >
> > Git tag name is
> > 1.9.0-rc2
> >
> > This release includes the following changes:
> >
> > Ignite:
> > * Added Data streamer mode for DML
> > * Added Discovery SPI Implementation for Ignite Kubernetes Pods
> > * SQL: Query can utilize multiple threads
> > * SQL: Improved distributed SQL support
> > * Benchmarking simplified and automated
> > * Fixed licenses generation during build
> > * ignite-spark module upgraded to Spark 2.0
> >
> > Ignite.NET:
> > * DML support
> > * TransactionScope API for Ignite transactions support
> >
> > Ignite CPP:
> > * DML support
> > * Implemented LoadCache
> > * ContinuousQuery support
> >
> > Complete list of closed issues:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%201.9%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/1.9.0-rc2
> >
> > RELEASENOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.9.0-rc2
> >
> > Please start voting.
> >
> > +1 - to accept Apache Ignite 1.9.0-rc2
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite 1.9.0-rc2 (explain why)
> >
> > This vote will go for 72 hours.
>
>

Re: Additional SQL metrics

[Dmitriy Setrakyan]

By the way, I am assuming that we are talking about per-query metrics, in
which case we should specify metrics history size, so we don't keep all the
queries in memory forever. I don't think it makes sense to have metrics
aggregated across the queries. Just wanted to clarify this.

On Thu, Mar 2, 2017 at 12:31 PM, Denis Magda  wrote:

> Vovan,
>
> Your metrics make perfect sense to me. However, I see a high demand for
> JOINs based metrics especially from those who give a try to non-collocated
> joins in production  and want to measure them somehow. This is why,
> personally, I prefer to see the metrics below in the top priority list as
> well:
>
> if a query was executed in the collocated or non-collocated mode. Three
> results are valid: collocated, non-collocated, simple query (no joins).
> non-collocated query: size of the data exchanged between the nodes to
> complete a specific join. If there are multiple joins in the query we need
> to provide this metric for every of them.
> non-collocated and collocated query: a part of the time spent joining the
> data. If there are multiple joins in the query we need to provide this
> metric for every of them.
>
> As for “unicast” and “broadcast”, agree, let’s ignore it for now.
>
> In any case, can we include timing information (map phase, reduce phase,
> join phase) into an execution plan produced by H2? Are there any
> implementation hooks?
>
> —
> Denis
>
>
> > On Mar 2, 2017, at 12:02 PM, Dmitriy Setrakyan 
> wrote:
> >
> > I think some of the metrics specified by Denis also make sense, so I
> would
> > add them as well. See below...
> >
> > On Thu, Mar 2, 2017 at 12:36 AM, Vladimir Ozerov  >
> > wrote:
> >
> >> Denis,
> >>
> >> Query execution is complex process involving different stages which are
> not
> >> very easy to match with each other. Especially provided that any node
> can
> >> leave topology at any time. Another problem is that engine evolves and
> >> metrics like "did a query do broadcast or unicast" may easily become
> >> useless at some point, because for example there will be neither
> unicast,
> >> nor broadast, but something different. On the other hand I completely
> agree
> >> that performance monitoring is essential part of any mature DBMS.
> >>
> >> I would start with metrics which are both very basic and easy to
> implement
> >> at the same time. For example we can add fingerprint (hash) to every
> query
> >> which will be used to join "map" and "reduce" parts with each other and
> add
> >> the following basic metrics:
> >> 1) Execution count for particular query
> >> 2) Number of map nodes - min, max, avg
> >>
> >
> > (1) and (2) makes sense
> >
> >
> >> 3) Map step duration (if applicable) - min, max,
> >
> > 4) Reduce step duration (if applicable) - min, max, avg
> >>
> >
> > Not sure if (3) and (4) are needed. I would only add them if they are
> easy
> > to implement.
> >
> > I would also add these:
> >
> > 5) Collocated: yes/no
> > 6) last execution time
> > 7) min/max/average execution duration
> >
> >
> >>
> >> Once done users will be able to get statistics for particular queries.
> >>
> >> Vladimir.
> >>
> >>
> >> On Tue, Feb 28, 2017 at 3:12 AM, Denis Magda  wrote:
> >>
> >>> BTW,
> >>>
> >>> What if we expose per-query metrics below as a part of EXPLAIN ANALYZE?
> >>> Sergi, is this feasible?
> >>>
> >>> —
> >>> Denis
> >>>
>  On Feb 27, 2017, at 2:35 PM, Denis Magda  wrote:
> 
>  Igniters,
> 
>  Let’s shed more light on SQL query execution internals introducing a
> >> set
> >>> of useful metrics (https://issues.apache.org/jira/browse/IGNITE-4757).
> 
>  Per-query metrics. Total history size is defined by
> >> *CacheConfiguration.
> >>> getQueryDetailMetricsSize*:
>  * if a query was executed in the collocated or non-collocated mode.
> >>> Three results are valid: collocated, non-collocated, simple query (no
> >>> joins).
>  * non-collocated query: size of the data exchanged between the nodes
> to
> >>> complete a join.
>  * non-collocated query: did a query do broadcast or unicast to get
> data
> >>> needed to complete a join.
>  * non-collocated and collocated query: a part of the time spent
> joining
> >>> the data.
> 
>  CacheMetrics:
>  * an average number of executed SQL queries (collocated,
> >> non-collocated,
> >>> simple query (no joins)).
> 
>  Please don’t hesitate do share suggest another metrics or improve
> >>> proposed ones.
> 
>  —
>  Denis
>
>

Re: IGNITE-13

[Вадим Опольский]

Hi Valentin!

I've created:

new method strToUtf8BytesDirect in BinaryUtilsNew
https://github.com/javaller/MyBenchmark/blob/master/src/
main/java/org/sample/BinaryUtilsNew.java

new method doWriteStringDirect in BinaryWriterExImplNew
https://github.com/javaller/MyBenchmark/blob/master/src/
main/java/org/sample/BinaryWriterExImplNew.java

benchmarks for BinaryWriterExImpl doWriteString and BinaryWriterExImplNew
doWriteStringDirect
https://github.com/javaller/MyBenchmark/blob/master/src/
main/java/org/sample/ExampleTest.java

This is a result of comparing:

Benchmark
Mode  Cnt   Score   Error
UnitsExampleTest.binaryHeapOutputStreamDirect  avgt   50  1128448,743 ±
13536,689  ns/opExampleTest.binaryHeapOutputStreamInDirect  avgt   50
1127270,695 ± 17309,256  ns/op

Vadim

2017-03-02 1:02 GMT+03:00 Valentin Kulichenko :

> Hi Vadim,
>
> We're getting closer :) I would actually like to see the test for actual
> implementation of BinaryWriterExImpl#doWriteString method. Logic in
> binaryHeapOutputInDirect() confuses me a bit and I'm not sure comparison is
> valid.
>
> Can you please do the following:
>
> 1. Create new BinaryUtils#strToUtf8BytesDirect method, copy-paste the
> code from existing BinaryUtils#strToUtf8Bytes and modify it so that it
> takes BinaryOutputStream as an argument and writes to it directly. Do not
> create stream inside this method, as it's the same as creating new array.
> 2. Create new BinaryWriterExImpl#doWriteStringDirect, copy-paste the code
> from existing BinaryWriterExImpl#doWriteString and modify it so that it
> uses BinaryUtils#strToUtf8BytesDirect and doesn't call out.writeByteArray.
> 3. Create benchmark for BinaryWriterExImpl#doWriteString method. I.e.,
> create an instance of BinaryWriterExImpl and call doWriteString() in
> benchmark method.
> 4. Similarly, create benchmark for BinaryWriterExImpl#doWriteStringDirect.
> 5. Compare results.
>
> This will give us clear picture of how these two approaches perform. Your
> current results are actually promising, but I would like to confirm them.
>
> -Val
>
> On Wed, Mar 1, 2017 at 6:17 AM, Вадим Опольский 
> wrote:
>
>> Hi Valentin!
>>
>> Thank you for comments.
>>
>> There is a new method which writes directly to BinaryOutputStream instead
>> of intermediate array.
>> https://github.com/javaller/MyBenchmark/blob/master/src/main
>> /java/org/sample/BinaryUtilsNew.java
>>
>> There is benchmark.
>> https://github.com/javaller/MyBenchmark/blob/master/src/main
>> /java/org/sample/MyBenchmark.java
>>
>> Unit test
>> https://github.com/javaller/MyBenchmark/blob/master/src/main
>> /java/org/sample/BinaryOutputStreamTest.java
>>
>> Statistics
>> https://github.com/javaller/MyBenchmark/blob/master/out_01_03_17.txt
>>
>> Benchmark
>>  Mode   CntScoreError  Units MyBenchmark.binaryHeapOutputIn
>> Directavgt  50  111,337 ± 0,742  ns/op
>> MyBenchmark.binaryHeapOutputStreamDirect   avgt  50   23,847 ±
>> 0,303ns/op
>>
>>
>> Vadim
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2017-02-28 4:29 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>>> Hi Vadim,
>>>
>>> Looks like you accidentally removed dev list from the thread, adding it
>>> back.
>>>
>>> I think there is still misunderstanding. What I propose is to modify
>>> the BinaryUtils#strToUtf8Bytes so that it writes directly to 
>>> BinaryOutputStream
>>> instead of intermediate array. This should decrease memory consumption and
>>> can also increase performance as we will avoid 'writeByteArray' step at
>>> the end.
>>>
>>> Does it make sense to you?
>>>
>>> -Val
>>>
>>> On Mon, Feb 27, 2017 at 6:55 AM, Вадим Опольский 
>>> wrote:
>>>
 Hi, Valentin!

 What do you think about using the methods of BinaryOutputStream:

 1) writeByteArray(byte[] val)
 2) writeCharArray(char[] val)
 3) write (byte[] arr, int off, int len)

 String val = "Test";
 out.writeByteArray( val.getBytes(UTF_8));

  String val = "Test";
 out.writeCharArray(str.toCharArray());

 String val = "Test"
 InputStream stream = new ByteArrayInputStream(
 exampleString.getBytes(StandartCharsets.UTF_8));
 byte[] buffer = new byte[1024];
 while ((buffer = stream.read()) != -1) {
 out.writeByteArray(buffer);
 }

 What else can we use ?

 Vadim


 2017-02-25 2:21 GMT+03:00 Valentin Kulichenko <
 valentin.kuliche...@gmail.com>:

> Hi Vadim,
>
> Which method implements the approach described in the ticket? From
> what I see, all writeToStringX versions are still encoding into an
> intermediate array and then call out.writeByteArray. What we need to test
> is the approach where bytes are written directly into the stream during
> encoding. Encoding algorithm itself should stay the same for now, 
> otherwise
> we will not know how to interpret the result.
>
> It looks like there is some misunderstanding h

Re: Additional SQL metrics

[Vladimir Ozerov]

Denis,

The main problem with suggested metrics is that they implies that ceratin
internal mechanics work in predefined way. For example, what is JOIN
metrics? There are no guarantees that JOIN in user's query will be
translated to a real physical join. What if several different query
execution pieces happen in parallel? What if we rework our distributed
query engine from pull to push approach for performance reasons and there
will be no JOINs in classical sense?

This is why I think that we should start with very basic things. Something
like:
1) Query exec count
2) Query exec time (first define what "time" means) - min, max, avg
3) Number of bytes exchanged between nodes during query execution
4) Number of returned rows - min, max, avg

Once we have base numbers in place, we can think of carefully integrating
and enhancing all pieces of query execution into more verbose formats,
similar to query plans with relative weights in classical RDBMS systems.

Thoughts?



On Thu, Mar 2, 2017 at 11:31 PM, Denis Magda  wrote:

> Vovan,
>
> Your metrics make perfect sense to me. However, I see a high demand for
> JOINs based metrics especially from those who give a try to non-collocated
> joins in production  and want to measure them somehow. This is why,
> personally, I prefer to see the metrics below in the top priority list as
> well:
>
> if a query was executed in the collocated or non-collocated mode. Three
> results are valid: collocated, non-collocated, simple query (no joins).
> non-collocated query: size of the data exchanged between the nodes to
> complete a specific join. If there are multiple joins in the query we need
> to provide this metric for every of them.
> non-collocated and collocated query: a part of the time spent joining the
> data. If there are multiple joins in the query we need to provide this
> metric for every of them.
>
> As for “unicast” and “broadcast”, agree, let’s ignore it for now.
>
> In any case, can we include timing information (map phase, reduce phase,
> join phase) into an execution plan produced by H2? Are there any
> implementation hooks?
>
> —
> Denis
>
>
> > On Mar 2, 2017, at 12:02 PM, Dmitriy Setrakyan 
> wrote:
> >
> > I think some of the metrics specified by Denis also make sense, so I
> would
> > add them as well. See below...
> >
> > On Thu, Mar 2, 2017 at 12:36 AM, Vladimir Ozerov  >
> > wrote:
> >
> >> Denis,
> >>
> >> Query execution is complex process involving different stages which are
> not
> >> very easy to match with each other. Especially provided that any node
> can
> >> leave topology at any time. Another problem is that engine evolves and
> >> metrics like "did a query do broadcast or unicast" may easily become
> >> useless at some point, because for example there will be neither
> unicast,
> >> nor broadast, but something different. On the other hand I completely
> agree
> >> that performance monitoring is essential part of any mature DBMS.
> >>
> >> I would start with metrics which are both very basic and easy to
> implement
> >> at the same time. For example we can add fingerprint (hash) to every
> query
> >> which will be used to join "map" and "reduce" parts with each other and
> add
> >> the following basic metrics:
> >> 1) Execution count for particular query
> >> 2) Number of map nodes - min, max, avg
> >>
> >
> > (1) and (2) makes sense
> >
> >
> >> 3) Map step duration (if applicable) - min, max,
> >
> > 4) Reduce step duration (if applicable) - min, max, avg
> >>
> >
> > Not sure if (3) and (4) are needed. I would only add them if they are
> easy
> > to implement.
> >
> > I would also add these:
> >
> > 5) Collocated: yes/no
> > 6) last execution time
> > 7) min/max/average execution duration
> >
> >
> >>
> >> Once done users will be able to get statistics for particular queries.
> >>
> >> Vladimir.
> >>
> >>
> >> On Tue, Feb 28, 2017 at 3:12 AM, Denis Magda  wrote:
> >>
> >>> BTW,
> >>>
> >>> What if we expose per-query metrics below as a part of EXPLAIN ANALYZE?
> >>> Sergi, is this feasible?
> >>>
> >>> —
> >>> Denis
> >>>
>  On Feb 27, 2017, at 2:35 PM, Denis Magda  wrote:
> 
>  Igniters,
> 
>  Let’s shed more light on SQL query execution internals introducing a
> >> set
> >>> of useful metrics (https://issues.apache.org/jira/browse/IGNITE-4757).
> 
>  Per-query metrics. Total history size is defined by
> >> *CacheConfiguration.
> >>> getQueryDetailMetricsSize*:
>  * if a query was executed in the collocated or non-collocated mode.
> >>> Three results are valid: collocated, non-collocated, simple query (no
> >>> joins).
>  * non-collocated query: size of the data exchanged between the nodes
> to
> >>> complete a join.
>  * non-collocated query: did a query do broadcast or unicast to get
> data
> >>> needed to complete a join.
>  * non-collocated and collocated query: a part of the time spent
> joining
> >>> the data.
> 
>  CacheMetrics:
>  * an average nu

Re: Additional SQL metrics

[Dmitriy Setrakyan]

Vladimir, are you talking about per-query metrics?

On Thu, Mar 2, 2017 at 1:32 PM, Vladimir Ozerov 
wrote:

> Denis,
>
> The main problem with suggested metrics is that they implies that ceratin
> internal mechanics work in predefined way. For example, what is JOIN
> metrics? There are no guarantees that JOIN in user's query will be
> translated to a real physical join. What if several different query
> execution pieces happen in parallel? What if we rework our distributed
> query engine from pull to push approach for performance reasons and there
> will be no JOINs in classical sense?
>
> This is why I think that we should start with very basic things. Something
> like:
> 1) Query exec count
> 2) Query exec time (first define what "time" means) - min, max, avg
> 3) Number of bytes exchanged between nodes during query execution
> 4) Number of returned rows - min, max, avg
>
> Once we have base numbers in place, we can think of carefully integrating
> and enhancing all pieces of query execution into more verbose formats,
> similar to query plans with relative weights in classical RDBMS systems.
>
> Thoughts?
>
>
>
> On Thu, Mar 2, 2017 at 11:31 PM, Denis Magda  wrote:
>
> > Vovan,
> >
> > Your metrics make perfect sense to me. However, I see a high demand for
> > JOINs based metrics especially from those who give a try to
> non-collocated
> > joins in production  and want to measure them somehow. This is why,
> > personally, I prefer to see the metrics below in the top priority list as
> > well:
> >
> > if a query was executed in the collocated or non-collocated mode. Three
> > results are valid: collocated, non-collocated, simple query (no joins).
> > non-collocated query: size of the data exchanged between the nodes to
> > complete a specific join. If there are multiple joins in the query we
> need
> > to provide this metric for every of them.
> > non-collocated and collocated query: a part of the time spent joining the
> > data. If there are multiple joins in the query we need to provide this
> > metric for every of them.
> >
> > As for “unicast” and “broadcast”, agree, let’s ignore it for now.
> >
> > In any case, can we include timing information (map phase, reduce phase,
> > join phase) into an execution plan produced by H2? Are there any
> > implementation hooks?
> >
> > —
> > Denis
> >
> >
> > > On Mar 2, 2017, at 12:02 PM, Dmitriy Setrakyan 
> > wrote:
> > >
> > > I think some of the metrics specified by Denis also make sense, so I
> > would
> > > add them as well. See below...
> > >
> > > On Thu, Mar 2, 2017 at 12:36 AM, Vladimir Ozerov  > >
> > > wrote:
> > >
> > >> Denis,
> > >>
> > >> Query execution is complex process involving different stages which
> are
> > not
> > >> very easy to match with each other. Especially provided that any node
> > can
> > >> leave topology at any time. Another problem is that engine evolves and
> > >> metrics like "did a query do broadcast or unicast" may easily become
> > >> useless at some point, because for example there will be neither
> > unicast,
> > >> nor broadast, but something different. On the other hand I completely
> > agree
> > >> that performance monitoring is essential part of any mature DBMS.
> > >>
> > >> I would start with metrics which are both very basic and easy to
> > implement
> > >> at the same time. For example we can add fingerprint (hash) to every
> > query
> > >> which will be used to join "map" and "reduce" parts with each other
> and
> > add
> > >> the following basic metrics:
> > >> 1) Execution count for particular query
> > >> 2) Number of map nodes - min, max, avg
> > >>
> > >
> > > (1) and (2) makes sense
> > >
> > >
> > >> 3) Map step duration (if applicable) - min, max,
> > >
> > > 4) Reduce step duration (if applicable) - min, max, avg
> > >>
> > >
> > > Not sure if (3) and (4) are needed. I would only add them if they are
> > easy
> > > to implement.
> > >
> > > I would also add these:
> > >
> > > 5) Collocated: yes/no
> > > 6) last execution time
> > > 7) min/max/average execution duration
> > >
> > >
> > >>
> > >> Once done users will be able to get statistics for particular queries.
> > >>
> > >> Vladimir.
> > >>
> > >>
> > >> On Tue, Feb 28, 2017 at 3:12 AM, Denis Magda 
> wrote:
> > >>
> > >>> BTW,
> > >>>
> > >>> What if we expose per-query metrics below as a part of EXPLAIN
> ANALYZE?
> > >>> Sergi, is this feasible?
> > >>>
> > >>> —
> > >>> Denis
> > >>>
> >  On Feb 27, 2017, at 2:35 PM, Denis Magda  wrote:
> > 
> >  Igniters,
> > 
> >  Let’s shed more light on SQL query execution internals introducing a
> > >> set
> > >>> of useful metrics (https://issues.apache.org/jira/browse/IGNITE-4757
> ).
> > 
> >  Per-query metrics. Total history size is defined by
> > >> *CacheConfiguration.
> > >>> getQueryDetailMetricsSize*:
> >  * if a query was executed in the collocated or non-collocated mode.
> > >>> Three results are valid: collocated, non-collocated, simp

Re: Additional SQL metrics

[Denis Magda]

Vovan,

When I’m speaking of JOIN metrics I’m simply assume that we need to add metrics 
relevant for queries with joins, metrics that will help us get more insights on 
non-collocated and collocated joins execution flow.

> 1) Query exec count
> 2) Query exec time (first define what "time" means) - min, max, avg

Total query execution time might not be helpful in the trickiest cases. What if 
you have multiple joins in your query? How do I know which one contributes to 
the execution most?

So, I would do a breakdown having total time, map time, per-join time, reduce 
time. Hope it’s possible. If it’s unclear how to support everything at the 
first place then it’s a different question. Let’s create several tickets and 
start implementing everything gracefully.

> 3) Number of bytes exchanged between nodes during query execution

It will be really helpful to make a breakdown showing a number of bytes 
exchanged per-join (physical join). Again, if you believe it makes sense to do 
the breakdown later then let’s create an additional ticket for the 2 tier 
metrics then. 

> 4) Number of returned rows - min, max, avg


Plus, let’s add the following to the list:

5) Collocated: yes or no

—
Denis

> On Mar 2, 2017, at 1:32 PM, Vladimir Ozerov  wrote:
> 
> Denis,
> 
> The main problem with suggested metrics is that they implies that ceratin
> internal mechanics work in predefined way. For example, what is JOIN
> metrics? There are no guarantees that JOIN in user's query will be
> translated to a real physical join. What if several different query
> execution pieces happen in parallel? What if we rework our distributed
> query engine from pull to push approach for performance reasons and there
> will be no JOINs in classical sense?
> 
> This is why I think that we should start with very basic things. Something
> like:
> 1) Query exec count
> 2) Query exec time (first define what "time" means) - min, max, avg
> 3) Number of bytes exchanged between nodes during query execution
> 4) Number of returned rows - min, max, avg
> 
> Once we have base numbers in place, we can think of carefully integrating
> and enhancing all pieces of query execution into more verbose formats,
> similar to query plans with relative weights in classical RDBMS systems.
> 
> Thoughts?
> 
> 
> 
> On Thu, Mar 2, 2017 at 11:31 PM, Denis Magda  wrote:
> 
>> Vovan,
>> 
>> Your metrics make perfect sense to me. However, I see a high demand for
>> JOINs based metrics especially from those who give a try to non-collocated
>> joins in production  and want to measure them somehow. This is why,
>> personally, I prefer to see the metrics below in the top priority list as
>> well:
>> 
>> if a query was executed in the collocated or non-collocated mode. Three
>> results are valid: collocated, non-collocated, simple query (no joins).
>> non-collocated query: size of the data exchanged between the nodes to
>> complete a specific join. If there are multiple joins in the query we need
>> to provide this metric for every of them.
>> non-collocated and collocated query: a part of the time spent joining the
>> data. If there are multiple joins in the query we need to provide this
>> metric for every of them.
>> 
>> As for “unicast” and “broadcast”, agree, let’s ignore it for now.
>> 
>> In any case, can we include timing information (map phase, reduce phase,
>> join phase) into an execution plan produced by H2? Are there any
>> implementation hooks?
>> 
>> —
>> Denis
>> 
>> 
>>> On Mar 2, 2017, at 12:02 PM, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> I think some of the metrics specified by Denis also make sense, so I
>> would
>>> add them as well. See below...
>>> 
>>> On Thu, Mar 2, 2017 at 12:36 AM, Vladimir Ozerov > >
>>> wrote:
>>> 
 Denis,
 
 Query execution is complex process involving different stages which are
>> not
 very easy to match with each other. Especially provided that any node
>> can
 leave topology at any time. Another problem is that engine evolves and
 metrics like "did a query do broadcast or unicast" may easily become
 useless at some point, because for example there will be neither
>> unicast,
 nor broadast, but something different. On the other hand I completely
>> agree
 that performance monitoring is essential part of any mature DBMS.
 
 I would start with metrics which are both very basic and easy to
>> implement
 at the same time. For example we can add fingerprint (hash) to every
>> query
 which will be used to join "map" and "reduce" parts with each other and
>> add
 the following basic metrics:
 1) Execution count for particular query
 2) Number of map nodes - min, max, avg
 
>>> 
>>> (1) and (2) makes sense
>>> 
>>> 
 3) Map step duration (if applicable) - min, max,
>>> 
>>> 4) Reduce step duration (if applicable) - min, max, avg
 
>>> 
>>> Not sure if (3) and (4) are needed. I would only add them if they are
>> easy
>>> to impleme

Re: Same Affinity For Same Key On All Caches

[Valentin Kulichenko]

Adding back the dev list.

Folks,

Are there any opinions on the problem discussed here? Do we really need
FairAffinityFunction if it can't guarantee cross-cache collocation?

-Val

On Thu, Mar 2, 2017 at 2:41 PM, vkulichenko 
wrote:

> Hi Alex,
>
> I see your point. Can you please outline its advantages vs rendezvous
> function?
>
> In my view issue discussed here makes it pretty much useless in vast
> majority of use cases, and very error-prone in all others.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Same-Affinity-For-Same-Key-On-All-
> Caches-tp10829p11006.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Same Affinity For Same Key On All Caches

[Denis Magda]

What??? Unbelievable. It sounds like a design flaw to me. Any ideas how to fix?

—
Denis

> On Mar 2, 2017, at 2:43 PM, Valentin Kulichenko 
>  wrote:
> 
> Adding back the dev list.
> 
> Folks,
> 
> Are there any opinions on the problem discussed here? Do we really need 
> FairAffinityFunction if it can't guarantee cross-cache collocation?
> 
> -Val
> 
> On Thu, Mar 2, 2017 at 2:41 PM, vkulichenko  > wrote:
> Hi Alex,
> 
> I see your point. Can you please outline its advantages vs rendezvous
> function?
> 
> In my view issue discussed here makes it pretty much useless in vast
> majority of use cases, and very error-prone in all others.
> 
> -Val
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Same-Affinity-For-Same-Key-On-All-Caches-tp10829p11006.html
>  
> 
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
> 

Re: IGNITE-13

[Valentin Kulichenko]

Vadim,

Looks better now. Can you also try to modify the benchmark so that
marshaller and writer are created outside of the measured method? I.e. the
benchmark methods should be as simple as this:

@Benchmark
public void binaryHeapOutputStreamDirect() throws Exception {
writer.doWriteStringDirect(message);
}

@Benchmark
public void binaryHeapOutputStreamInDirect() throws Exception {
writer.doWriteString(message);
}

In any case, do I understand correctly that it didn't actually make any
performance difference? If so, I think we can close the ticket.

Vova, can you also take a look and provide your thoughts?

-Val

On Thu, Mar 2, 2017 at 1:27 PM, Вадим Опольский 
wrote:

> Hi Valentin!
>
> I've created:
>
> new method strToUtf8BytesDirect in BinaryUtilsNew
> https://github.com/javaller/MyBenchmark/blob/master/src/main
> /java/org/sample/BinaryUtilsNew.java
>
> new method doWriteStringDirect in BinaryWriterExImplNew
> https://github.com/javaller/MyBenchmark/blob/master/src/main
> /java/org/sample/BinaryWriterExImplNew.java
>
> benchmarks for BinaryWriterExImpl doWriteString and BinaryWriterExImplNew
> doWriteStringDirect
> https://github.com/javaller/MyBenchmark/blob/master/src/main
> /java/org/sample/ExampleTest.java
>
> This is a result of comparing:
>
> Benchmark
> Mode  Cnt   Score   Error UnitsExampleTest.
> binaryHeapOutputStreamDirect  avgt   50  1128448,743 ± 13536,689
> ns/opExampleTest.binaryHeapOutputStreamInDirect  avgt   50  1127270,695 ±
> 17309,256  ns/op
>
> Vadim
>
> 2017-03-02 1:02 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
>> Hi Vadim,
>>
>> We're getting closer :) I would actually like to see the test for actual
>> implementation of BinaryWriterExImpl#doWriteString method. Logic in
>> binaryHeapOutputInDirect() confuses me a bit and I'm not sure comparison is
>> valid.
>>
>> Can you please do the following:
>>
>> 1. Create new BinaryUtils#strToUtf8BytesDirect method, copy-paste the
>> code from existing BinaryUtils#strToUtf8Bytes and modify it so that it
>> takes BinaryOutputStream as an argument and writes to it directly. Do not
>> create stream inside this method, as it's the same as creating new array.
>> 2. Create new BinaryWriterExImpl#doWriteStringDirect, copy-paste the
>> code from existing BinaryWriterExImpl#doWriteString and modify it so
>> that it uses BinaryUtils#strToUtf8BytesDirect and doesn't
>> call out.writeByteArray.
>> 3. Create benchmark for BinaryWriterExImpl#doWriteString method. I.e.,
>> create an instance of BinaryWriterExImpl and call doWriteString() in
>> benchmark method.
>> 4. Similarly, create benchmark for BinaryWriterExImpl#doWriteStri
>> ngDirect.
>> 5. Compare results.
>>
>> This will give us clear picture of how these two approaches perform. Your
>> current results are actually promising, but I would like to confirm them.
>>
>> -Val
>>
>> On Wed, Mar 1, 2017 at 6:17 AM, Вадим Опольский 
>> wrote:
>>
>>> Hi Valentin!
>>>
>>> Thank you for comments.
>>>
>>> There is a new method which writes directly to BinaryOutputStream
>>> instead of intermediate array.
>>> https://github.com/javaller/MyBenchmark/blob/master/src/main
>>> /java/org/sample/BinaryUtilsNew.java
>>>
>>> There is benchmark.
>>> https://github.com/javaller/MyBenchmark/blob/master/src/main
>>> /java/org/sample/MyBenchmark.java
>>>
>>> Unit test
>>> https://github.com/javaller/MyBenchmark/blob/master/src/main
>>> /java/org/sample/BinaryOutputStreamTest.java
>>>
>>> Statistics
>>> https://github.com/javaller/MyBenchmark/blob/master/out_01_03_17.txt
>>>
>>> Benchmark
>>>  Mode   CntScoreError  Units MyBenchmark.binaryHeapOutputIn
>>> Directavgt  50  111,337 ± 0,742  ns/op
>>> MyBenchmark.binaryHeapOutputStreamDirect   avgt  50   23,847 ±
>>> 0,303ns/op
>>>
>>>
>>> Vadim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2017-02-28 4:29 GMT+03:00 Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com>:
>>>
 Hi Vadim,

 Looks like you accidentally removed dev list from the thread, adding it
 back.

 I think there is still misunderstanding. What I propose is to modify
 the BinaryUtils#strToUtf8Bytes so that it writes directly to 
 BinaryOutputStream
 instead of intermediate array. This should decrease memory consumption and
 can also increase performance as we will avoid 'writeByteArray' step
 at the end.

 Does it make sense to you?

 -Val

 On Mon, Feb 27, 2017 at 6:55 AM, Вадим Опольский 
 wrote:

> Hi, Valentin!
>
> What do you think about using the methods of BinaryOutputStream:
>
> 1) writeByteArray(byte[] val)
> 2) writeCharArray(char[] val)
> 3) write (byte[] arr, int off, int len)
>
> String val = "Test";
> out.writeByteArray( val.getBytes(UTF_8));
>
>  String val = "Test";
> out.writeCharArray(str.toCharArray());
>
> Strin

Re: Documenting Apache Ignite 1.9 Features

[Denis Magda]

Vovan, Alex P.,

I've cloned JDBC page for version 1.9 and made it hidden:
https://apacheignite.readme.io/docs/jdbc-driver-19

Please add new properties added as a part of IGNITE-4169 to the properties
table there.

I would have done this on my own if I hadn't lost track of what we actually
did :)

--
Denis

On Thu, Mar 2, 2017 at 10:45 AM, Denis Magda  wrote:

> Vovan,
>
> If Alex can’t finish the doc tomorrow could you write a paragraph or so
> about
>
> Data Streamer Mode DML (*Alexander P.*). Please add a section to
>> “Distributed DML” page:
>>https://issues.apache.org/jira/browse/IGNITE-4169
>>
>>
> ?
>
> To be honest I lost track what exactly was supported.
>
> —
> Denis
>
> On Mar 2, 2017, at 8:14 AM, Igor Sapego  wrote:
>
> Denis, I will try to complete my part today.
>
> Best Regards,
> Igor
>
> On Thu, Mar 2, 2017 at 7:12 PM, Denis Magda  wrote:
>
>> Igor, Alex P.,
>>
>> Will you be able to complete your part tomorrow? I’ll highly appreciate
>> this because Prachi and me need some time to do a final review.
>>
>> —
>> Denis
>>
>>
>> Begin forwarded message:
>>
>> *From: *Denis Magda 
>> *Subject: **Documenting Apache Ignite 1.9 Features*
>> *Date: *February 28, 2017 at 11:46:03 AM PST
>> *To: *dev@ignite.apache.org
>> *Cc: *Vladimir Ozerov , "
>> alexander.a.pasche...@gmail.com" , Igor
>> Sapego 
>> *Reply-To: *dev@ignite.apache.org
>>
>> Igniters,
>>
>> We’ve already documented most of the features and improvements except the
>> ones below.
>>
>> Vovan, Igor, Alexander P., please spare some time this week preparing the
>> docs. Once you’re done Prachi and I will do a final review. All the docs
>> have to be ready by the time AI 1.9 gets released officially.
>>
>> 1) Parallel Query Execution (*Vovan*). Please add a section to
>> “Distributed Queries” page:
>>https://issues.apache.org/jira/browse/IGNITE-4106
>>
>> 2) Data Streamer Mode DML (*Alexander P.*). Please add a section to
>> “Distributed DML” page:
>>https://issues.apache.org/jira/browse/IGNITE-4169
>>
>> 3) C++ LoadCache (*Igor*). You can use Java cache store and loading
>> approaches pages as a template:
>>https://issues.apache.org/jira/browse/IGNITE-4670
>>
>> 4) C++ DML and SQL Grid documentation (*Igor*). Please do the same way as
>> Pavel did for .NET:
>>https://issues.apache.org/jira/browse/IGNITE-4620
>>
>> This page might be useful if you don’t remember how we document a new
>> feature that is missing in current release:
>> https://cwiki.apache.org/confluence/display/IGNITE/Documentation
>>
>> —
>> Denis
>>
>>
>>
>
>

general question

[ALEKSEY KUZNETSOV]

Hi all ! What is the difference between local and near transactions
-- 

*Best Regards,*

*Kuznetsov Aleksey*