[jira] [Assigned] (IGNITE-7218) Upgrade Flink version to 1.4.0

[Saikat Maitra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Saikat Maitra reassigned IGNITE-7218:
-

Assignee: Saikat Maitra

> Upgrade Flink version to 1.4.0
> --
>
> Key: IGNITE-7218
> URL: https://issues.apache.org/jira/browse/IGNITE-7218
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Hai Zhou
>Assignee: Saikat Maitra
>Priority: Minor
>
> http://flink.apache.org/news/2017/12/12/release-1.4.0.html
> There are a lot of exciting improvements.
> flink 1.4.0 will not be compatible with scala 2.10, need to switch the 
> packages to use the scala 2.11.



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

[jira] [Commented] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.

[Saikat Maitra (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501303#comment-16501303
 ] 

Saikat Maitra commented on IGNITE-8697:
---

Hi, 
 
When Ignite Sink Data Streamer start it checks if the cache name is already 
present in the grid before the streaming process can begin.
 
Can you please confirm if cache got created before data sink process get 
executed
 
Regards,
Saikat

> Flink sink throws java.lang.IllegalArgumentException when running in flink 
> cluster mode.
> 
>
> Key: IGNITE-8697
> URL: https://issues.apache.org/jira/browse/IGNITE-8697
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Ray
>Assignee: Roman Shtykh
>Priority: Blocker
>
> if I submit the Application to the Flink Cluster using Ignite flink sink I 
> get this error
>  
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.ignite.sink.flink.IgniteSink$SinkContext.getStreamer(IgniteSink.java:201)
>   at 
> org.apache.ignite.sink.flink.IgniteSink$SinkContext.access$100(IgniteSink.java:175)
>   at org.apache.ignite.sink.flink.IgniteSink.invoke(IgniteSink.java:165)
>   at 
> org.apache.flink.streaming.api.functions.sink.SinkFunction.invoke(SinkFunction.java:52)
>   at 
> org.apache.flink.streaming.api.operators.StreamSink.processElement(StreamSink.java:56)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
>   at 
> org.apache.flink.streaming.api.operators.TimestampedCollector.collect(TimestampedCollector.java:51)
>   at 
> org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:97)
>   at 
> org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:1)
>   at 
> org.apache.flink.streaming.api.operators.StreamFlatMap.processElement(StreamFlatMap.java:50)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
>   at 
> org.apache.flink.streaming.api.operators.StreamSourceContexts$NonTimestampContext.collect(StreamSourceContexts.java:104)
>   at 
> org.apache.flink.streaming.api.functions.source.SocketTextStreamFunction.run(SocketTextStreamFunction.java:110)
>   at 
> org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:87)
>   at 
> org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:56)
>   at 
> org.apache.flink.streaming.runtime.tasks.SourceStreamTask.run(SourceStreamTask.java:99)
>   at 
> org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:306)
>   at org.apache.flink.runtime.taskmanager.Task.run(Task.java:703)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid: 
> Cache name must not be null or empty.
>   at 
> org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1581)
>   at 
> org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3284)
>   at 
> org.apache.ignite.sink.flink.IgniteSink$SinkContext$Holder.(IgniteSink.java:183)
>   ... 27 more



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

[jira] [Assigned] (IGNITE-8695) RPM|DEB: Remove requirement to run Ignite stand-along under root

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov reassigned IGNITE-8695:


Assignee: (was: Peter Ivanov)

> RPM|DEB: Remove requirement to run Ignite stand-along under root
> 
>
> Key: IGNITE-8695
> URL: https://issues.apache.org/jira/browse/IGNITE-8695
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Priority: Critical
> Fix For: 2.6
>
>
> If Ignite is started as a stand-alone process we require to do that under the 
> root user:
> https://apacheignite.readme.io/docs/getting-started#section-run-ignite-as-a-stand-alone-process
> Noone would do that in prod. We need to remove this requirement.



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

[jira] [Created] (IGNITE-8698) Presto can't query tables in ignite with '_' in name.

[arklet (JIRA)]

arklet created IGNITE-8698:
--

 Summary: Presto can't query tables in ignite with '_' in name.
 Key: IGNITE-8698
 URL: https://issues.apache.org/jira/browse/IGNITE-8698
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.5, 2.4
 Environment: Presto plugin
Reporter: arklet
 Attachments: presto-ignite.jar

I tried to implement a plugin for presto to connect ignite.  Presto can list 
information_schema and public two schema. I have some tables in public schema 
that with underlines in the name. But,these tables can't be found in the table 
information_schema.columns. And, these tables can't be queried in the presto. 



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

[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures

[Amir Akhmedov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501233#comment-16501233
 ] 

Amir Akhmedov commented on IGNITE-640:
--

Hi [~avinogradov],

Thanks for your time to review and comment my changes. Please find below my 
comments:
 # I think Map and Set look similar at first glance but in general they 
implement two different interfaces which has nothing in common. In terms of 
Ignite we can build similar infrastructure on CacheDataStructuresManager and 
DataStructuresProcessor levels but I doubt we can come up with generic easy 
maintainable design for both of them.
 # Agree. I could say the methods queue0 and multimap0 in 
CacheDataStructuresManager are identical and would be nice to merge them into 
one but I can't make my mind how to do this cause despite having the similar 
flow those methods operate with different object types, arguments, predicates 
etc. If you have an idea how to converge them would be happy to listen to it.
 # Fixed.
 # Fixed in most places. Will look more carefully in next days.
 # Fixed.
 # Sorry, I'm not following. Can you please put more details how 
GridCacheMultimapApiSelfAbstractTest could be shortened?
 # Fixed.
 # Fixed.
 # I tried my best and did something wrong, now my PR looks ugly :) I don't 
know can it be reverted back or not.

Please let me know if you have any other inquiries or concerns.

 

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.6
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to 
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
>  and its implementation, 
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value 
> under a separate key in an Ignite cache. For example, let's say that we have 
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should 
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. 
> This means that we need to wrap user key into our own, internal key, which 
> will also have {{index}} field. 
> Also note that we need to collocate all the values for the same key on the 
> same node, which means that we need to define user key K as the affinity key, 
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a 
> specific index to a key and do a cache lookup. Look ups for all values for a 
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the 

[jira] [Created] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.

[Ray (JIRA)]

Ray created IGNITE-8697:
---

 Summary: Flink sink throws java.lang.IllegalArgumentException when 
running in flink cluster mode.
 Key: IGNITE-8697
 URL: https://issues.apache.org/jira/browse/IGNITE-8697
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5, 2.4, 2.3
Reporter: Ray
Assignee: Roman Shtykh


if I submit the Application to the Flink Cluster using Ignite flink sink I get 
this error

 
java.lang.ExceptionInInitializerError
at 
org.apache.ignite.sink.flink.IgniteSink$SinkContext.getStreamer(IgniteSink.java:201)
at 
org.apache.ignite.sink.flink.IgniteSink$SinkContext.access$100(IgniteSink.java:175)
at org.apache.ignite.sink.flink.IgniteSink.invoke(IgniteSink.java:165)
at 
org.apache.flink.streaming.api.functions.sink.SinkFunction.invoke(SinkFunction.java:52)
at 
org.apache.flink.streaming.api.operators.StreamSink.processElement(StreamSink.java:56)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
at 
org.apache.flink.streaming.api.operators.TimestampedCollector.collect(TimestampedCollector.java:51)
at 
org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:97)
at 
org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:1)
at 
org.apache.flink.streaming.api.operators.StreamFlatMap.processElement(StreamFlatMap.java:50)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
at 
org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
at 
org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
at 
org.apache.flink.streaming.api.operators.StreamSourceContexts$NonTimestampContext.collect(StreamSourceContexts.java:104)
at 
org.apache.flink.streaming.api.functions.source.SocketTextStreamFunction.run(SocketTextStreamFunction.java:110)
at 
org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:87)
at 
org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:56)
at 
org.apache.flink.streaming.runtime.tasks.SourceStreamTask.run(SourceStreamTask.java:99)
at 
org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:306)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:703)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid: Cache 
name must not be null or empty.
at 
org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1581)
at 
org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3284)
at 
org.apache.ignite.sink.flink.IgniteSink$SinkContext$Holder.(IgniteSink.java:183)
... 27 more



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

[jira] [Commented] (IGNITE-8696) control.sh utility does not show atomicity mode

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501108#comment-16501108
 ] 

ASF GitHub Bot commented on IGNITE-8696:


GitHub user macrergate opened a pull request:

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

IGNITE-8696 add cache atomicity to cache list info



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

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

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

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


commit aeb6cdea855a074c94314f25c20adf8700c23277
Author: Sergey Kosarev 
Date:   2018-06-05T01:09:08Z

IGNITE-8696 add cache atomicity to cache list info




> control.sh utility does not show atomicity mode
> ---
>
> Key: IGNITE-8696
> URL: https://issues.apache.org/jira/browse/IGNITE-8696
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Minor
> Fix For: 2.6
>
>
> In current implementation cache viewer list function:
> ./control.sh --cache list
> does not show atomicity mode for caches. Please add this to the output.



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

[jira] [Created] (IGNITE-8696) control.sh utility does not show atomicity mode

[Sergey Kosarev (JIRA)]

Sergey Kosarev created IGNITE-8696:
--

 Summary: control.sh utility does not show atomicity mode
 Key: IGNITE-8696
 URL: https://issues.apache.org/jira/browse/IGNITE-8696
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Sergey Kosarev
Assignee: Sergey Kosarev
 Fix For: 2.6


In current implementation cache viewer list function:

./control.sh --cache list

does not show atomicity mode for caches. Please add this to the output.



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

[jira] [Commented] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500954#comment-16500954
 ] 

ASF GitHub Bot commented on IGNITE-8693:


Github user asfgit closed the pull request at:

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


> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8693
> URL: https://issues.apache.org/jira/browse/IGNITE-8693
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.6
>
>
> One case of such problem is reproduced by 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (IGNITE-7766).
> If PARTITIONED cache has NodeFilter and is located on subset of REPLICATED 
> cache nodes, we might fail to execute SQL JOIN query with "Caches have 
> distinct sets of data nodes" error. Whether if will fail or not depends on 
> order of *cacheIds* List argument in 
> GridReduceQueryExecutor.stableDataNodes(...) - we will fail if first cacheId 
> is REPLICATED. The order depends on internal factors that are out of user's 
> control.



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

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500933#comment-16500933
 ] 

Ryabov Dmitrii commented on IGNITE-602:
---

[~agura], I have updated branch with fresh master less than 2 weeks ago, so PR 
is up to date (at least github says there is no conflicts) and recursion is 
merged with collection limits now. Of course, I refreshed tests on TC, they are 
looks good.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Created] (IGNITE-8695) RPM|DEB: Remove requirement to run Ignite stand-along under root

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8695:
---

 Summary: RPM|DEB: Remove requirement to run Ignite stand-along 
under root
 Key: IGNITE-8695
 URL: https://issues.apache.org/jira/browse/IGNITE-8695
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Peter Ivanov
 Fix For: 2.6


If Ignite is started as a stand-alone process we require to do that under the 
root user:
https://apacheignite.readme.io/docs/getting-started#section-run-ignite-as-a-stand-alone-process

Noone would do that in prod. We need to remove this requirement.



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

[jira] [Commented] (IGNITE-8290) Activation message handling fails with AssertionError sporadically.

[Andrey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500750#comment-16500750
 ] 

Andrey Kuznetsov commented on IGNITE-8290:
--

Currently, {{IgnitePdsWholeClusterRestartTest}} does not cause the assertion 
mentioned to fail. I could not reproduce this neither on my dev box nor on 
TeamCity. [~amashenkov], could you share some other tests that break the same 
assertion?

> Activation message handling fails with AssertionError sporadically.
> ---
>
> Key: IGNITE-8290
> URL: https://issues.apache.org/jira/browse/IGNITE-8290
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrew Mashenkov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Attachments: disco-msg-fails-2.stack, disco-msg-fails.stack
>
>
> Some test fails sporadically due to AssertionError while processing custom 
> discovery message which can leads to grid and tests handing.
> PFA stacktraces.
> org.apache.ignite.internal.processors.cache.persistence.db.IgnitePdsWholeClusterRestartTest
>  is a good startpoint.
> However, the test passes at master, it's every run logs lot of 
> AssertionErrors .



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

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500595#comment-16500595
 ] 

Andrey Gura commented on IGNITE-602:


This changes requires reintegration with master branch due to a lot of changes.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Comment Edited] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500595#comment-16500595
 ] 

Andrey Gura edited comment on IGNITE-602 at 6/4/18 5:41 PM:


This changes require reintegration with master branch due to a lot of changes.


was (Author: agura):
This changes requires reintegration with master branch due to a lot of changes.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Comment Edited] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500595#comment-16500595
 ] 

Andrey Gura edited comment on IGNITE-602 at 6/4/18 5:41 PM:


This changes require reintegration with master branch and retesting due to a 
lot of changes.


was (Author: agura):
This changes require reintegration with master branch due to a lot of changes.

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Commented] (IGNITE-8642) Failure processor should dump state of all threads

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500580#comment-16500580
 ] 

Andrey Gura commented on IGNITE-8642:
-

[~andrey-kuznetsov] Please rename {{IGNITE_DUMP_THREADS_ON_FAILURE_PROP}} 
property to {{IGNITE_DUMP_THREADS_ON_FAILURE}} and move it to 
{{IgniteSystemProperties}}. Also properly comment added properties.

> Failure processor should dump state of all threads
> --
>
> Key: IGNITE-8642
> URL: https://issues.apache.org/jira/browse/IGNITE-8642
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> Failure processor should dump state of all threads before failure handler is 
> invoked.
> Use {{org.apache.ignite.internal.util.IgniteUtils#dumpThreads}} method.



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

[jira] [Commented] (IGNITE-8690) Missed package-info for some packages

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500480#comment-16500480
 ] 

Andrey Gura commented on IGNITE-8690:
-

Guys, in the future please just exclude `internal`-packages from package info 
checking.

> Missed package-info for some packages
> -
>
> Key: IGNITE-8690
> URL: https://issues.apache.org/jira/browse/IGNITE-8690
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> List of affected packages:
> {noformat}
> org.apache.ignite.spi.communication.tcp.internal
> org.apache.ignite.spi.discovery.zk
> org.apache.ignite.spi.discovery.zk.internal
> org.apache.ignite.ml.structures.partition
> {noformat}



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

[jira] [Commented] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500431#comment-16500431
 ] 

Ivan Rakov commented on IGNITE-8682:


[~agoncharuk], please take a look.

> Attempt to configure IGFS in persistent mode without specific data region 
> ends with AssertionError
> --
>
> Key: IGNITE-8682
> URL: https://issues.apache.org/jira/browse/IGNITE-8682
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> If persistence is enabled and data region name is not specified in IGFS 
> configuration, attempt to access IGFS internal cache results in the following 
> error:
> {noformat}
> [00:40:03]W:java.lang.AssertionError
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:40:03]W:  at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:40:03]W:  at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Assigned] (IGNITE-8509) A lot of "Execution timeout" result for Cache 6 suite

[Alexei Scherbakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexei Scherbakov reassigned IGNITE-8509:
-

Assignee: Alexei Scherbakov

> A lot of "Execution timeout" result for Cache 6 suite
> -
>
> Key: IGNITE-8509
> URL: https://issues.apache.org/jira/browse/IGNITE-8509
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Alexei Scherbakov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> *Summary*
> Suite Cache 6 fails with execution timeout fails with
> {code:java}
> [org.apache.ignite:ignite-core] [2018-05-15 02:35:14,143][WARN 
> ][grid-timeout-worker-#71656%transactions.TxRollbackOnTimeoutNearCacheTest0%][diagnostic]
>  Found long running transaction [startTime=02:32:57.989, 
> curTime=02:35:14.136, tx=GridDhtTxRemote
> {code}
> *Please, fefer for more details* 
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6=1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E]
> *Statistics Cache 6 Suite*
>  Recent fails : 42,0% [21 fails / 50 runs]; 
>  Critical recent fails: 10,0% [5 fails / 50 runs];
> Last mounth (15.04 – 15.05)
> Execution timeout: 21,0% [84 fails / 400 runs];



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

[jira] [Assigned] (IGNITE-8570) Create lighter version of GridStringLogger

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-8570:


Assignee: Alexey Kuznetsov

> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> Most usages of {{GridStringLogger}} in test assumes the following scenario. 
> First, it is set as a logger for some Ignite node. Then, after some activity 
> on that node, log content is searched for some predefined strings. 
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to 
> store log contents, older contents gets dropped on exaustion. Thus, changes 
> that add more logging may damage some independent tests that use 
> {{GridStringLogger}}.
> The suggestion is to implement and use another test logger conforming to 
> these requirements:
> * It does not accumulate any logs.
> * It allows to set the listener that fires when log message matches certain 
> regular expression, {{Matcher}} can be passed to the listener.



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

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Alexey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500374#comment-16500374
 ] 

Alexey Kuznetsov commented on IGNITE-602:
-

[~SomeFire] looks good to me

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



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

[jira] [Commented] (IGNITE-8562) Turn system-critical Ignite threads into GridWorkers

[Andrey Gura (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500375#comment-16500375
 ] 

Andrey Gura commented on IGNITE-8562:
-

[~andrey-kuznetsov] I've reviewed your changes. Please see my comments in 
Upsource.

> Turn system-critical Ignite threads into GridWorkers
> 
>
> Key: IGNITE-8562
> URL: https://issues.apache.org/jira/browse/IGNITE-8562
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> The goal of the change is to make system-critical threads (in terms of 
> IEP-14, [1]) available to {{WorkersControlMXBean}}.
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling



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

[jira] [Updated] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8693:
---
Fix Version/s: 2.6

> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8693
> URL: https://issues.apache.org/jira/browse/IGNITE-8693
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
> Fix For: 2.6
>
>
> One case of such problem is reproduced by 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (IGNITE-7766).
> If PARTITIONED cache has NodeFilter and is located on subset of REPLICATED 
> cache nodes, we might fail to execute SQL JOIN query with "Caches have 
> distinct sets of data nodes" error. Whether if will fail or not depends on 
> order of *cacheIds* List argument in 
> GridReduceQueryExecutor.stableDataNodes(...) - we will fail if first cacheId 
> is REPLICATED. The order depends on internal factors that are out of user's 
> control.



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

[jira] [Resolved] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov resolved IGNITE-8694.

Resolution: Duplicate

Clone of IGNITE-8693

> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8694
> URL: https://issues.apache.org/jira/browse/IGNITE-8694
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> We already have IGNITE-7766 where TC test fails due to the same problem.
> Particular case with PARTITIONED and REPLICATED caches will be fixed under 
> this ticket, while rest of the work will be completed under IGNITE-7766.



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

[jira] [Commented] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500355#comment-16500355
 ] 

ASF GitHub Bot commented on IGNITE-8694:


GitHub user glukos opened a pull request:

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

IGNITE-8694 SQL JOIN between PARTITIONED and REPLICATED cache fails

Signed-off-by: Ivan Rakov 

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

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

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

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


commit 78085fdb2f40747840d4a4b72b67de80d10e1afd
Author: Ivan Rakov 
Date:   2018-06-04T15:12:10Z

IGNITE-8694 SQL JOIN between PARTITIONED and REPLICATED cache fails

Signed-off-by: Ivan Rakov 




> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8694
> URL: https://issues.apache.org/jira/browse/IGNITE-8694
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> We already have IGNITE-7766 where TC test fails due to the same problem.
> Particular case with PARTITIONED and REPLICATED caches will be fixed under 
> this ticket, while rest of the work will be completed under IGNITE-7766.



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

[jira] [Commented] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500340#comment-16500340
 ] 

Ivan Rakov commented on IGNITE-7766:


Please note that particular case of this issue is fixed under IGNITE-8694. Test 
from description should pass after IGNITE-8694 merge.

> Ignite Queries 2: Test always failed 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
> ---
>
> Key: IGNITE-7766
> URL: https://issues.apache.org/jira/browse/IGNITE-7766
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Dmitriy Pavlov
>Assignee: Evgenii Zagumennov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Ignite Queries 2 
>  IgniteBinaryCacheQueryTestSuite2: 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%)
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts 
>  Current failure: refs/heads/master #345 No changes 11 Feb 18 03:03
> junit.framework.AssertionFailedError: On large page size must retry.
> Last runs fails with 100% probability.



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

[jira] [Commented] (IGNITE-7251) Remove term "fabric" from Ignite deliverables

[Peter Ivanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500341#comment-16500341
 ] 

Peter Ivanov commented on IGNITE-7251:
--

[~dmagda], there was no review, only comments that the way the issue is 
currently implemented -- is the wrong way.

> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
>  Labels: important
> Fix For: 2.6
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release - 
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been 
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as - 
> {{apache-ignite-\{version}-bin}}.



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

[jira] [Updated] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8694:
---
Description: 
We already have IGNITE-7766 where TC test fails due to the same problem.
Particular case with PARTITIONED and REPLICATED cache will be fixed under this 
ticket, while rest of the work will be completed under IGNITE-7766.

  was:
We already have IGNITE-7766 where test fails due to the same problem.
Particular case with PARTITIONED and REPLICATED cache will be fixed under this 
ticket, while rest of the work will be completed under IGNITE-7766.


> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8694
> URL: https://issues.apache.org/jira/browse/IGNITE-8694
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> We already have IGNITE-7766 where TC test fails due to the same problem.
> Particular case with PARTITIONED and REPLICATED cache will be fixed under 
> this ticket, while rest of the work will be completed under IGNITE-7766.



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

[jira] [Updated] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8694:
---
Description: 
We already have IGNITE-7766 where TC test fails due to the same problem.
Particular case with PARTITIONED and REPLICATED caches will be fixed under this 
ticket, while rest of the work will be completed under IGNITE-7766.

  was:
We already have IGNITE-7766 where TC test fails due to the same problem.
Particular case with PARTITIONED and REPLICATED cache will be fixed under this 
ticket, while rest of the work will be completed under IGNITE-7766.


> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8694
> URL: https://issues.apache.org/jira/browse/IGNITE-8694
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> We already have IGNITE-7766 where TC test fails due to the same problem.
> Particular case with PARTITIONED and REPLICATED caches will be fixed under 
> this ticket, while rest of the work will be completed under IGNITE-7766.



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

[jira] [Created] (IGNITE-8694) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8694:
--

 Summary: SQL JOIN between PARTITIONED and REPLICATED cache fails
 Key: IGNITE-8694
 URL: https://issues.apache.org/jira/browse/IGNITE-8694
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.6


We already have IGNITE-7766 where test fails due to the same problem.
Particular case with PARTITIONED and REPLICATED cache will be fixed under this 
ticket, while rest of the work will be completed under IGNITE-7766.



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

[jira] [Commented] (IGNITE-7251) Remove term "fabric" from Ignite deliverables

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500333#comment-16500333
 ] 

Denis Magda commented on IGNITE-7251:
-

[~vveider], have anybody reviewed your changes? I do remember conversations on 
the dev that should have helped you finish the task. Let's finish it for 2.6.

> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
>  Labels: important
> Fix For: 2.6
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release - 
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been 
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as - 
> {{apache-ignite-\{version}-bin}}.



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

[jira] [Updated] (IGNITE-7251) Remove term "fabric" from Ignite deliverables

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7251:
-
Priority: Blocker  (was: Critical)

> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Blocker
>  Labels: important
> Fix For: 2.6
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release - 
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been 
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as - 
> {{apache-ignite-\{version}-bin}}.



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

[jira] [Commented] (IGNITE-8682) Attempt to configure IGFS in persistent mode without specific data region ends with AssertionError

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500329#comment-16500329
 ] 

Ivan Rakov commented on IGNITE-8682:


TC: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F4108%2Fhead

> Attempt to configure IGFS in persistent mode without specific data region 
> ends with AssertionError
> --
>
> Key: IGNITE-8682
> URL: https://issues.apache.org/jira/browse/IGNITE-8682
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> If persistence is enabled and data region name is not specified in IGFS 
> configuration, attempt to access IGFS internal cache results in the following 
> error:
> {noformat}
> [00:40:03]W:java.lang.AssertionError
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:40:03]W:  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:40:03]W:  at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:40:03]W:  at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Updated] (IGNITE-7393) Apache Ignite delivery in RPM / DEB packages (Stage II)

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7393:
-
Summary: Apache Ignite delivery in RPM / DEB packages (Stage II)  (was: 
Apache Ignite delivery in RPM / DEB packages (stage II))

> Apache Ignite delivery in RPM / DEB packages (Stage II)
> ---
>
> Key: IGNITE-7393
> URL: https://issues.apache.org/jira/browse/IGNITE-7393
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
>
> Aggregation task for first stage of preparing Apache Ignite delivery through 
> RPM / DEB packages.
> Steps:
> # Prepare source-based package build procedures for RPM and DEB.
> # Introduce these build procedures to Release Apache Ignite task in PublicTC.
> # Introduce upload / update schemes.



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

[jira] [Updated] (IGNITE-8667) Splitting of dataset to test and training sets

[Anton Dmitriev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Dmitriev updated IGNITE-8667:
---
Description: A mandatory part of any ML task is splitting dataset on test 
and train subsets. The goal of this issues is to implement this splitting based 
on ability to filter upstream cache entries that was added in IGNITE-8666.   
(was: One mandatory part of any ML task solving is splitting dataset on test 
and train subsets. The goal of this issues is to implement such splitting based 
on )

> Splitting of dataset to test and training sets
> --
>
> Key: IGNITE-8667
> URL: https://issues.apache.org/jira/browse/IGNITE-8667
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.6
>
>
> A mandatory part of any ML task is splitting dataset on test and train 
> subsets. The goal of this issues is to implement this splitting based on 
> ability to filter upstream cache entries that was added in IGNITE-8666. 



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

[jira] [Updated] (IGNITE-8667) Splitting of dataset to test and training sets

[Anton Dmitriev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Dmitriev updated IGNITE-8667:
---
Description: One mandatory part of any ML task solving is splitting dataset 
on test and train subsets. The goal of this issues is to implement such 
splitting based on   (was: This splitting should have randomization of data. 
Also we should have the possibility of configure proportion of training and 
test parts.)

> Splitting of dataset to test and training sets
> --
>
> Key: IGNITE-8667
> URL: https://issues.apache.org/jira/browse/IGNITE-8667
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.6
>
>
> One mandatory part of any ML task solving is splitting dataset on test and 
> train subsets. The goal of this issues is to implement such splitting based 
> on 



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

[jira] [Commented] (IGNITE-8667) Splitting of dataset to test and training sets

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500304#comment-16500304
 ] 

ASF GitHub Bot commented on IGNITE-8667:


GitHub user dmitrievanthony opened a pull request:

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

IGNITE-8667 Splitting of dataset to test and training sets



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

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

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

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


commit e392b6acafb3fa2752b77fcd942dc85b482b4bec
Author: Anton Dmitriev 
Date:   2018-05-31T14:57:26Z

IGNITE-8666 Add predicates into CacheBasedDatasetBuilder and 
LocalDatasetBuilder.

commit c50a645e3f3a0e277f98e02916eaf4b62731ff52
Author: Anton Dmitriev 
Date:   2018-05-31T15:08:58Z

IGNITE-8666 Add dataset predicate support to examples.

commit efa7e33ced5e9f313f4b9521aef76568f0e9d1bf
Author: Anton Dmitriev 
Date:   2018-05-31T15:09:08Z

IGNITE-8666 Add dataset predicate support to examples.

commit 737738febe0bedd8ceb362f6204b6a0d79679579
Author: Anton Dmitriev 
Date:   2018-05-31T15:26:13Z

IGNITE-8666 Add constructor with default predicate to CacheBased and Local 
Dataset Builders.

commit 28565c356057bc36c09fc17c8daf7aa3e2827eb5
Author: Anton Dmitriev 
Date:   2018-05-31T16:18:17Z

IGNITE-8666 Use default ScanQuery filter instead of custom cursor wrapper.

commit a7932692789b3ef59bfb713839bffb9b73aa0597
Author: dmitrievanthony 
Date:   2018-05-31T20:30:36Z

IGNITE-8666 Use default transformer instead of UpstreamCursorAdapter.

commit f77f13e9c7698be7bd0176d9f531875c572cd4d3
Author: dmitrievanthony 
Date:   2018-05-31T20:49:32Z

IGNITE-8666 Use default constructs of CacheBased and Local Dataset Builders.

commit e6eb7473645ed0bf248f7c4badd87ac4c20e34d4
Author: dmitrievanthony 
Date:   2018-05-31T20:52:58Z

IGNITE-8666 Fix code style.

commit b9e8a105a61912f9e7ceb6064d5528ba12f017b1
Author: Anton Dmitriev 
Date:   2018-06-01T08:06:49Z

IGNITE-8666 Add KNNRegressionTrainer to trainers hierarchy.

commit dd09c0a809c81c34a6ae8ac95278080565965b47
Author: Anton Dmitriev 
Date:   2018-06-01T08:23:34Z

IGNITE-8666 Fix javadoc in ComputeUtils class.

commit a004bf20342fef500045f830e821954616a2164b
Author: Anton Dmitriev 
Date:   2018-06-01T09:10:04Z

IGNITE-8666 Add concurrent modification checker to dataset builders.

commit 88b2483cf3a601935140f43edafe2e13b03506eb
Author: Anton Dmitriev 
Date:   2018-06-01T09:32:54Z

Merge branch 'ignite-8666' into ignite-8667

commit c2291f3e01b98c3f22a57652ecab500e67e29aef
Author: Anton Dmitriev 
Date:   2018-06-01T11:23:29Z

IGNITE-8666 Rename pred -> filter.

commit 05b527dd346cdedf3e2f823a6a5761d240ff381a
Author: Anton Dmitriev 
Date:   2018-06-01T11:24:49Z

Merge branch 'ignite-8666' into ignite-8667

commit 7bab5832d5a94f0f9f46f17286161b2738538179
Author: Anton Dmitriev 
Date:   2018-06-01T13:37:16Z

IGNITE-8667 First version of TrainTest dataset splitter.

commit 206a9cbaf132ea515b3e8aa7b3832df3332d2c71
Author: Anton Dmitriev 
Date:   2018-06-04T14:27:49Z

IGNITE-8667 Add unified mapper for train test splitter and tests.

commit fe6a7f05eb0926f8bfc07885c6f6ed3ab335956f
Author: Anton Dmitriev 
Date:   2018-06-04T14:34:45Z

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

# Conflicts:
#   
modules/ml/src/main/java/org/apache/ignite/ml/dataset/impl/cache/util/ComputeUtils.java




> Splitting of dataset to test and training sets
> --
>
> Key: IGNITE-8667
> URL: https://issues.apache.org/jira/browse/IGNITE-8667
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.6
>
>
> This splitting should have randomization of data. Also we should have the 
> possibility of configure proportion of training and test parts.



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

[jira] [Commented] (IGNITE-8645) CacheMetrics.getCacheTxCommits() doesn't include transactions started on client node

[Alexey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500300#comment-16500300
 ] 

Alexey Kuznetsov commented on IGNITE-8645:
--

[~guseinov] , [~kuaw26] hi.
I have nearly fixed cache metrics(now, calling 
_cache(CACHE_NAME).metrics().getCacheTxCommits()_ result in correct value).

But have some problems with fixing Visor metrics.

I propose to create a separate ticket for fixing Visor metrics, and assign it 
to [~kuaw26]

Are you agree ?

> CacheMetrics.getCacheTxCommits() doesn't include transactions started on 
> client node
> 
>
> Key: IGNITE-8645
> URL: https://issues.apache.org/jira/browse/IGNITE-8645
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Roman Guseinov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: CacheTxCommitsMetricTest.java
>
>
> The test is attached [^CacheTxCommitsMetricTest.java]



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

[jira] [Assigned] (IGNITE-8386) SQL: Make sure PK index do not use wrapped object

[Alexander Paschenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Paschenko reassigned IGNITE-8386:
---

Assignee: Alexander Paschenko

> SQL: Make sure PK index do not use wrapped object
> -
>
> Key: IGNITE-8386
> URL: https://issues.apache.org/jira/browse/IGNITE-8386
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
>  Labels: iep-19, performance
> Fix For: 2.6
>
>
> Currently PK may be built over the whole {{_KEY}} column, i.e. the whole 
> binary object. This could happen in two cases:
> 1) Composite PK
> 2) Plain PK but with {{WRAP_KEY}} option.
> This is critical performance issue for two reasons:
> 1) This index is effectively useless and cannot be used in any sensible 
> queries; it just wastes space and makes updates slower
> 2) Binary object typically has common header bytes what may lead to excessive 
> number of comparisons during index update.
> To mitigate the problem we need to ensure that index is *never* built over 
> {{_KEY}}, Instead, we must always extract target columns and build normal 
> index over them.



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

[jira] [Commented] (IGNITE-8610) Searching checkpoint / WAL history for rebalancing is not properly working in case of local/global WAL disabling

[Ilya Lantukh (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500245#comment-16500245
 ] 

Ilya Lantukh commented on IGNITE-8610:
--

Looks good.

> Searching checkpoint / WAL history for rebalancing is not properly working in 
> case of local/global WAL disabling
> 
>
> Key: IGNITE-8610
> URL: https://issues.apache.org/jira/browse/IGNITE-8610
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> After implementation IGNITE-6411 and IGNITE-8087 we can face with situation 
> when after some checkpoint, WAL was temporarily disabled and enabled again. 
> In this case we can't treat that checkpoint as start point to rebalance, 
> because WAL history after such checkpoint may contain gaps.
> We should rework our checkpoint / wal history searching mechanism and ignore 
> such checkpoints.



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

[jira] [Commented] (IGNITE-8690) Missed package-info for some packages

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500208#comment-16500208
 ] 

ASF GitHub Bot commented on IGNITE-8690:


Github user asfgit closed the pull request at:

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


> Missed package-info for some packages
> -
>
> Key: IGNITE-8690
> URL: https://issues.apache.org/jira/browse/IGNITE-8690
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> List of affected packages:
> {noformat}
> org.apache.ignite.spi.communication.tcp.internal
> org.apache.ignite.spi.discovery.zk
> org.apache.ignite.spi.discovery.zk.internal
> org.apache.ignite.ml.structures.partition
> {noformat}



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

[jira] [Commented] (IGNITE-8691) Get rid of tests jar artifact in ignite-zookeeper module

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500207#comment-16500207
 ] 

ASF GitHub Bot commented on IGNITE-8691:


Github user asfgit closed the pull request at:

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


> Get rid of tests jar artifact in ignite-zookeeper module
> 
>
> Key: IGNITE-8691
> URL: https://issues.apache.org/jira/browse/IGNITE-8691
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently Ignite building process produces 
> {noformat}
> org/apache/ignite/ignite-zookeeper/2.X.X/ignite-zookeeper-2.X.X-tests.jar
> {noformat}
> artifact which seems to be useless and should be excluded as result of 
> packaging.



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

[jira] [Updated] (IGNITE-8689) SQL query execution may lead to NullPointerException while node is stopped

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8689:

Attachment: node-B.xml
node-A.xml

> SQL query execution may lead to NullPointerException while node is stopped
> --
>
> Key: IGNITE-8689
> URL: https://issues.apache.org/jira/browse/IGNITE-8689
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Attachments: node-A.xml, node-B.xml
>
>
> Let's consider the following scenario:
>  * Start a new node (node 'A') and create a new partitioned cache that 
> resides on that node
> {code:java}
> Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
> IgniteCache cache = ignite.getOrCreateCache(new 
> CacheConfiguration()
> .setName("default")
> .setIndexedTypes(String.class, String.class)
> .setNodeFilter(new NodeFilter())
> );
> public class NodeFilter implements IgnitePredicate {
> @Override public boolean apply(ClusterNode node) {
> return node.attribute("test.attribute").equals("first-node");
> }
> }{code}
>  * Start the second node (node 'B') with a custom connector configuration:
> {code:java}
> 
>  class="org.apache.ignite.configuration.ClientConnectorConfiguration">
> 
> 
> 
> 
> 
> Ignite ignite = Ignition.start("examples/config/segmentation/node-B.xml");
> Executors.newScheduledThreadPool(1).schedule(
> new Runnable() {
> @Override public void run() {
> DiscoverySpi spi = ignite.configuration().getDiscoverySpi();
> spi.failNode(ignite.cluster().localNode().id(), "test message");
> }
> },
> 30,
> TimeUnit.SECONDS);{code}
>  * Execute simple SQL query using sqlline for example (JDBC driver should be 
> connected to the node 'B')
> {code:java}
> ./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2
> select * from UNKNOWN_TABLE;{code}
> In that case, {{IgniteH2Indexing.prepareStatement()}} throws 
> {{SQLException(Table is not found)}} and the implementation tries to start 
> caches that are not started yet by sending 
> {{ClientCacheChangeDummyDiscoveryMessage}} to 'discovery-worker' thread,
> which in turn posts that message to 'exchange-worker' thread.
> Assume that while processing of {{ClientCacheChangeDummyDiscoveryMessage}} by 
> the 'exchange-worker', the discovery thread receives {{EVT_NODE_FAILED}} (as 
> a result of segmentation) and so {{DiscoCache}} history is updated by 
> removing the failed node from the list of alive nodes.
> At the same time, 'exchange-worker' detects that there is only one alive node 
> (node 'B' in our case) and mistakenly believes that node 'B' is a coordinator:
> {code:java|title=CacheAffinitySharedManager.java}
> void processClientCachesChanges(ClientCacheChangeDummyDiscoveryMessage 
> msg) {
> AffinityTopologyVersion topVer = 
> cctx.exchange().readyAffinityVersion();
> DiscoCache discoCache = cctx.discovery().discoCache(topVer);
> boolean crd = 
> cctx.localNode().equals(discoCache.oldestAliveServerNode()); // discoCache 
> contains only the one node!
> Map startedCaches = 
> processClientCacheStartRequests(msg, crd, topVer, discoCache);
> Set closedCaches = processCacheCloseRequests(msg, crd, 
> topVer);
> if (startedCaches != null || closedCaches != null)
> scheduleClientChangeMessage(startedCaches, closedCaches);
> }
> {code}
> and results in the following {{NullPointerException}}:
> {code:java}
> [19:25:57,019][ERROR][exchange-worker-#42][GridCachePartitionExchangeManager] 
> Failed to process custom exchange task: 
> ClientCacheChangeDummyDiscoveryMessage 
> [reqId=8c7904a2-4b70-4614-bf7b-f4434d274c30, cachesToClose=null, 
> startCaches=[default-segmented]]
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:458)
> at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:621)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:363)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2207)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2296)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 

[jira] [Updated] (IGNITE-8689) SQL query execution may lead to NullPointerException while node is stopped

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8689:

Summary: SQL query execution may lead to NullPointerException while node is 
stopped  (was: SQL query execution may lead to NullPointerException during node 
stop.)

> SQL query execution may lead to NullPointerException while node is stopped
> --
>
> Key: IGNITE-8689
> URL: https://issues.apache.org/jira/browse/IGNITE-8689
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Priority: Major
>
> Let's consider the following scenario:
>  * Start a new node (node 'A') and create a new partitioned cache that 
> resides on that node
> {code:java}
> Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
> IgniteCache cache = ignite.getOrCreateCache(new 
> CacheConfiguration()
> .setName("default")
> .setIndexedTypes(String.class, String.class)
> .setNodeFilter(new NodeFilter())
> );
> public class NodeFilter implements IgnitePredicate {
> @Override public boolean apply(ClusterNode node) {
> return node.attribute("test.attribute").equals("first-node");
> }
> }{code}
>  * Start the second node (node 'B') with a custom connector configuration:
> {code:java}
> 
>  class="org.apache.ignite.configuration.ClientConnectorConfiguration">
> 
> 
> 
> 
> 
> Ignite ignite = Ignition.start("examples/config/segmentation/node-B.xml");
> Executors.newScheduledThreadPool(1).schedule(
> new Runnable() {
> @Override public void run() {
> DiscoverySpi spi = ignite.configuration().getDiscoverySpi();
> spi.failNode(ignite.cluster().localNode().id(), "test message");
> }
> },
> 30,
> TimeUnit.SECONDS);{code}
>  * Execute simple SQL query using sqlline for example (JDBC driver should be 
> connected to the node 'B')
> {code:java}
> ./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2
> select * from UNKNOWN_TABLE;{code}
> In that case, {{IgniteH2Indexing.prepareStatement()}} throws 
> {{SQLException(Table is not found)}} and the implementation tries to start 
> caches that are not started yet by sending 
> {{ClientCacheChangeDummyDiscoveryMessage}} to 'discovery-worker' thread,
> which in turn posts that message to 'exchange-worker' thread.
> Assume that while processing of {{ClientCacheChangeDummyDiscoveryMessage}} by 
> the 'exchange-worker', the discovery thread receives {{EVT_NODE_FAILED}} (as 
> a result of segmentation) and so {{DiscoCache}} history is updated by 
> removing the failed node from the list of alive nodes.
> At the same time, 'exchange-worker' detects that there is only one alive node 
> (node 'B' in our case) and mistakenly believes that node 'B' is a coordinator:
> {code:java|title=CacheAffinitySharedManager.java}
> void processClientCachesChanges(ClientCacheChangeDummyDiscoveryMessage 
> msg) {
> AffinityTopologyVersion topVer = 
> cctx.exchange().readyAffinityVersion();
> DiscoCache discoCache = cctx.discovery().discoCache(topVer);
> boolean crd = 
> cctx.localNode().equals(discoCache.oldestAliveServerNode()); // discoCache 
> contains only the one node!
> Map startedCaches = 
> processClientCacheStartRequests(msg, crd, topVer, discoCache);
> Set closedCaches = processCacheCloseRequests(msg, crd, 
> topVer);
> if (startedCaches != null || closedCaches != null)
> scheduleClientChangeMessage(startedCaches, closedCaches);
> }
> {code}
> and results in the following {{NullPointerException}}:
> {code:java}
> [19:25:57,019][ERROR][exchange-worker-#42][GridCachePartitionExchangeManager] 
> Failed to process custom exchange task: 
> ClientCacheChangeDummyDiscoveryMessage 
> [reqId=8c7904a2-4b70-4614-bf7b-f4434d274c30, cachesToClose=null, 
> startCaches=[default-segmented]]
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:458)
> at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:621)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:363)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2207)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2296)
> at 

[jira] [Updated] (IGNITE-8689) SQL query execution may lead to NullPointerException during node stop.

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8689:

Description: 
Let's consider the following scenario:
 * Start a new node (node 'A') and create a new partitioned cache that resides 
on that node

{code:java}
Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
IgniteCache cache = ignite.getOrCreateCache(new 
CacheConfiguration()
.setName("default")
.setIndexedTypes(String.class, String.class)
.setNodeFilter(new NodeFilter())
);

public class NodeFilter implements IgnitePredicate {
@Override public boolean apply(ClusterNode node) {
return node.attribute("test.attribute").equals("first-node");
}
}{code}
 * Start the second node (node 'B') with a custom connector configuration:

{code:java}








Ignite ignite = Ignition.start("examples/config/segmentation/node-B.xml");

Executors.newScheduledThreadPool(1).schedule(
new Runnable() {
@Override public void run() {
DiscoverySpi spi = ignite.configuration().getDiscoverySpi();
spi.failNode(ignite.cluster().localNode().id(), "test message");
}
},
30,
TimeUnit.SECONDS);{code}
 * Execute simple SQL query using sqlline for example (JDBC driver should be 
connected to the node 'B')

{code:java}
./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2

select * from UNKNOWN_TABLE;{code}
In that case, {{IgniteH2Indexing.prepareStatement()}} throws 
{{SQLException(Table is not found)}} and the implementation tries to start 
caches that are not started yet by sending 
{{ClientCacheChangeDummyDiscoveryMessage}} to 'discovery-worker' thread,
which in turn posts that message to 'exchange-worker' thread.

Assume that while processing of {{ClientCacheChangeDummyDiscoveryMessage}} by 
the 'exchange-worker', the discovery thread receives {{EVT_NODE_FAILED}} (as a 
result of segmentation) and so {{DiscoCache}} history is updated by removing 
the failed node from the list of alive nodes.
At the same time, 'exchange-worker' detects that there is only one alive node 
(node 'B' in our case) and mistakenly believes that node 'B' is a coordinator:
{code:java|title=CacheAffinitySharedManager.java}
void processClientCachesChanges(ClientCacheChangeDummyDiscoveryMessage msg) 
{
AffinityTopologyVersion topVer = cctx.exchange().readyAffinityVersion();

DiscoCache discoCache = cctx.discovery().discoCache(topVer);

boolean crd = 
cctx.localNode().equals(discoCache.oldestAliveServerNode()); // discoCache 
contains only the one node!

Map startedCaches = 
processClientCacheStartRequests(msg, crd, topVer, discoCache);

Set closedCaches = processCacheCloseRequests(msg, crd, topVer);

if (startedCaches != null || closedCaches != null)
scheduleClientChangeMessage(startedCaches, closedCaches);
}
{code}
and results in the following {{NullPointerException}}:
{code:java}
[19:25:57,019][ERROR][exchange-worker-#42][GridCachePartitionExchangeManager] 
Failed to process custom exchange task: ClientCacheChangeDummyDiscoveryMessage 
[reqId=8c7904a2-4b70-4614-bf7b-f4434d274c30, cachesToClose=null, 
startCaches=[default-segmented]]
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:458)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:621)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:363)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2207)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2296)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}
As a result, the node cannot be stopped due to the following reasons:
 * 'exchange' thread throws {{NullPointerException}} and therefore does not 
complete {{DynamicCacheStartFuture}}
 * 'Client connector' thread is blocked on {{DynamicCacheStatrt.get()}} method 
which never returns control
 * the thread which performs node stopping process is blocked on {{busyLock}}

 Please see the following thread dump:
{code:java}
"Thread-117" #734 prio=5 os_prio=0 tid=0x558b117a9000 nid=0x437 waiting on 
condition [0x7f2466ba1000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at 
org.apache.ignite.internal.util.GridSpinReadWriteLock.writeLock(GridSpinReadWriteLock.java:206)
at 

[jira] [Commented] (IGNITE-8562) Turn system-critical Ignite threads into GridWorkers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500190#comment-16500190
 ] 

ASF GitHub Bot commented on IGNITE-8562:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-8562: Squashed partial commits.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-8562

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

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


commit cf466344de49c24f249e34e718ba4188beb606b6
Author: Andrey Kuznetsov 
Date:   2018-06-04T13:10:18Z

IGNITE-8562: Squashed partial commits.




> Turn system-critical Ignite threads into GridWorkers
> 
>
> Key: IGNITE-8562
> URL: https://issues.apache.org/jira/browse/IGNITE-8562
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> The goal of the change is to make system-critical threads (in terms of 
> IEP-14, [1]) available to {{WorkersControlMXBean}}.
> [1] 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling



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

[jira] [Updated] (IGNITE-8689) SQL query execution may lead to NullPointerException during node stop.

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8689:

Description: 
Let's consider the following scenario:
 # Start a new node (node 'A') and create a new partitioned cache that resides 
on that node

{code:java}
Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
IgniteCache cache = ignite.getOrCreateCache(new 
CacheConfiguration()
.setName("default")
.setIndexedTypes(String.class, String.class)
.setNodeFilter(new NodeFilter())
);

public class NodeFilter implements IgnitePredicate {
@Override public boolean apply(ClusterNode node) {
return node.attribute("test.attribute").equals("first-node");
}
}{code}

 # Start the second node (node 'B') with a custom connector configuration:

{code:java}








Ignite ignite = Ignition.start("examples/config/segmentation/node-B.xml");

Executors.newScheduledThreadPool(1).schedule(
new Runnable() {
@Override public void run() {
DiscoverySpi spi = ignite.configuration().getDiscoverySpi();
spi.failNode(ignite.cluster().localNode().id(), "test message");
}
},
30,
TimeUnit.SECONDS);{code}

 # Execute simple SQL query using sqlline for example (JDBC driver should be 
connected to the node 'B')

{code:java}
./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2

select * from UNKNOWN_TABLE;{code}

In that case, IgniteH2Indexing.prepareStatement() throws SQLException(Table is 
not found) and the implementation tries to start caches that are not started 
yet by sending ClientCacheChangeDummyDiscoveryMessage to discovery worker 
thread,
which in turn posts that message to exchange-worker thread.
Assume that while processing of ClientCacheChangeDummyDiscoveryMessage by the 
exchange-worker, the discovery thread receives EVT_NODE_FAILED (as a result of 
segmentation) and so DiscoCache history is updated by removing the failed node 
from the list of alive nodes.
At the same time, exchange-worker detects that there is only one alive node 
(node 'B' in our case) and mistakenly believes that node 'B' is a coordinator:
and results in the following NullPointerException:

> SQL query execution may lead to NullPointerException during node stop.
> --
>
> Key: IGNITE-8689
> URL: https://issues.apache.org/jira/browse/IGNITE-8689
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Priority: Major
>
> Let's consider the following scenario:
>  # Start a new node (node 'A') and create a new partitioned cache that 
> resides on that node
> {code:java}
> Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
> IgniteCache cache = ignite.getOrCreateCache(new 
> CacheConfiguration()
> .setName("default")
> .setIndexedTypes(String.class, String.class)
> .setNodeFilter(new NodeFilter())
> );
> public class NodeFilter implements IgnitePredicate {
> @Override public boolean apply(ClusterNode node) {
> return node.attribute("test.attribute").equals("first-node");
> }
> }{code}
>  # Start the second node (node 'B') with a custom connector configuration:
> {code:java}
> 
>  class="org.apache.ignite.configuration.ClientConnectorConfiguration">
> 
> 
> 
> 
> 
> Ignite ignite = Ignition.start("examples/config/segmentation/node-B.xml");
> Executors.newScheduledThreadPool(1).schedule(
> new Runnable() {
> @Override public void run() {
> DiscoverySpi spi = ignite.configuration().getDiscoverySpi();
> spi.failNode(ignite.cluster().localNode().id(), "test message");
> }
> },
> 30,
> TimeUnit.SECONDS);{code}
>  # Execute simple SQL query using sqlline for example (JDBC driver should be 
> connected to the node 'B')
> {code:java}
> ./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2
> select * from UNKNOWN_TABLE;{code}
> In that case, IgniteH2Indexing.prepareStatement() throws SQLException(Table 
> is not found) and the implementation tries to start caches that are not 
> started yet by sending ClientCacheChangeDummyDiscoveryMessage to discovery 
> worker thread,
> which in turn posts that message to exchange-worker thread.
> Assume that while processing of ClientCacheChangeDummyDiscoveryMessage by the 
> exchange-worker, the discovery thread receives EVT_NODE_FAILED (as a result 
> of segmentation) and so DiscoCache history is updated by removing the failed 
> node from the list of alive nodes.
> At the same time, exchange-worker detects that there is only one alive node 
> (node 'B' in our case) and mistakenly believes that node 'B' is a 

[jira] [Commented] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ilya Lantukh (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500179#comment-16500179
 ] 

Ilya Lantukh commented on IGNITE-8693:
--

https://ci.ignite.apache.org/viewQueued.html?itemId=1357399

> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8693
> URL: https://issues.apache.org/jira/browse/IGNITE-8693
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> One case of such problem is reproduced by 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (IGNITE-7766).
> If PARTITIONED cache has NodeFilter and is located on subset of REPLICATED 
> cache nodes, we might fail to execute SQL JOIN query with "Caches have 
> distinct sets of data nodes" error. Whether if will fail or not depends on 
> order of *cacheIds* List argument in 
> GridReduceQueryExecutor.stableDataNodes(...) - we will fail if first cacheId 
> is REPLICATED. The order depends on internal factors that are out of user's 
> control.



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

[jira] [Updated] (IGNITE-8689) SQL query execution may lead to NullPointerException during node stop.

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8689:

Description: 
Let's consider the following scenario:
 * Start a new node (node 'A') and create a new partitioned cache that resides 
on that node

{code:java}
Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
IgniteCache cache = ignite.getOrCreateCache(new 
CacheConfiguration()
.setName("default")
.setIndexedTypes(String.class, String.class)
.setNodeFilter(new NodeFilter())
);

public class NodeFilter implements IgnitePredicate {
@Override public boolean apply(ClusterNode node) {
return node.attribute("test.attribute").equals("first-node");
}
}{code}
 * Start the second node (node 'B') with a custom connector configuration:

{code:java}








Ignite ignite = Ignition.start("examples/config/segmentation/node-B.xml");

Executors.newScheduledThreadPool(1).schedule(
new Runnable() {
@Override public void run() {
DiscoverySpi spi = ignite.configuration().getDiscoverySpi();
spi.failNode(ignite.cluster().localNode().id(), "test message");
}
},
30,
TimeUnit.SECONDS);{code}
 * Execute simple SQL query using sqlline for example (JDBC driver should be 
connected to the node 'B')

{code:java}
./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2

select * from UNKNOWN_TABLE;{code}
In that case, IgniteH2Indexing.prepareStatement() throws SQLException(Table is 
not found) and the implementation tries to start caches that are not started 
yet by sending ClientCacheChangeDummyDiscoveryMessage to discovery worker 
thread,
which in turn posts that message to exchange-worker thread.
Assume that while processing of ClientCacheChangeDummyDiscoveryMessage by the 
exchange-worker, the discovery thread receives EVT_NODE_FAILED (as a result of 
segmentation) and so DiscoCache history is updated by removing the failed node 
from the list of alive nodes.
At the same time, exchange-worker detects that there is only one alive node 
(node 'B' in our case) and mistakenly believes that node 'B' is a coordinator:
and results in the following NullPointerException:

  was:
Let's consider the following scenario:
 # Start a new node (node 'A') and create a new partitioned cache that resides 
on that node

{code:java}
Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
IgniteCache cache = ignite.getOrCreateCache(new 
CacheConfiguration()
.setName("default")
.setIndexedTypes(String.class, String.class)
.setNodeFilter(new NodeFilter())
);

public class NodeFilter implements IgnitePredicate {
@Override public boolean apply(ClusterNode node) {
return node.attribute("test.attribute").equals("first-node");
}
}{code}

 # Start the second node (node 'B') with a custom connector configuration:

{code:java}








Ignite ignite = Ignition.start("examples/config/segmentation/node-B.xml");

Executors.newScheduledThreadPool(1).schedule(
new Runnable() {
@Override public void run() {
DiscoverySpi spi = ignite.configuration().getDiscoverySpi();
spi.failNode(ignite.cluster().localNode().id(), "test message");
}
},
30,
TimeUnit.SECONDS);{code}

 # Execute simple SQL query using sqlline for example (JDBC driver should be 
connected to the node 'B')

{code:java}
./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2

select * from UNKNOWN_TABLE;{code}

In that case, IgniteH2Indexing.prepareStatement() throws SQLException(Table is 
not found) and the implementation tries to start caches that are not started 
yet by sending ClientCacheChangeDummyDiscoveryMessage to discovery worker 
thread,
which in turn posts that message to exchange-worker thread.
Assume that while processing of ClientCacheChangeDummyDiscoveryMessage by the 
exchange-worker, the discovery thread receives EVT_NODE_FAILED (as a result of 
segmentation) and so DiscoCache history is updated by removing the failed node 
from the list of alive nodes.
At the same time, exchange-worker detects that there is only one alive node 
(node 'B' in our case) and mistakenly believes that node 'B' is a coordinator:
and results in the following NullPointerException:


> SQL query execution may lead to NullPointerException during node stop.
> --
>
> Key: IGNITE-8689
> URL: https://issues.apache.org/jira/browse/IGNITE-8689
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Priority: Major
>
> Let's consider the following scenario:
>  * Start a new node (node 'A') and create a new 

[jira] [Commented] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500174#comment-16500174
 ] 

ASF GitHub Bot commented on IGNITE-8693:


GitHub user ilantukh opened a pull request:

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

IGNITE-8693 : Fix for SQL JOIN between REPLICATED and PARTITIONED caches

…hes.

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

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

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

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


commit 9b4ae6520c9c701382bc5468141c4b709658f682
Author: Ilya Lantukh 
Date:   2018-06-01T14:01:43Z

ignite-8693 : Fix for SQL JOIN between REPLICATED and PARTITIONED caches.




> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8693
> URL: https://issues.apache.org/jira/browse/IGNITE-8693
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> One case of such problem is reproduced by 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (IGNITE-7766).
> If PARTITIONED cache has NodeFilter and is located on subset of REPLICATED 
> cache nodes, we might fail to execute SQL JOIN query with "Caches have 
> distinct sets of data nodes" error. Whether if will fail or not depends on 
> order of *cacheIds* List argument in 
> GridReduceQueryExecutor.stableDataNodes(...) - we will fail if first cacheId 
> is REPLICATED. The order depends on internal factors that are out of user's 
> control.



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

[jira] [Updated] (IGNITE-8676) Possible data loss after stoping/starting several nodes at the same time

[Stanislav Lukyanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Lukyanov updated IGNITE-8676:
---
Attachment: Ignite8676Test.java

> Possible data loss after stoping/starting several nodes at the same time
> 
>
> Key: IGNITE-8676
> URL: https://issues.apache.org/jira/browse/IGNITE-8676
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DataLossTest.zip, Ignite8676Test.java, 
> image-2018-06-01-12-34-54-320.png, image-2018-06-01-13-12-47-218.png, 
> image-2018-06-01-13-15-17-437.png
>
>
> Steps to reproduce:
> 1)Start 3 data (DN1, DN2, DN3) nodes with the configuration that contains the 
> cache with node filter for only these three nodes and 1 backup. (see 
> configuration from attachment)
>  2)Activate the cluster. Now you should have 3 nodes in BLT
>  3)Start new server node (SN). Now you should have 3 nodes in BLT and 1 node 
> not in the baseline.
>  4)Using some node load about 1 (or more) entities into the cache.
>  5)Start that number of primary partitions equals to backup partitions.
> !image-2018-06-01-12-34-54-320.png!
>  6)Now stop DN3 and SN. After that start them at the same time.
>  7)When DN3 and SN will be online, check that number of primary partitions 
> (PN) equals to backup partitions (BN).
> 7.1)In a case if PN == BN => go to step 6)
>  7.2)In a case if PN != BN => go to step 8)
>  
> !image-2018-06-01-13-12-47-218.png!
> 8)Deactivate the cluster with control.sh.
>  9)Activate the cluster with control.sh.
> Not you should see the data loss.
> !image-2018-06-01-13-15-17-437.png!
> Notes:
>  1)Stops/Starts should be done at the same time
>  2)Consistent Ids for nodes should be constant.
> Not you should see the data loss.
> Also, I provide the reproducer that often possible to reproduce this issue 
> (not always).  Free the working directory and restart reproducer in case if 
> there is no data loss in this iteration.



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

[jira] [Commented] (IGNITE-8676) Possible data loss after stoping/starting several nodes at the same time

[Stanislav Lukyanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500169#comment-16500169
 ] 

Stanislav Lukyanov commented on IGNITE-8676:


Reproducer attached (Ignite8676Test.java).

> Possible data loss after stoping/starting several nodes at the same time
> 
>
> Key: IGNITE-8676
> URL: https://issues.apache.org/jira/browse/IGNITE-8676
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: DataLossTest.zip, Ignite8676Test.java, 
> image-2018-06-01-12-34-54-320.png, image-2018-06-01-13-12-47-218.png, 
> image-2018-06-01-13-15-17-437.png
>
>
> Steps to reproduce:
> 1)Start 3 data (DN1, DN2, DN3) nodes with the configuration that contains the 
> cache with node filter for only these three nodes and 1 backup. (see 
> configuration from attachment)
>  2)Activate the cluster. Now you should have 3 nodes in BLT
>  3)Start new server node (SN). Now you should have 3 nodes in BLT and 1 node 
> not in the baseline.
>  4)Using some node load about 1 (or more) entities into the cache.
>  5)Start that number of primary partitions equals to backup partitions.
> !image-2018-06-01-12-34-54-320.png!
>  6)Now stop DN3 and SN. After that start them at the same time.
>  7)When DN3 and SN will be online, check that number of primary partitions 
> (PN) equals to backup partitions (BN).
> 7.1)In a case if PN == BN => go to step 6)
>  7.2)In a case if PN != BN => go to step 8)
>  
> !image-2018-06-01-13-12-47-218.png!
> 8)Deactivate the cluster with control.sh.
>  9)Activate the cluster with control.sh.
> Not you should see the data loss.
> !image-2018-06-01-13-15-17-437.png!
> Notes:
>  1)Stops/Starts should be done at the same time
>  2)Consistent Ids for nodes should be constant.
> Not you should see the data loss.
> Also, I provide the reproducer that often possible to reproduce this issue 
> (not always).  Free the working directory and restart reproducer in case if 
> there is no data loss in this iteration.



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

[jira] [Updated] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ilya Lantukh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Lantukh updated IGNITE-8693:
-
Description: 
One case of such problem is reproduced by 
IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (IGNITE-7766).

If PARTITIONED cache has NodeFilter and is located on subset of REPLICATED 
cache nodes, we might fail to execute SQL JOIN query with "Caches have distinct 
sets of data nodes" error. Whether if will fail or not depends on order of 
*cacheIds* List argument in GridReduceQueryExecutor.stableDataNodes(...) - we 
will fail if first cacheId is REPLICATED. The order depends on internal factors 
that are out of user's control.

> SQL JOIN between PARTITIONED and REPLICATED cache fails
> ---
>
> Key: IGNITE-8693
> URL: https://issues.apache.org/jira/browse/IGNITE-8693
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> One case of such problem is reproduced by 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (IGNITE-7766).
> If PARTITIONED cache has NodeFilter and is located on subset of REPLICATED 
> cache nodes, we might fail to execute SQL JOIN query with "Caches have 
> distinct sets of data nodes" error. Whether if will fail or not depends on 
> order of *cacheIds* List argument in 
> GridReduceQueryExecutor.stableDataNodes(...) - we will fail if first cacheId 
> is REPLICATED. The order depends on internal factors that are out of user's 
> control.



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

[jira] [Created] (IGNITE-8693) SQL JOIN between PARTITIONED and REPLICATED cache fails

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-8693:


 Summary: SQL JOIN between PARTITIONED and REPLICATED cache fails
 Key: IGNITE-8693
 URL: https://issues.apache.org/jira/browse/IGNITE-8693
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh






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

[jira] [Commented] (IGNITE-8691) Get rid of tests jar artifact in ignite-zookeeper module

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500151#comment-16500151
 ] 

ASF GitHub Bot commented on IGNITE-8691:


GitHub user Jokser opened a pull request:

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

IGNITE-8691 Removed jar-plugin from ignite-zookeeper module



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

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

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

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


commit 0512f384fd85ebf5e03308aae1f459dc59855e71
Author: Pavel Kovalenko 
Date:   2018-06-04T12:31:25Z

IGNITE-8691 Removed jar-plugin from ignite-zookeeper module




> Get rid of tests jar artifact in ignite-zookeeper module
> 
>
> Key: IGNITE-8691
> URL: https://issues.apache.org/jira/browse/IGNITE-8691
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently Ignite building process produces 
> {noformat}
> org/apache/ignite/ignite-zookeeper/2.X.X/ignite-zookeeper-2.X.X-tests.jar
> {noformat}
> artifact which seems to be useless and should be excluded as result of 
> packaging.



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

[jira] [Created] (IGNITE-8692) MVCC TX: Always persistent TxLog

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-8692:


 Summary: MVCC TX: Always persistent TxLog
 Key: IGNITE-8692
 URL: https://issues.apache.org/jira/browse/IGNITE-8692
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Igor Seliverstov


Currently TxLog may be overflowed in case a long running Tx prevents 
"vacuuming".

It can be solved by enabling persistence for TxLog data region by default.



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

[jira] [Updated] (IGNITE-7393) Apache Ignite delivery in RPM / DEB packages (stage II)

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7393:
-
Summary: Apache Ignite delivery in RPM / DEB packages (stage II)  (was: 
Apache Ignite delivery in RPM / DEB packages)

> Apache Ignite delivery in RPM / DEB packages (stage II)
> ---
>
> Key: IGNITE-7393
> URL: https://issues.apache.org/jira/browse/IGNITE-7393
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
>
> Aggregation task for first stage of preparing Apache Ignite delivery through 
> RPM / DEB packages.
> Steps:
> # Prepare source-based package build procedures for RPM and DEB.
> # Introduce these build procedures to Release Apache Ignite task in PublicTC.
> # Introduce upload / update schemes.



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

[jira] [Updated] (IGNITE-7393) Apache Ignite delivery in RPM / DEB packages (stage II)

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7393:
-
Fix Version/s: 2.6

> Apache Ignite delivery in RPM / DEB packages (stage II)
> ---
>
> Key: IGNITE-7393
> URL: https://issues.apache.org/jira/browse/IGNITE-7393
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
>
> Aggregation task for first stage of preparing Apache Ignite delivery through 
> RPM / DEB packages.
> Steps:
> # Prepare source-based package build procedures for RPM and DEB.
> # Introduce these build procedures to Release Apache Ignite task in PublicTC.
> # Introduce upload / update schemes.



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

[jira] [Commented] (IGNITE-8663) L1,L2 normalization

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500144#comment-16500144
 ] 

ASF GitHub Bot commented on IGNITE-8663:


GitHub user zaleslaw opened a pull request:

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

IGNITE-8663: Add Normalization Preprocessing support



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

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

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

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


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

IGNITE-7829: Added example

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

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

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

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

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

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

commit bb244de762b89d0a1e5606aa282e34d92752595b
Author: Zinoviev Alexey 
Date:   2018-05-16T11:42:06Z

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

commit b4cb1a42d35a0da9f8b762207011a46c6f542a20
Author: Zinoviev Alexey 
Date:   2018-05-16T16:17:39Z

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

commit 5d447d57d61c77b9f415093d634df8f3dccd55eb
Author: Zinoviev Alexey 
Date:   2018-06-01T09:36:16Z

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

commit 81ddb1c5db410d50208ada6d3de869e127506f56
Author: Zinoviev Alexey 
Date:   2018-06-04T08:21:37Z

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

commit cb55f45a8fcf85668db73a286770fba14a25730e
Author: Zinoviev Alexey 
Date:   2018-06-04T12:17:19Z

IGNITE-8662: Added Normalization support




> L1,L2 normalization
> ---
>
> Key: IGNITE-8663
> URL: https://issues.apache.org/jira/browse/IGNITE-8663
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.6
>
>
> We want to add L1 and L2 normalization using Model/Trainer API.



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

[jira] [Commented] (IGNITE-8690) Missed package-info for some packages

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500137#comment-16500137
 ] 

ASF GitHub Bot commented on IGNITE-8690:


GitHub user Jokser opened a pull request:

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

IGNITE-8690 Added missed package-infos.



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

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

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

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


commit 389c4553f399446cc1242772fc280e42eab1aeed
Author: Pavel Kovalenko 
Date:   2018-06-04T11:55:39Z

IGNITE-8690 Added package-info.

commit 41d27f6dde08483ea4c39c8bed46011d2eb4bdea
Author: Pavel Kovalenko 
Date:   2018-06-04T12:03:56Z

IGNITE-8690 Added package-info.




> Missed package-info for some packages
> -
>
> Key: IGNITE-8690
> URL: https://issues.apache.org/jira/browse/IGNITE-8690
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> List of affected packages:
> {noformat}
> org.apache.ignite.spi.communication.tcp.internal
> org.apache.ignite.spi.discovery.zk
> org.apache.ignite.spi.discovery.zk.internal
> org.apache.ignite.ml.structures.partition
> {noformat}



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

[jira] [Updated] (IGNITE-8689) SQL query execution may lead to NullPointerException during node stop.

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8689:

Description: (was: Let's consider the following scenario:
 # Start a new node (node 'A') and create a new partitioned cache that resides 
on that node.

{code:java}
Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
IgniteCache cache = ignite.getOrCreateCache(new 
CacheConfiguration()
.setName("default")
.setIndexedTypes(String.class, String.class)
.setNodeFilter(new NodeFilter())
);

public static class NodeFilter implements IgnitePredicate {
@Override public boolean apply(ClusterNode node) {
return node.attribute("test.attribute").equals("first-node");
}
}
{code}

 # Start the second node (node 'B') witch a custom connector configuration

{code:java}






{code}

 # Execute simple SQL query using sqlline for example (JDBC driver should be 
connected to node 'B')

{code:java}
./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2

select * from UNKNOWN_TABLE;
{code}
{{In that case, IgniteH2Indexing}})

> SQL query execution may lead to NullPointerException during node stop.
> --
>
> Key: IGNITE-8689
> URL: https://issues.apache.org/jira/browse/IGNITE-8689
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Priority: Major
>




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

[jira] [Commented] (IGNITE-8675) Fix flacky test PdsWithTtlCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500135#comment-16500135
 ] 

ASF GitHub Bot commented on IGNITE-8675:


Github user asfgit closed the pull request at:

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


> Fix flacky test  
> PdsWithTtlCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_1
> -
>
> Key: IGNITE-8675
> URL: https://issues.apache.org/jira/browse/IGNITE-8675
> Project: Ignite
>  Issue Type: Test
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Looks like 2.1 node that is started in separate JVM, fails with OOM.
>  



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

[jira] [Commented] (IGNITE-8311) IgniteClientRejoinTest.testClientsReconnectDisabled causes exchange-worker to terminate via NPE

[Dmitriy Sorokin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500129#comment-16500129
 ] 

Dmitriy Sorokin commented on IGNITE-8311:
-

[~agura], review my patch, please!

> IgniteClientRejoinTest.testClientsReconnectDisabled causes exchange-worker to 
> terminate via NPE
> ---
>
> Key: IGNITE-8311
> URL: https://issues.apache.org/jira/browse/IGNITE-8311
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Currently, tests use {{NoOpFailureHandler}} by default, hence this 
> exchange-worker termination is masked. We are to fix it: test code should not 
> be able to terminate system-critical thread.



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

[jira] [Commented] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500126#comment-16500126
 ] 

Dmitriy Pavlov commented on IGNITE-5823:


Run all report on TC looking good
https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_GenerateTestReport/1338400:id/report.html


> Need to remove CacheAtomicUpdateTimeoutException
> 
>
> Key: IGNITE-5823
> URL: https://issues.apache.org/jira/browse/IGNITE-5823
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Sergey Dorozhkin
>Priority: Minor
>  Labels: newbie
>
> And releated - CacheAtomicUpdateTimeoutCheckedException
> These exceptions are not used any more and can be removed.



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

[jira] [Commented] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500124#comment-16500124
 ] 

Dmitriy Pavlov commented on IGNITE-5823:


Hi [~akalashnikov] could you please take a look?

> Need to remove CacheAtomicUpdateTimeoutException
> 
>
> Key: IGNITE-5823
> URL: https://issues.apache.org/jira/browse/IGNITE-5823
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Sergey Dorozhkin
>Priority: Minor
>  Labels: newbie
>
> And releated - CacheAtomicUpdateTimeoutCheckedException
> These exceptions are not used any more and can be removed.



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

[jira] [Comment Edited] (IGNITE-8671) Provide instructions on running Apache Ignite as systemd service on Windows 10 WSL Ubuntu

[Peter Ivanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500123#comment-16500123
 ] 

Peter Ivanov edited comment on IGNITE-8671 at 6/4/18 12:02 PM:
---

I've added info (?) snippet at the end of item 2 of [RPM / DEB packages 
Installation|https://apacheignite.readme.io/docs/getting-started#section-rpm-deb-packages-installation]
 section with full layout disclosure.


was (Author: vveider):
I've added info (?) snippet at the end of item 2 of [RPM \| DEB packages 
Installation|https://apacheignite.readme.io/docs/getting-started#section-rpm-deb-packages-installation]
 section with full layout disclosure.

> Provide instructions on running Apache Ignite as systemd service on Windows 
> 10 WSL Ubuntu
> -
>
> Key: IGNITE-8671
> URL: https://issues.apache.org/jira/browse/IGNITE-8671
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.6
>
>
> Prepare instructions (and possibly update official documentation) on running 
> Apache Ignite as systemd service on Windows 10 WSL Ubuntu using official DEB 
> package.



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

[jira] [Comment Edited] (IGNITE-8671) Provide instructions on running Apache Ignite as systemd service on Windows 10 WSL Ubuntu

[Peter Ivanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500123#comment-16500123
 ] 

Peter Ivanov edited comment on IGNITE-8671 at 6/4/18 12:02 PM:
---

I've added info (?) snippet at the end of item 2 of [RPM / DEB packages 
Installation|https://apacheignite.readme.io/docs/getting-started#section-rpm-deb-packages-installation]
 section with full installation layout disclosure.


was (Author: vveider):
I've added info (?) snippet at the end of item 2 of [RPM / DEB packages 
Installation|https://apacheignite.readme.io/docs/getting-started#section-rpm-deb-packages-installation]
 section with full layout disclosure.

> Provide instructions on running Apache Ignite as systemd service on Windows 
> 10 WSL Ubuntu
> -
>
> Key: IGNITE-8671
> URL: https://issues.apache.org/jira/browse/IGNITE-8671
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.6
>
>
> Prepare instructions (and possibly update official documentation) on running 
> Apache Ignite as systemd service on Windows 10 WSL Ubuntu using official DEB 
> package.



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

[jira] [Commented] (IGNITE-8671) Provide instructions on running Apache Ignite as systemd service on Windows 10 WSL Ubuntu

[Peter Ivanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500123#comment-16500123
 ] 

Peter Ivanov commented on IGNITE-8671:
--

I've added info (?) snippet at the end of item 2 of [RPM | DEB packages 
Installation|https://apacheignite.readme.io/docs/getting-started#section-rpm-deb-packages-installation]
 section with full layout disclosure.

> Provide instructions on running Apache Ignite as systemd service on Windows 
> 10 WSL Ubuntu
> -
>
> Key: IGNITE-8671
> URL: https://issues.apache.org/jira/browse/IGNITE-8671
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.6
>
>
> Prepare instructions (and possibly update official documentation) on running 
> Apache Ignite as systemd service on Windows 10 WSL Ubuntu using official DEB 
> package.



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

[jira] [Comment Edited] (IGNITE-8671) Provide instructions on running Apache Ignite as systemd service on Windows 10 WSL Ubuntu

[Peter Ivanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500123#comment-16500123
 ] 

Peter Ivanov edited comment on IGNITE-8671 at 6/4/18 12:01 PM:
---

I've added info (?) snippet at the end of item 2 of [RPM \| DEB packages 
Installation|https://apacheignite.readme.io/docs/getting-started#section-rpm-deb-packages-installation]
 section with full layout disclosure.


was (Author: vveider):
I've added info (?) snippet at the end of item 2 of [RPM | DEB packages 
Installation|https://apacheignite.readme.io/docs/getting-started#section-rpm-deb-packages-installation]
 section with full layout disclosure.

> Provide instructions on running Apache Ignite as systemd service on Windows 
> 10 WSL Ubuntu
> -
>
> Key: IGNITE-8671
> URL: https://issues.apache.org/jira/browse/IGNITE-8671
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.6
>
>
> Prepare instructions (and possibly update official documentation) on running 
> Apache Ignite as systemd service on Windows 10 WSL Ubuntu using official DEB 
> package.



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

[jira] [Commented] (IGNITE-8290) Activation message handling fails with AssertionError sporadically.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500118#comment-16500118
 ] 

ASF GitHub Bot commented on IGNITE-8290:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-8290: Trying to reproduce on TC.

Debug through CI.

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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-8290

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

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


commit b8f4a20cee48220e47efaba8433820ed1c150153
Author: Andrey Kuznetsov 
Date:   2018-06-04T11:49:30Z

IGNITE-8290: Trying to reproduce on TC.




> Activation message handling fails with AssertionError sporadically.
> ---
>
> Key: IGNITE-8290
> URL: https://issues.apache.org/jira/browse/IGNITE-8290
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrew Mashenkov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Attachments: disco-msg-fails-2.stack, disco-msg-fails.stack
>
>
> Some test fails sporadically due to AssertionError while processing custom 
> discovery message which can leads to grid and tests handing.
> PFA stacktraces.
> org.apache.ignite.internal.processors.cache.persistence.db.IgnitePdsWholeClusterRestartTest
>  is a good startpoint.
> However, the test passes at master, it's every run logs lot of 
> AssertionErrors .



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

[jira] [Created] (IGNITE-8691) Get rid of tests jar artifact in ignite-zookeeper module

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8691:
---

 Summary: Get rid of tests jar artifact in ignite-zookeeper module
 Key: IGNITE-8691
 URL: https://issues.apache.org/jira/browse/IGNITE-8691
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


Currently Ignite building process produces 
{noformat}
org/apache/ignite/ignite-zookeeper/2.X.X/ignite-zookeeper-2.X.X-tests.jar
{noformat}
artifact which seems to be useless and should be excluded as result of 
packaging.



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

[jira] [Created] (IGNITE-8690) Missed package-info for some packages

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8690:
---

 Summary: Missed package-info for some packages
 Key: IGNITE-8690
 URL: https://issues.apache.org/jira/browse/IGNITE-8690
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


List of affected packages:

{noformat}
org.apache.ignite.spi.communication.tcp.internal
org.apache.ignite.spi.discovery.zk
org.apache.ignite.spi.discovery.zk.internal
org.apache.ignite.ml.structures.partition
{noformat}




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

[jira] [Updated] (IGNITE-8689) SQL query execution may lead to NullPointerException during node stop.

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8689:

Description: 
Let's consider the following scenario:
 # Start a new node (node 'A') and create a new partitioned cache that resides 
on that node.

{code:java}
Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
IgniteCache cache = ignite.getOrCreateCache(new 
CacheConfiguration()
.setName("default")
.setIndexedTypes(String.class, String.class)
.setNodeFilter(new NodeFilter())
);

public static class NodeFilter implements IgnitePredicate {
@Override public boolean apply(ClusterNode node) {
return node.attribute("test.attribute").equals("first-node");
}
}
{code}

 # Start the second node (node 'B') witch a custom connector configuration

{code:java}






{code}

 # Execute simple SQL query using sqlline for example (JDBC driver should be 
connected to node 'B')

{code:java}
./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2

select * from UNKNOWN_TABLE;
{code}
{{In that case, IgniteH2Indexing}}

> SQL query execution may lead to NullPointerException during node stop.
> --
>
> Key: IGNITE-8689
> URL: https://issues.apache.org/jira/browse/IGNITE-8689
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Priority: Major
>
> Let's consider the following scenario:
>  # Start a new node (node 'A') and create a new partitioned cache that 
> resides on that node.
> {code:java}
> Ignite ignite = Ignition.start("examples/config/segmentation/node-A.xml");
> IgniteCache cache = ignite.getOrCreateCache(new 
> CacheConfiguration()
> .setName("default")
> .setIndexedTypes(String.class, String.class)
> .setNodeFilter(new NodeFilter())
> );
> public static class NodeFilter implements IgnitePredicate {
> @Override public boolean apply(ClusterNode node) {
> return node.attribute("test.attribute").equals("first-node");
> }
> }
> {code}
>  # Start the second node (node 'B') witch a custom connector configuration
> {code:java}
> 
>  class="org.apache.ignite.configuration.ClientConnectorConfiguration">
> 
> 
> 
> 
> {code}
>  # Execute simple SQL query using sqlline for example (JDBC driver should be 
> connected to node 'B')
> {code:java}
> ./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1:2
> select * from UNKNOWN_TABLE;
> {code}
> {{In that case, IgniteH2Indexing}}



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

[jira] [Created] (IGNITE-8689) SQL query execution may lead to NullPointerException during node stop.

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-8689:
---

 Summary: SQL query execution may lead to NullPointerException 
during node stop.
 Key: IGNITE-8689
 URL: https://issues.apache.org/jira/browse/IGNITE-8689
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Vyacheslav Koptilin






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

[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500099#comment-16500099
 ] 

Ryabov Dmitrii commented on IGNITE-2313:


[~dpavlov], any suggestions?

> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.6
>
>
> Currently atomic operations within a transaction succeed without alarming a 
> user that no transaction really occurs. We should add a mode to fail such 
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following 
> error message: {{Transaction spans operations on atomic cache (consider 
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to 
> true)}}



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

[jira] [Comment Edited] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts

[Ilya Lantukh (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500095#comment-16500095
 ] 

Ilya Lantukh edited comment on IGNITE-7766 at 6/4/18 11:25 AM:
---

Personally I consider proposed solution a dirty hack that only solves problem 
for 1 specific case.
[~vozerov], can you please take a look as well?


was (Author: ilantukh):
Personally I consider proposed solution a dirty hack, that only solves problem 
for 1 specific case.
[~vozerov], can you please take a look as well?

> Ignite Queries 2: Test always failed 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
> ---
>
> Key: IGNITE-7766
> URL: https://issues.apache.org/jira/browse/IGNITE-7766
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Dmitriy Pavlov
>Assignee: Evgenii Zagumennov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Ignite Queries 2 
>  IgniteBinaryCacheQueryTestSuite2: 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%)
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts 
>  Current failure: refs/heads/master #345 No changes 11 Feb 18 03:03
> junit.framework.AssertionFailedError: On large page size must retry.
> Last runs fails with 100% probability.



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

[jira] [Commented] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts

[Ilya Lantukh (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500095#comment-16500095
 ] 

Ilya Lantukh commented on IGNITE-7766:
--

Personally I consider proposed solution a dirty hack, that only solves problem 
for 1 specific case.
[~vozerov], can you please take a look as well?

> Ignite Queries 2: Test always failed 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
> ---
>
> Key: IGNITE-7766
> URL: https://issues.apache.org/jira/browse/IGNITE-7766
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Dmitriy Pavlov
>Assignee: Evgenii Zagumennov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Ignite Queries 2 
>  IgniteBinaryCacheQueryTestSuite2: 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%)
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts 
>  Current failure: refs/heads/master #345 No changes 11 Feb 18 03:03
> junit.framework.AssertionFailedError: On large page size must retry.
> Last runs fails with 100% probability.



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

[jira] [Commented] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts

[Ilya Lantukh (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500094#comment-16500094
 ] 

Ilya Lantukh commented on IGNITE-7766:
--

It is theoretically possible that 2 partitioned caches have the same affinity 
function and node filter, but different primary assignments. And so, there 
might be a node that is primary for some partitions of cache1, but isn't for 
cache2 - so it will present in *extraNodes*, but absent in *nodes*.

> Ignite Queries 2: Test always failed 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
> ---
>
> Key: IGNITE-7766
> URL: https://issues.apache.org/jira/browse/IGNITE-7766
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Dmitriy Pavlov
>Assignee: Evgenii Zagumennov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Ignite Queries 2 
>  IgniteBinaryCacheQueryTestSuite2: 
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%)
> IgniteCacheQueryNodeRestartTxSelfTest.testRestarts 
>  Current failure: refs/heads/master #345 No changes 11 Feb 18 03:03
> junit.framework.AssertionFailedError: On large page size must retry.
> Last runs fails with 100% probability.



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

[jira] [Commented] (IGNITE-8183) ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally

[Sergey Chugunov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500063#comment-16500063
 ] 

Sergey Chugunov commented on IGNITE-8183:
-

[~garus.d.g], thanks for your patch!

Your analysis seems correct to me. It looks like that the source of the 
original timeout of 20 seconds could be value of syncLimit which is always 
configured to 5 in testing cluster.

However I don't think we should add up sesTimeout on ZookeeperClient side, sum 
of tickTime * initLimit + otherLogic should be enough here.

Also I left a comment in your PR, please address it and we will be good to 
proceed.

> ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
> ---
>
> Key: IGNITE-8183
> URL: https://issues.apache.org/jira/browse/IGNITE-8183
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Test fails with assertion on awaits on latch:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testSegmentation3(ZookeeperDiscoverySpiTest.java:1060)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason SEGMENTATION event is never fired, so assertion on latch 
> fails. Investigation is needed.



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

[jira] [Commented] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Roman Guseinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500062#comment-16500062
 ] 

Roman Guseinov commented on IGNITE-6241:


[~vveider], here is a little bit more detailed tutorial to deploy Ignite 
cluster on Google Cloud Platform (Kubernetes):

1. Grant cluster-admin role to the current user:
{code}
$ kubectl create clusterrolebinding myname-cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user=
{code}
2. Create `apacheig` namespace:
{code}
$ kubectl create -f namespace.yaml
{code}
3. Create service account and grant permissions:
{code}
$ kubectl create -f sa.yaml
$ kubectl create -f role.yaml
$ kubectl create -f rolebind.yaml
{code}
4. Create a grid service:
{code}
$ kubectl create -f service.yaml
{code}
5. Deploy GridGain cluster (stateful set):
{code}
$ kubectl create -f grid.yaml
{code}
6. Connect to POD and activate cluster:
{code}
$ kubectl exec -it grid-0 --namespace=apacheig -- /bin/bash

$ cd /opt/ignite/apache-ignite-*
$ ./bin/control.sh --activate
{code}
YAML-files are attached: [^namespace.yaml] [^sa.yaml] [^role.yaml] 
[^rolebind.yaml] [^service.yaml] [^grid.yaml] [^pds-config.xml]

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: grid.yaml, namespace.yaml, pds-config.xml, role.yaml, 
> rolebind.yaml, sa.yaml, service.yaml, tutorial_k8s.txt
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html
> See how it's done for Cassandra and MongoDB:
> * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
> * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/
> We can reach out K8 folks and ask to add a prepared Ignite tutorial to the 
> list.
> Good reading on the stateful set: 
> https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html



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

[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-6241:
---
Attachment: grid.yaml

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: grid.yaml, namespace.yaml, pds-config.xml, role.yaml, 
> rolebind.yaml, sa.yaml, service.yaml, tutorial_k8s.txt
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html
> See how it's done for Cassandra and MongoDB:
> * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
> * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/
> We can reach out K8 folks and ask to add a prepared Ignite tutorial to the 
> list.
> Good reading on the stateful set: 
> https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html



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

[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-6241:
---
Attachment: (was: grid.yaml)

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: grid.yaml, namespace.yaml, pds-config.xml, role.yaml, 
> rolebind.yaml, sa.yaml, service.yaml, tutorial_k8s.txt
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html
> See how it's done for Cassandra and MongoDB:
> * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
> * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/
> We can reach out K8 folks and ask to add a prepared Ignite tutorial to the 
> list.
> Good reading on the stateful set: 
> https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html



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

[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-6241:
---
Attachment: (was: openshift-pds.xml)

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: grid.yaml, namespace.yaml, pds-config.xml, role.yaml, 
> rolebind.yaml, sa.yaml, service.yaml, tutorial_k8s.txt
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html
> See how it's done for Cassandra and MongoDB:
> * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
> * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/
> We can reach out K8 folks and ask to add a prepared Ignite tutorial to the 
> list.
> Good reading on the stateful set: 
> https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html



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

[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-6241:
---
Attachment: (was: service.yaml)

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: grid.yaml, namespace.yaml, pds-config.xml, role.yaml, 
> rolebind.yaml, sa.yaml, service.yaml, tutorial_k8s.txt
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html
> See how it's done for Cassandra and MongoDB:
> * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
> * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/
> We can reach out K8 folks and ask to add a prepared Ignite tutorial to the 
> list.
> Good reading on the stateful set: 
> https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html



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

[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-6241:
---
Attachment: (was: grid.yaml)

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: grid.yaml, namespace.yaml, openshift-pds.xml, 
> pds-config.xml, role.yaml, rolebind.yaml, sa.yaml, service.yaml, 
> service.yaml, tutorial_k8s.txt
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html
> See how it's done for Cassandra and MongoDB:
> * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
> * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/
> We can reach out K8 folks and ask to add a prepared Ignite tutorial to the 
> list.
> Good reading on the stateful set: 
> https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html



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

[jira] [Updated] (IGNITE-6241) Integrate with Kubernetes StatefulSet to support Ignite Persistence

[Roman Guseinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Guseinov updated IGNITE-6241:
---
Attachment: pds-config.xml
namespace.yaml
grid.yaml
service.yaml
sa.yaml
rolebind.yaml
role.yaml

> Integrate with Kubernetes StatefulSet to support Ignite Persistence
> ---
>
> Key: IGNITE-6241
> URL: https://issues.apache.org/jira/browse/IGNITE-6241
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.6
>
> Attachments: grid.yaml, namespace.yaml, openshift-pds.xml, 
> pds-config.xml, role.yaml, rolebind.yaml, sa.yaml, service.yaml, 
> service.yaml, tutorial_k8s.txt
>
>
> Ignite Kubernetes integration has to support StatefulSet which enables Ignite 
> Persistence usage in Kubernetes deployments. More details are here:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-Persistence-on-Kubernetes-td16396.html
> See how it's done for Cassandra and MongoDB:
> * https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
> * https://kubernetes.io/docs/tutorials/stateless-application/guestbook/
> We can reach out K8 folks and ask to add a prepared Ignite tutorial to the 
> list.
> Good reading on the stateful set: 
> https://lenadroid.github.io/posts/stateful-sets-kubernetes-azure.html



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

[jira] [Commented] (IGNITE-8468) Adding and searching UUIDs in index tree produces a lot of garbage

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500025#comment-16500025
 ] 

Andrew Mashenkov commented on IGNITE-8468:
--

TC looks good.

> Adding and searching UUIDs in index tree produces a lot of garbage
> --
>
> Key: IGNITE-8468
> URL: https://issues.apache.org/jira/browse/IGNITE-8468
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Seems, optimization for UUIDs was missed in IGNITE-5918.
> PFA patch.



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

[jira] [Assigned] (IGNITE-8468) Adding and searching UUIDs in index tree produces a lot of garbage

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov reassigned IGNITE-8468:


Assignee: Andrew Mashenkov

> Adding and searching UUIDs in index tree produces a lot of garbage
> --
>
> Key: IGNITE-8468
> URL: https://issues.apache.org/jira/browse/IGNITE-8468
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Seems, optimization for UUIDs was missed in IGNITE-5918.
> PFA patch.



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

[jira] [Commented] (IGNITE-8688) Pending tree is initialized outside of checkpoint lock

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1658#comment-1658
 ] 

Ivan Rakov commented on IGNITE-8688:


Looks like the same issue as IGNITE-8682. We should probably close this after 
IGNITE-8682 is fixed.

> Pending tree is initialized outside of checkpoint lock
> --
>
> Key: IGNITE-8688
> URL: https://issues.apache.org/jira/browse/IGNITE-8688
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.6
>
>
> This may lead to possible page corruption.
> {noformat}
> handled accordingly to configured handler [hnd=class 
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext 
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
> [00:11:56]W:   [org.gridgain:gridgain-compatibility] 
> java.lang.AssertionError
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:11:56]W:   [org.gridgain:gridgain-compatibility]  at 
> java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Created] (IGNITE-8688) Pending tree is initialized outside of checkpoint lock

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8688:
---

 Summary: Pending tree is initialized outside of checkpoint lock
 Key: IGNITE-8688
 URL: https://issues.apache.org/jira/browse/IGNITE-8688
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Andrew Mashenkov
 Fix For: 2.6


This may lead to possible page corruption.

{noformat}
handled accordingly to configured handler [hnd=class 
o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext 
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
[00:11:56]W: [org.gridgain:gridgain-compatibility] 
java.lang.AssertionError
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[00:11:56]W: [org.gridgain:gridgain-compatibility]  at 
java.lang.Thread.run(Thread.java:748)
{noformat}




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

[jira] [Commented] (IGNITE-8468) Adding and searching UUIDs in index tree produces a lot of garbage

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499968#comment-16499968
 ] 

Vladimir Ozerov commented on IGNITE-8468:
-

[~amashenkov], please confirm that TC is fine.

> Adding and searching UUIDs in index tree produces a lot of garbage
> --
>
> Key: IGNITE-8468
> URL: https://issues.apache.org/jira/browse/IGNITE-8468
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Seems, optimization for UUIDs was missed in IGNITE-5918.
> PFA patch.



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

[jira] [Commented] (IGNITE-8687) Add JCache TCK 1.1.0 to TC

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499930#comment-16499930
 ] 

ASF GitHub Bot commented on IGNITE-8687:


GitHub user SharplEr opened a pull request:

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

ignite-8687 Add JCache TCK 1.1.0 to TC

For [IGNITE-8687](https://issues.apache.org/jira/browse/IGNITE-8687)

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

$ git pull https://github.com/SharplEr/ignite ignite-8687

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

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


commit 2f169ceaad811282998194257858ee3e3dadf74c
Author: Alexander Menshikov 
Date:   2018-06-04T09:11:31Z

ignite-8687 Add JCache TCK 1.1.0 to TC




> Add JCache TCK 1.1.0 to TC
> --
>
> Key: IGNITE-8687
> URL: https://issues.apache.org/jira/browse/IGNITE-8687
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
>
> We need to add a new profile for run TCK 1.1.0 and add it to TC.
> Until Ignite becomes JCache 1.1.0 compatible, this profile should coexist 
> with TCK 1.0.1.



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

[jira] [Created] (IGNITE-8687) Add JCache TCK 1.1.0 to TC

[Alexander Menshikov (JIRA)]

Alexander Menshikov created IGNITE-8687:
---

 Summary: Add JCache TCK 1.1.0 to TC
 Key: IGNITE-8687
 URL: https://issues.apache.org/jira/browse/IGNITE-8687
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexander Menshikov
Assignee: Alexander Menshikov


We need to add a new profile for run TCK 1.1.0 and add it to TC.

Until Ignite becomes JCache 1.1.0 compatible, this profile should coexist with 
TCK 1.0.1.



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

[jira] [Updated] (IGNITE-8686) Web console: 'Get started' points to the wrong page

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8686:
---
Summary: Web console: 'Get started' points to the wrong page  (was: Web 
console: 'Get started' point to the wrong page)

> Web console: 'Get started' points to the wrong page
> ---
>
> Key: IGNITE-8686
> URL: https://issues.apache.org/jira/browse/IGNITE-8686
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> I'm noticed that 'Get started' button on the landing page points to 'signin' 
> page, but should point to 'signup' page.
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8686) Web console: 'Get started' points to the wrong page

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8686:
---
Component/s: wizards

> Web console: 'Get started' points to the wrong page
> ---
>
> Key: IGNITE-8686
> URL: https://issues.apache.org/jira/browse/IGNITE-8686
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> I'm noticed that 'Get started' button on the landing page points to 'signin' 
> page, but should point to 'signup' page.
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8686) Web console: 'Get started' point to the wrong page

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8686:
---
Affects Version/s: 2.5

> Web console: 'Get started' point to the wrong page
> --
>
> Key: IGNITE-8686
> URL: https://issues.apache.org/jira/browse/IGNITE-8686
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> I'm noticed that 'Get started' button on the landing page points to 'signin' 
> page, but should point to 'signup' page.
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8686) Web console: 'Get started' point to the wrong page

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8686:
---
Fix Version/s: 2.6

> Web console: 'Get started' point to the wrong page
> --
>
> Key: IGNITE-8686
> URL: https://issues.apache.org/jira/browse/IGNITE-8686
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> I'm noticed that 'Get started' button on the landing page points to 'signin' 
> page, but should point to 'signup' page.
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8686) Web console: 'Get started' point to the wrong page

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8686:
---
Description: 
I'm noticed that 'Get started' button on the landing page points to 'signin' 
page, but should point to 'signup' page.
 !screenshot-1.png! 

  was:I'm noticed that 'Get started' button on the landing page points to 
'signin' page, but should point to 'signup' page.


> Web console: 'Get started' point to the wrong page
> --
>
> Key: IGNITE-8686
> URL: https://issues.apache.org/jira/browse/IGNITE-8686
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> I'm noticed that 'Get started' button on the landing page points to 'signin' 
> page, but should point to 'signup' page.
>  !screenshot-1.png! 



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

[jira] [Created] (IGNITE-8686) Web console: 'Get started' point to the wrong page

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8686:
--

 Summary: Web console: 'Get started' point to the wrong page
 Key: IGNITE-8686
 URL: https://issues.apache.org/jira/browse/IGNITE-8686
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
 Attachments: screenshot-1.png

I'm noticed that 'Get started' button on the landing page points to 'signin' 
page, but should point to 'signup' page.



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

[jira] [Updated] (IGNITE-8686) Web console: 'Get started' point to the wrong page

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov updated IGNITE-8686:
---
Attachment: screenshot-1.png

> Web console: 'Get started' point to the wrong page
> --
>
> Key: IGNITE-8686
> URL: https://issues.apache.org/jira/browse/IGNITE-8686
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> I'm noticed that 'Get started' button on the landing page points to 'signin' 
> page, but should point to 'signup' page.



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