[jira] [Closed] (IGNITE-4823) SpringCache#putIfAbsent - wrong implementation

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-4823.
---

> SpringCache#putIfAbsent - wrong implementation
> --
>
> Key: IGNITE-4823
> URL: https://issues.apache.org/jira/browse/IGNITE-4823
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>
> *Current implementation:*
> {code}
> Object old;
> if (val == null)
> old = cache.withSkipStore().putIfAbsent(key, NULL);
> else
> old = cache.putIfAbsent(key, val);
> return old != null ? fromValue(old) : null;
> {code}
> cache.putIfAbsent(key, val) - return boolean, not cached value
> *Excepted behavior (according to the Spring-docs)*
> {code}
> Object existingValue = cache.get(key);
> if (existingValue == null) {
> cache.put(key, value);
> return null;
> } else {
> return existingValue;
> }
> {code}
> 1. Need to fix implementation
> 2. Cover SpringCache class with unit-tests



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

[jira] [Commented] (IGNITE-4823) SpringCache#putIfAbsent - wrong implementation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4823:


Github user asfgit closed the pull request at:

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


> SpringCache#putIfAbsent - wrong implementation
> --
>
> Key: IGNITE-4823
> URL: https://issues.apache.org/jira/browse/IGNITE-4823
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>
> *Current implementation:*
> {code}
> Object old;
> if (val == null)
> old = cache.withSkipStore().putIfAbsent(key, NULL);
> else
> old = cache.putIfAbsent(key, val);
> return old != null ? fromValue(old) : null;
> {code}
> cache.putIfAbsent(key, val) - return boolean, not cached value
> *Excepted behavior (according to the Spring-docs)*
> {code}
> Object existingValue = cache.get(key);
> if (existingValue == null) {
> cache.put(key, value);
> return null;
> } else {
> return existingValue;
> }
> {code}
> 1. Need to fix implementation
> 2. Cover SpringCache class with unit-tests



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

[jira] [Commented] (IGNITE-4823) SpringCache#putIfAbsent - wrong implementation

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4823:
-

[~daradurvs], I looked at IGNITE-4211 and didn't find any reason for these 
tickets to depend on each other. So I merged your fix. Thanks!

> SpringCache#putIfAbsent - wrong implementation
> --
>
> Key: IGNITE-4823
> URL: https://issues.apache.org/jira/browse/IGNITE-4823
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>
> *Current implementation:*
> {code}
> Object old;
> if (val == null)
> old = cache.withSkipStore().putIfAbsent(key, NULL);
> else
> old = cache.putIfAbsent(key, val);
> return old != null ? fromValue(old) : null;
> {code}
> cache.putIfAbsent(key, val) - return boolean, not cached value
> *Excepted behavior (according to the Spring-docs)*
> {code}
> Object existingValue = cache.get(key);
> if (existingValue == null) {
> cache.put(key, value);
> return null;
> } else {
> return existingValue;
> }
> {code}
> 1. Need to fix implementation
> 2. Cover SpringCache class with unit-tests



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

[jira] [Commented] (IGNITE-2786) SpringCache doesn't survive client reconnect

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-2786:
-

[~ryagnik], can you please explain the fix? Why do you destroy the caches? In 
my understanding we just need to clear {{caches}} map in {{SpringCacheManager}} 
on {{DISCONNECTED}} event. This way if it reconnects, it will create new 
{{SpringCache}} when needed. Agree? Also you should add tests to reproduce the 
issue and then make sure that it is fixed by your change.

BTW, when you create a PR, please move the ticket to Patch Available. Please 
refer to the development process description on our wiki for more details.

> SpringCache doesn't survive client reconnect
> 
>
> Key: IGNITE-2786
> URL: https://issues.apache.org/jira/browse/IGNITE-2786
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Rishi
> Fix For: 2.0
>
>
> After a client disconnects and reconnects with new ID, Spring caching can't 
> be used, because existing cache instance are closed.



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

[jira] [Commented] (IGNITE-4748) jdbc2.JdbcStatement does not implement setQueryTimeout method

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4748:
-

[~adasari], I wanted to look at your changes, but there are conflicts. Can you 
please make sure that PR is mergeable to master?

Also whenever you create a PR and want community to review, please move ticket 
to Patch Available.

> jdbc2.JdbcStatement does not implement setQueryTimeout method
> -
>
> Key: IGNITE-4748
> URL: https://issues.apache.org/jira/browse/IGNITE-4748
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Anil Dasari
>Priority: Critical
> Fix For: 2.0
>
>
> The method was implemented in the older version of JDBC driver, but was 
> missed in the newer version (still throws exception).



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

[jira] [Commented] (IGNITE-4812) Disable EventStorageSpi by default

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4812:
-

[~alpert], the fix itself looks good, but I don't like multiple changes in old 
tests. Please do the following:
* Revert all these changes of {{getConfiguration}} method in tests.
* Instead modify {{GridAbstractTest.getConfiguration(String igniteInstanceName, 
IgniteTestResources rsrcs)}} method to use {{MemoryEventStorageSpi}} by 
default, so that nothing changes for any of tests that already exist.
* In any new tests that require {{NoopEventStorageSpi}}, set it explicitly.
* Rerun TC and check that everything is fine.

> Disable EventStorageSpi by default
> --
>
> Key: IGNITE-4812
> URL: https://issues.apache.org/jira/browse/IGNITE-4812
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Alper Tekinalp
> Fix For: 2.0
>
>
> Current default implementation of {{EventStorageSpi}} is 
> {{MemoryEventStorageSpi}}. It consumes a lot of memory, while is used only 
> for events querying (i.e. not listening), which is a fairly rare use case.
> Need to:
> * Introduce {{NoOpEventStorageSpi}}.
> * Make {{NoOpEventStorageSpi}} the default one.
> * Throw an exception when {{IgniteEvents#localQuery}} or {{#remoteQuery}} 
> method is called with default setting. Exception message should explain how 
> to fix it.



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

[jira] [Commented] (IGNITE-4896) OptimizedMarshaller should not failed on GridClientNodeBean serialization

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4896:
-

[~kuaw26], I don't like that the change is made on the class descriptor level. 
It implements the protocol and writing some dummy strings there looks 
completely wrong. It's correct for the protocol to throw an exception if 
something can't be serialized, and it's up to upper-level code to catch is and 
write these strings or do whatever else is needed.

If there is something wrong with {{GridClientNodeBean}} in particular, let's 
fix it in its {{write/readExternal}} methods.

> OptimizedMarshaller should not failed on GridClientNodeBean serialization
> -
>
> Key: IGNITE-4896
> URL: https://issues.apache.org/jira/browse/IGNITE-4896
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 1.9
>Reporter: Alexey Kuznetsov
>Assignee: Valentin Kulichenko
> Fix For: 2.0
>
>
> If node attributes contain some unknown for Optimized marshaller classes (not 
> present in classnames.properties) it will failed to serialize them.
> I think it is better to skip such objects and print warning in node log and 
> GridClient log.



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

[jira] [Created] (IGNITE-4903) More SQL side tests for CREATE/DROP INDEX

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4903:
---

 Summary: More SQL side tests for CREATE/DROP INDEX
 Key: IGNITE-4903
 URL: https://issues.apache.org/jira/browse/IGNITE-4903
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 2.0


IGNITE-4656 needs more tests to check indexes' actual usage and correctness.



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

[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4211:
-

[~daradurvs], as far as I know Anton is on vacation. He will review the changes 
once he is back.

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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

[jira] [Commented] (IGNITE-4890) Unable to create tables automatically because 'unconfigured columnfamily' error is not handled for older Cassandra versions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4890:


GitHub user venky1963 opened a pull request:

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

https://issues.apache.org/jira/browse/IGNITE-4890

Support older versions of Cassandra where the table not exists message
comes out as 'unconfigured columnfamily' instead of the newer
'unconfigured table' in newer Cassandra versions

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

$ git pull https://github.com/venky1963/ignite master

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

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


commit c08a9d33b3b49535e50837916b9f2324589e0558
Author: vkandas 
Date:   2017-03-31T17:22:45Z

https://issues.apache.org/jira/browse/IGNITE-4890
Support older versions of Cassandra where the table not exists message
comes out as 'unconfigured columnfamily' instead of the newer
'unconfigured table' in newer Cassandra versions




> Unable to create tables automatically because 'unconfigured columnfamily' 
> error is not handled for older Cassandra versions
> ---
>
> Key: IGNITE-4890
> URL: https://issues.apache.org/jira/browse/IGNITE-4890
> Project: Ignite
>  Issue Type: Bug
>  Components: compatibility
>Affects Versions: 1.9
>Reporter: Venky Kandaswamy
>  Labels: patch
> Fix For: 2.0
>
>
> PROBLEM:
> When running Ignite with older Cassandra versions (i.e DSE 4.8.10, Cassandra 
> 2.1.6 or older), we noticed that only the first tabel in an Ignite config is 
> created and the others fail with 'unconfigured columnfamily' exception.
> SUGGESTED FIX:
> It appears that the error from Cassandra is changed in newer versions to 
> 'unconfigured table ...' and this is handled.  The conditions checked in 
> org.apache.ignite.cache.store.cassandra.common.CassandraHelper needs to be 
> modified to handle the older Cassandra errors. 
> We are submitting a patch to do that. 
> 13:44:28,753 ERROR com.walmartlabs.qarth.ignite.tests.utils.CacheStoreHelper 
> [main] - Failed to execute Cassandra CQL statement: insert into 
> "test1"."blob_test2" ("key", "value") values (?,?);
> class org.apache.ignite.IgniteException: Failed to execute Cassandra CQL 
> statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
>   at 
> org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:163)
>   at 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:276)
>   at 
> com.walmartlabs.qarth.ignite.tests.cassandra.CassandraDirectPersistenceTest.blobStrategyTest(CassandraDirectPersistenceTest.java:233)
>   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:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> 

[jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4052:
-

Folks,

Please don’t forget to update Mesos doc once this contribution gets merged:
https://apacheignite.readme.io/docs/mesos-deployment

Assign the ticket on [~pgarg] to review documentation changes.

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Updated] (IGNITE-4856) .NET: StopAll on AppDomain unload

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4856:
---
Description: 
In certain scenarios .NET {{AppDomain}} can be unloaded and started again. Java 
part of Ignite continues to run, but .NET part (including Ignite instances) is 
lost. User can no longer work with started nodes, .NET callback pointers are 
lost, etc.

1) Track AppDomain unload and stop all Ignite instances.
2) When starting Ignite, wait for node with specified name to stop.
3) Make it possible to auto-generate a unique grid name automatically?

IIS issues example: 
http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183

  was:
In certain scenarios .NET {{AppDomain}} can be unloaded and started again. Java 
part of Ignite continues to run, but .NET part (including Ignite instances) is 
lost. User can no longer work with started nodes, .NET callback pointers are 
lost, etc.

We should track AppDomain unload and stop all Ignite instances.

IIS issues example: 
http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183


> .NET: StopAll on AppDomain unload
> -
>
> Key: IGNITE-4856
> URL: https://issues.apache.org/jira/browse/IGNITE-4856
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> In certain scenarios .NET {{AppDomain}} can be unloaded and started again. 
> Java part of Ignite continues to run, but .NET part (including Ignite 
> instances) is lost. User can no longer work with started nodes, .NET callback 
> pointers are lost, etc.
> 1) Track AppDomain unload and stop all Ignite instances.
> 2) When starting Ignite, wait for node with specified name to stop.
> 3) Make it possible to auto-generate a unique grid name automatically?
> IIS issues example: 
> http://stackoverflow.com/questions/42961879/how-do-i-retrieve-a-started-ignite-instance-when-a-website-restart-occurs-in-iis/42968183#42968183



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

[jira] [Created] (IGNITE-4902) .NET: StartFromApplicationConfiguration does not work in ASP.NET

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4902:
--

 Summary: .NET: StartFromApplicationConfiguration does not work in 
ASP.NET
 Key: IGNITE-4902
 URL: https://issues.apache.org/jira/browse/IGNITE-4902
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.7
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


{{Ignition.StartFromApplicationConfiguration()}} fails with {{exePath must be 
specified when not running inside a stand alone exe}} error. Equivalent call in 
web environment would be 
{{System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~")}}, 
but we really do not want System.Web dependency.

{{Ignition.StartFromApplicationConfiguration("igniteConfiguration")}} works, 
and that is what we should do from the method without arguments.



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

[jira] [Commented] (IGNITE-4625) .NET: MixedClusterTest leaves Java-only node running

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4625:


Looks like {{MixedClusterTest.TestScanQuery}} breaks something serious on Java 
side, and node may fail to stop and clean up properly.

> .NET: MixedClusterTest leaves Java-only node running
> 
>
> Key: IGNITE-4625
> URL: https://issues.apache.org/jira/browse/IGNITE-4625
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> MixedClusterTest causes consequent tests to fail in some situations because 
> it leaves java-only "grid2" node running. Looks like ExecuteJavaTask does not 
> stop node properly.



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

[jira] [Comment Edited] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov edited comment on IGNITE-4052 at 3/31/17 3:06 PM:
---

[~javaller]
I'm some bit confused. Builder#setRoleBytes and Builder#setUserBytes methods 
used only test and how user can provide this parameters in ignite-yarn 
integration? Also seems that the test does test nothing. I don't see any 
invocation "production code" from {{IgniteFrameworkInfoTest}} test. Do you have 
any idea how fix it?
I think that need to investigate this deeper and look at another mesos 
application and see how they do it.


was (Author: ntikhonov):
[~javaller]
I'm some bit confused. Builder#setRoleBytes and Builder#setUserBytes methods 
used only test and how user can provide this parameters in ignite-yarn 
integration? Also seems that test does test nothing. I don't see any invocation 
"production code" from {{IgniteFrameworkInfoTest}} test. Do you have any idea 
how fix it?
I think that need to investigate this deeper and look at another mesos 
application and see how they do it.

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Vadim Opolski
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS cluster 
> via current user. Need to add ability to configure this parameters via system 
> env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



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

[jira] [Created] (IGNITE-4901) Decrease logging level for DataStremer retry

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4901:


 Summary: Decrease logging level for DataStremer retry 
 Key: IGNITE-4901
 URL: https://issues.apache.org/jira/browse/IGNITE-4901
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.9
Reporter: Nikolay Tikhonov


When topology are changed DataStreame log the following error message which 
confused users. Need to decrease logging level for this case.
{noformat}
ERROR  Failed to execute compound future reducer: GridCompoundFuture [...] 
class org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
[node=9d405934-eb78-4452-a3a8-fc44c3c61e76] 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1080)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:708)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:101)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:671)
 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745) 
Caused by: class org.apache.ignite.IgniteCheckedException: DataStreamer will 
retry data transfer at stable topology [...] 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:337)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:297)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:56)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:86)
 
... 7 more 
{noformat}



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

[jira] [Updated] (IGNITE-4901) Decrease logging level for DataStremer retry

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-4901:
-
Priority: Trivial  (was: Major)

> Decrease logging level for DataStremer retry 
> -
>
> Key: IGNITE-4901
> URL: https://issues.apache.org/jira/browse/IGNITE-4901
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>Priority: Trivial
>
> When topology are changed DataStreame log the following error message which 
> confused users. Need to decrease logging level for this case.
> {noformat}
> ERROR  Failed to execute compound future reducer: GridCompoundFuture [...] 
> class org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
> [node=9d405934-eb78-4452-a3a8-fc44c3c61e76] 
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
>  
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
>  
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1080)
>  
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:708)
>  
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:101)
>  
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:671)
>  
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  
>   at java.lang.Thread.run(Thread.java:745) 
> Caused by: class org.apache.ignite.IgniteCheckedException: DataStreamer will 
> retry data transfer at stable topology [...] 
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:337)
>  
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:297)
>  
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:56)
>  
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:86)
>  
>   ... 7 more 
> {noformat}



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

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 2:45 PM:
--

The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem ({{perNodeParallelBatchCount}} should be > 0, but it is 16 by default):
{code}

 .

{code}
After that the problem was reproducible just after node start with an attempt 
to read a 44Mb file via IGFS (with  {{./hadoop-ig fs -copyToLocal 
igfs://localhost:10500/tmp/myfile /tmp/}} ) that exists on HDFS (secondary Fs), 
but is yet missing in the IGFS caches.

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem ({{perNodeParallelBatchCount}} should be > 0, but it is 16 by default):
{code}

 .

{code}
After that the problem was reproducible just after node start with an attempt 
to read a 44Mb file via IGFS (with {{./hadoop-ig fs -copyToLocal 
igfs://localhost:10500/tmp/myfile /tmp/ }} ) that exists on HDFS (secondary 
Fs), but is yet missing in the IGFS caches.

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 2:45 PM:
--

The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem ({{perNodeParallelBatchCount}} should be > 0, but it is 16 by default):
{code}

 .

{code}
After that the problem was reproducible just after node start with an attempt 
to read a 44Mb file via IGFS (with {{./hadoop-ig fs -copyToLocal 
igfs://localhost:10500/tmp/myfile /tmp/ }} ) that exists on HDFS (secondary 
Fs), but is yet missing in the IGFS caches.

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem ({{perNodeParallelBatchCount}} should be > 0, but it is 16 by default):
{code}

 .

{code}
After that the problem was reproducible just after node start with an attempt 
to read a 44Mb file via IGFS (with {{./hadoop-ig fs -copyToLocal 
igfs://localhost:10500/tmp/myfile /tmp/ }}) that exists on HDFS (secondary Fs), 
but is yet missing in the IGFS caches.

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 2:45 PM:
--

The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem ({{perNodeParallelBatchCount}} should be > 0, but it is 16 by default):
{code}

 .

{code}
After that the problem was reproducible just after node start with an attempt 
to read a 44Mb file via IGFS (with {{./hadoop-ig fs -copyToLocal 
igfs://localhost:10500/tmp/myfile /tmp/ }}) that exists on HDFS (secondary Fs), 
but is yet missing in the IGFS caches.

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem ({{perNodeParallelBatchCount}} should be > 0, but it is 16 by default):
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 

[jira] [Commented] (IGNITE-4699) Introduce custom configurable executors.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4699:
--

Tests 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1718%2Fhead]

> Introduce custom configurable executors.
> 
>
> Key: IGNITE-4699
> URL: https://issues.apache.org/jira/browse/IGNITE-4699
> Project: Ignite
>  Issue Type: Task
>  Components: compute
>Reporter: Vladimir Ozerov
>Assignee: Alexander Menshikov
>  Labels: important
> Fix For: 2.0
>
>
> We need to provide a way to configure custom thread pools for user compute 
> tasks. 
> Proposed API:
> 1) Config
> {code}
> class ExecutorConfiguration {
> String name;
> int size;
> }
> {code}
> 2) Choosing executor for compute task:
> {code}
> IgniteCompute compute = Ignite.compute().withExecutor("my_exec");
> {code}
> 3) Accessing raw executor (could be required for proper execution of future 
> listeners):
> {code}
> ThreadPoolExecutor exec = ignite.compute().localExecutor("my_exec");
> {code}



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

[jira] [Commented] (IGNITE-4699) Introduce custom configurable executors.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4699:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4699 Introduce custom configurable executors.



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

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

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

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


commit 421dd941ce601ddae3a0e370024f90561dd3bb8a
Author: tledkov-gridgain 
Date:   2017-03-31T08:08:11Z

IGNITE-4699: save the progress

commit b4e7542fd2f4cc14b530a9f37983697c47687abe
Author: tledkov-gridgain 
Date:   2017-03-31T09:02:32Z

IGNITE-4699: save the progress

commit 99c3c7c13c9833a6e7f963359c2f02db6b00228c
Author: tledkov-gridgain 
Date:   2017-03-31T09:02:38Z

Merge branch '_master' into ignite-4699

commit 0abf4bf99f422dd816d632a884442d0ecd3a
Author: tledkov-gridgain 
Date:   2017-03-31T14:04:50Z

IGNITE-4699: save the progress




> Introduce custom configurable executors.
> 
>
> Key: IGNITE-4699
> URL: https://issues.apache.org/jira/browse/IGNITE-4699
> Project: Ignite
>  Issue Type: Task
>  Components: compute
>Reporter: Vladimir Ozerov
>Assignee: Alexander Menshikov
>  Labels: important
> Fix For: 2.0
>
>
> We need to provide a way to configure custom thread pools for user compute 
> tasks. 
> Proposed API:
> 1) Config
> {code}
> class ExecutorConfiguration {
> String name;
> int size;
> }
> {code}
> 2) Choosing executor for compute task:
> {code}
> IgniteCompute compute = Ignite.compute().withExecutor("my_exec");
> {code}
> 3) Accessing raw executor (could be required for proper execution of future 
> listeners):
> {code}
> ThreadPoolExecutor exec = ignite.compute().localExecutor("my_exec");
> {code}



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

[jira] [Created] (IGNITE-4900) org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 periodically fails in master

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-4900:
-

 Summary: 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 
periodically fails in master
 Key: IGNITE-4900
 URL: https://issues.apache.org/jira/browse/IGNITE-4900
 Project: Ignite
  Issue Type: Test
Reporter: Yakov Zhdanov
Priority: Blocker
 Fix For: 2.0
 Attachments: log.txt

See attached log



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

[jira] [Updated] (IGNITE-4900) org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 periodically fails in master

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-4900:
--
Attachment: log.txt

> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4 
> periodically fails in master
> --
>
> Key: IGNITE-4900
> URL: https://issues.apache.org/jira/browse/IGNITE-4900
> Project: Ignite
>  Issue Type: Test
>Reporter: Yakov Zhdanov
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: log.txt
>
>
> See attached log



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

[jira] [Resolved] (IGNITE-4713) refactoring of GridFinishedFuture and GridFutureAdapter

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov resolved IGNITE-4713.
-
Resolution: Not A Problem

Don't need it.

>  refactoring of GridFinishedFuture and GridFutureAdapter
> 
>
> Key: IGNITE-4713
> URL: https://issues.apache.org/jira/browse/IGNITE-4713
> Project: Ignite
>  Issue Type: Improvement
>  Components: community
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Trivial
>
> I propose to do refactoring of classes "GridFinishedFuture" and 
> "GridFutureAdapter". There is field "resFlag" which can equals "ERR = 1" or 
> "RES = 2". So I can replace it to one "bool haveResult" field.
> If there are no objections, I'm ready to proceed. If you find more such 
> classes, please write about them.



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

[jira] [Commented] (IGNITE-3585) CPP: Rework methods that accept containers so any container could be used with them.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3585:


Looks good to me.

> CPP: Rework methods that accept containers so any container could be used 
> with them.
> 
>
> Key: IGNITE-3585
> URL: https://issues.apache.org/jira/browse/IGNITE-3585
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> There are methods that could possibly be used with any container but by some 
> reason they only accept arguments of a single specific container type. It can 
> be non convenient for user and bad from the performance point of view if user 
> uses other container type to store values. Consider using iterators 
> (preferably) or template type for the container.
> Methods of interest:
> - {{QueryCursor::GetAll}}
> - {{Cache::ContainsKeys}}
> - {{Cache::GetAll}}
> - {{Cache::PutAll}}
> - {{Cache::LocalEvict}}
> - {{Cache::ClearAll}}
> - {{Cache::LocalClearAll}}
> - {{Cache::RemoveAll}}.



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

[jira] [Closed] (IGNITE-4884) Visorcmd - minor text mistake

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-4884.


> Visorcmd - minor text mistake
> -
>
> Key: IGNITE-4884
> URL: https://issues.apache.org/jira/browse/IGNITE-4884
> Project: Ignite
>  Issue Type: Task
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Trivial
> Fix For: 2.0
>
> Attachments: visor.png
>
>
> {noformat}
> 'Hi' - Number of cache hits.
> 'Mi' - Number of cache misses.
> 'Rd' - number of cache reads.
> 'Wr' - Number of cache writes.
> {noformat}
> Looks like "number of cache reads" should begin with the capital "N"
> !visor.png!



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

[jira] [Commented] (IGNITE-4884) Visorcmd - minor text mistake

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4884:


Github user asfgit closed the pull request at:

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


> Visorcmd - minor text mistake
> -
>
> Key: IGNITE-4884
> URL: https://issues.apache.org/jira/browse/IGNITE-4884
> Project: Ignite
>  Issue Type: Task
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Trivial
> Fix For: 2.0
>
> Attachments: visor.png
>
>
> {noformat}
> 'Hi' - Number of cache hits.
> 'Mi' - Number of cache misses.
> 'Rd' - number of cache reads.
> 'Wr' - Number of cache writes.
> {noformat}
> Looks like "number of cache reads" should begin with the capital "N"
> !visor.png!



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

[jira] [Created] (IGNITE-4899) .NET: Review Dictionary usage in APIs

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4899:
--

 Summary: .NET: Review Dictionary usage in APIs
 Key: IGNITE-4899
 URL: https://issues.apache.org/jira/browse/IGNITE-4899
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
 Fix For: 2.0


We have replaced {{IDictionary}} with {{IEnumerable>}} in 
{{ICacheStore}}, let's do the same for other APIs like {{ICache.GetAll}}.

Reading GetAll results into a dictionary is inefficient in case when user only 
needs to iterate over results (unneeded allocation and hashing).



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

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2703:


Migration guide updated: 
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide

> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api, important
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



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

[jira] [Commented] (IGNITE-3575) CPP: Support continuous queries remote filters.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-3575:
-

[~skalashnikov], would you take a look then?

> CPP: Support continuous queries remote filters.
> ---
>
> Key: IGNITE-3575
> URL: https://issues.apache.org/jira/browse/IGNITE-3575
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, important
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2703:


Merged to master. Woohoo! :D (y)

> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api, important
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



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

[jira] [Comment Edited] (IGNITE-4524) Indexes usage in SQL functions like min/max

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov edited comment on IGNITE-4524 at 3/31/17 1:32 PM:
-

Implemented. However, we need to fix H2 issue with index selection in order to 
fully fix this.
The changes are based on ignite-3477-master branch.


was (Author: skalashnikov):
Implemented. However, we need to fix H2 issue with index selection in order to 
fully fix this.

> Indexes usage in SQL functions like min/max
> ---
>
> Key: IGNITE-4524
> URL: https://issues.apache.org/jira/browse/IGNITE-4524
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Sergey Kalashnikov
>  Labels: important
> Fix For: 2.0
>
>
> If to execute queries like this
> {code}
> select min(id) from MyValue
> select max(id) from MyValue
> {code}
> assuming that 'id' is an indexed field then the engine will not gain from 
> this. 
> The SQL engine needs to be improved so that the indexes are used for queries 
> like the ones above.
> More details can be found in this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/min-max-SQL-and-indexes-td13492.html



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

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2703:


Github user ptupitsyn closed the pull request at:

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


> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api, important
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



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

[jira] [Commented] (IGNITE-4524) Indexes usage in SQL functions like min/max

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4524:


GitHub user skalashnikov opened a pull request:

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

IGNITE-4524: Index direct lookup for SQL functions MIN() and MAX()



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

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

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

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


commit 7ce61b7d08cb54f5355ae51657a3df37766a30b6
Author: Sergey Chugunov 
Date:   2017-03-31T09:32:04Z

IndexingSpi test fixed

commit 261a5eeafdc9f7db8446ca6b58896c9a249ee618
Author: Sergey Chugunov 
Date:   2017-03-31T10:53:26Z

H2CompareBigQueryTest configuration issue (probably introduced with merge) 
fixed

commit 5b5c838060e8d0c9160a82caa3b9052d0f5e8d69
Author: Dmitriy Govorukhin 
Date:   2017-03-31T12:01:39Z

ignite-3477-master fix (node can't s obtain write lock on stop)

commit c7f8c4682cccf17d9fad007e2152422e545aeaa8
Author: Dmitriy Govorukhin 
Date:   2017-03-31T12:13:42Z

ignite-3477-master minor update import

commit 3f49b18ef85009893ed9f22ac0368263cb417e05
Author: Dmitriy Govorukhin 
Date:   2017-03-31T12:14:40Z

Merge branch 'ignite-3477-master-apache' into ignite-3477-master

commit 5cf3f05d476407e7a8bcdacb516f8d826c968300
Author: Ilya Lantukh 
Date:   2017-03-31T12:35:44Z

Fixed GridCacheAtomicEntryProcessorDeploymentSelfTest.

commit f701c6af2198ea22ef59f57063e053db7536f3cd
Author: Ilya Lantukh 
Date:   2017-03-31T12:36:30Z

Merge branch 'ignite-3477-master' of 
https://github.com/gridgain/apache-ignite into ignite-3477-master

commit 4af9d8f99ae22687c49783e36c7bc0c1b206c342
Author: skalashnikov 
Date:   2017-03-31T13:19:05Z

IGNITE-4524: Index direct lookup for SQL functions MIN() and MAX()




> Indexes usage in SQL functions like min/max
> ---
>
> Key: IGNITE-4524
> URL: https://issues.apache.org/jira/browse/IGNITE-4524
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Reporter: Denis Magda
>Assignee: Sergey Kalashnikov
>  Labels: important
> Fix For: 2.0
>
>
> If to execute queries like this
> {code}
> select min(id) from MyValue
> select max(id) from MyValue
> {code}
> assuming that 'id' is an indexed field then the engine will not gain from 
> this. 
> The SQL engine needs to be improved so that the indexes are used for queries 
> like the ones above.
> More details can be found in this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/min-max-SQL-and-indexes-td13492.html



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

[jira] [Commented] (IGNITE-4625) .NET: MixedClusterTest leaves Java-only node running

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4625:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4625 .NET: MixedClusterTest leaves Java-only node running



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

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

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

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


commit eab761e99a8da7087fa753f2e66d074a8a0d0b8b
Author: Pavel Tupitsyn 
Date:   2017-03-31T13:08:39Z

fix AbstractTaskTest teardown

commit 5de99a6b63ce589365b10d65354cc83064d96b0d
Author: Pavel Tupitsyn 
Date:   2017-03-31T13:13:45Z

Fix DeploymentTest




> .NET: MixedClusterTest leaves Java-only node running
> 
>
> Key: IGNITE-4625
> URL: https://issues.apache.org/jira/browse/IGNITE-4625
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> MixedClusterTest causes consequent tests to fail in some situations because 
> it leaves java-only "grid2" node running. Looks like ExecuteJavaTask does not 
> stop node properly.



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

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2703:
-

[~ptupitsyn], LGTM.

> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api, important
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



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

[jira] [Commented] (IGNITE-4898) Add path to ODBC driver installers to platforms\cpp\odbc\README.txt

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4898:
-

[~dmagda] sure, will do.

> Add path to ODBC driver installers to platforms\cpp\odbc\README.txt
> ---
>
> Key: IGNITE-4898
> URL: https://issues.apache.org/jira/browse/IGNITE-4898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Irina Zaporozhtseva
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.0
>
>
> Add path to ODBC driver installers (/cpp/bin/odbc/) to 
> platforms\cpp\odbc\README.txt:
> "There are two ways to install ODBC driver currently. The first one is to use
> 32-bit or 64-bit installer. This is the most simple way and you are 
> recommended to stick to it by default."



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

[jira] [Commented] (IGNITE-3585) CPP: Rework methods that accept containers so any container could be used with them.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3585:


GitHub user isapego opened a pull request:

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

IGNITE-3585 CPP: Container-based methods now accept iterators.



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

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

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

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


commit de19ce621ba6d82c759a1e96d0b8b610bab9d4fb
Author: Igor Sapego 
Date:   2017-03-24T15:48:38Z

IGNITE-3585: Implemented for Cursor::GetAll

commit 7f8e735a8a52dc96c89bedd8be00fab2bafcb4b4
Author: Igor Sapego 
Date:   2017-03-27T11:45:16Z

IGNITE-3585: Fixed tests

commit 5b2c2b6218213e8e2a5149c42052095eacc82107
Author: Igor Sapego 
Date:   2017-03-29T17:58:15Z

IGNITE-3585: Implemented for ContainsKeys

commit c0dba0e0109cc73cf3c9757c155d46bacf3a9c72
Author: Igor Sapego 
Date:   2017-03-30T17:20:44Z

IGNITE-3585: Implemented for PutAll

commit be8af85892b17168364e3671c310a20f7d49afa2
Author: Igor Sapego 
Date:   2017-03-31T11:56:24Z

IGNITE-3585: Implemented GetAll

commit 3347971262d924b07a298eab020a1cc8cb89006a
Author: Igor Sapego 
Date:   2017-03-31T12:10:58Z

IGNITE-3585: Implemented for LocalEvict

commit 046d848aad1aa573a66468fb13efd279adbadb88
Author: Igor Sapego 
Date:   2017-03-31T12:25:25Z

IGNITE-3585: Implemented for ClearAll and LocalClearAll

commit 1e11a6209aa9231e78c318afc70b429c85f9a927
Author: Igor Sapego 
Date:   2017-03-31T12:33:52Z

IGNITE-3585: Implemented for RemoveAll

commit 28dc1b966381480e63aa8cef27a5e3fafdbda46d
Author: Igor Sapego 
Date:   2017-03-31T12:54:40Z

Merge remote-tracking branch 'upstream/master' into ignite-3585




> CPP: Rework methods that accept containers so any container could be used 
> with them.
> 
>
> Key: IGNITE-3585
> URL: https://issues.apache.org/jira/browse/IGNITE-3585
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.0
>
>
> There are methods that could possibly be used with any container but by some 
> reason they only accept arguments of a single specific container type. It can 
> be non convenient for user and bad from the performance point of view if user 
> uses other container type to store values. Consider using iterators 
> (preferably) or template type for the container.
> Methods of interest:
> - {{QueryCursor::GetAll}}
> - {{Cache::ContainsKeys}}
> - {{Cache::GetAll}}
> - {{Cache::PutAll}}
> - {{Cache::LocalEvict}}
> - {{Cache::ClearAll}}
> - {{Cache::LocalClearAll}}
> - {{Cache::RemoveAll}}.



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

[jira] [Updated] (IGNITE-4898) Add path to ODBC driver installers to platforms\cpp\odbc\README.txt

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4898:

Priority: Critical  (was: Trivial)

> Add path to ODBC driver installers to platforms\cpp\odbc\README.txt
> ---
>
> Key: IGNITE-4898
> URL: https://issues.apache.org/jira/browse/IGNITE-4898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Irina Zaporozhtseva
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.0
>
>
> Add path to ODBC driver installers (/cpp/bin/odbc/) to 
> platforms\cpp\odbc\README.txt:
> "There are two ways to install ODBC driver currently. The first one is to use
> 32-bit or 64-bit installer. This is the most simple way and you are 
> recommended to stick to it by default."



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

[jira] [Commented] (IGNITE-4898) Add path to ODBC driver installers to platforms\cpp\odbc\README.txt

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4898:
-

[~isapego], please review and update the readme.io documentation if needed.

> Add path to ODBC driver installers to platforms\cpp\odbc\README.txt
> ---
>
> Key: IGNITE-4898
> URL: https://issues.apache.org/jira/browse/IGNITE-4898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Irina Zaporozhtseva
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 2.0
>
>
> Add path to ODBC driver installers (/cpp/bin/odbc/) to 
> platforms\cpp\odbc\README.txt:
> "There are two ways to install ODBC driver currently. The first one is to use
> 32-bit or 64-bit installer. This is the most simple way and you are 
> recommended to stick to it by default."



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

[jira] [Assigned] (IGNITE-4898) Add path to ODBC driver installers to platforms\cpp\odbc\README.txt

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-4898:
---

Assignee: Igor Sapego

> Add path to ODBC driver installers to platforms\cpp\odbc\README.txt
> ---
>
> Key: IGNITE-4898
> URL: https://issues.apache.org/jira/browse/IGNITE-4898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Irina Zaporozhtseva
>Assignee: Igor Sapego
>Priority: Trivial
> Fix For: 2.0
>
>
> Add path to ODBC driver installers (/cpp/bin/odbc/) to 
> platforms\cpp\odbc\README.txt:
> "There are two ways to install ODBC driver currently. The first one is to use
> 32-bit or 64-bit installer. This is the most simple way and you are 
> recommended to stick to it by default."



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

[jira] [Assigned] (IGNITE-4625) .NET: MixedClusterTest leaves Java-only node running

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4625:
--

Assignee: Pavel Tupitsyn

> .NET: MixedClusterTest leaves Java-only node running
> 
>
> Key: IGNITE-4625
> URL: https://issues.apache.org/jira/browse/IGNITE-4625
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> MixedClusterTest causes consequent tests to fail in some situations because 
> it leaves java-only "grid2" node running. Looks like ExecuteJavaTask does not 
> stop node properly.



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

[jira] [Updated] (IGNITE-4898) Add path to ODBC driver installers to platforms\cpp\odbc\README.txt

[Irina Zaporozhtseva (JIRA)]

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

Irina Zaporozhtseva updated IGNITE-4898:

Fix Version/s: 2.0

> Add path to ODBC driver installers to platforms\cpp\odbc\README.txt
> ---
>
> Key: IGNITE-4898
> URL: https://issues.apache.org/jira/browse/IGNITE-4898
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Irina Zaporozhtseva
>Priority: Trivial
> Fix For: 2.0
>
>
> Add path to ODBC driver installers (/cpp/bin/odbc/) to 
> platforms\cpp\odbc\README.txt:
> "There are two ways to install ODBC driver currently. The first one is to use
> 32-bit or 64-bit installer. This is the most simple way and you are 
> recommended to stick to it by default."



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

[jira] [Created] (IGNITE-4898) Add path to ODBC driver installers to platforms\cpp\odbc\README.txt

[Irina Zaporozhtseva (JIRA)]

Irina Zaporozhtseva created IGNITE-4898:
---

 Summary: Add path to ODBC driver installers to 
platforms\cpp\odbc\README.txt
 Key: IGNITE-4898
 URL: https://issues.apache.org/jira/browse/IGNITE-4898
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Irina Zaporozhtseva
Priority: Trivial


Add path to ODBC driver installers (/cpp/bin/odbc/) to 
platforms\cpp\odbc\README.txt:

"There are two ways to install ODBC driver currently. The first one is to use
32-bit or 64-bit installer. This is the most simple way and you are recommended 
to stick to it by default."



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

[jira] [Resolved] (IGNITE-3506) .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-3506.

Resolution: Fixed

> .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants
> 
>
> Key: IGNITE-3506
> URL: https://issues.apache.org/jira/browse/IGNITE-3506
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> 1) Abbreviations should not be used
> 2) Constants in generic class are not good
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Commented] (IGNITE-3506) .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3506:


Merged to master

> .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants
> 
>
> Key: IGNITE-3506
> URL: https://issues.apache.org/jira/browse/IGNITE-3506
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> 1) Abbreviations should not be used
> 2) Constants in generic class are not good
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 12:04 PM:
---

The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem ({{perNodeParallelBatchCount}} should be > 0, but it is 16 by default):
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem:
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)

> NPE in reading 

[jira] [Assigned] (IGNITE-4896) OptimizedMarshaller should not failed on GridClientNodeBean serialization

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4896:


Assignee: Valentin Kulichenko  (was: Alexey Kuznetsov)

[~vkulichenko] Could you review my changes?
See https://github.com/gridgain/apache-ignite/pull/63

> OptimizedMarshaller should not failed on GridClientNodeBean serialization
> -
>
> Key: IGNITE-4896
> URL: https://issues.apache.org/jira/browse/IGNITE-4896
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 1.9
>Reporter: Alexey Kuznetsov
>Assignee: Valentin Kulichenko
> Fix For: 2.0
>
>
> If node attributes contain some unknown for Optimized marshaller classes (not 
> present in classnames.properties) it will failed to serialize them.
> I think it is better to skip such objects and print warning in node log and 
> GridClient log.



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

[jira] [Commented] (IGNITE-3506) .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3506:


Github user asfgit closed the pull request at:

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


> .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class constants
> 
>
> Key: IGNITE-3506
> URL: https://issues.apache.org/jira/browse/IGNITE-3506
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api
> Fix For: 2.0
>
>
> 1) Abbreviations should not be used
> 2) Constants in generic class are not good
> 2.0 migration guide has to be updated if needed: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide



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

[jira] [Assigned] (IGNITE-4891) Key is deserialized during transactional get() even if withKeepBinary is set

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-4891:
---

Assignee: Dmitry Karachentsev

> Key is deserialized during transactional get() even if withKeepBinary is set
> 
>
> Key: IGNITE-4891
> URL: https://issues.apache.org/jira/browse/IGNITE-4891
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Critical
> Fix For: 2.0
>
>
> This test reproduces the issue: https://github.com/olegskoblya/tx-binary-bug



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

[jira] [Comment Edited] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-2703 at 3/31/17 11:44 AM:
--

1) Done, log warning added: "Type 'x' implements 'ISerializable'. It will be 
written in Ignite binary format, however, the following limitations apply: 
DateTime fields would not work in SQL; sbyte, ushort, uint, ulong fields would 
not work in DML."

2) Flag added. SQL and DML tests for {{ISerializable}} added.

{{uint}} and such can be used from DML when the value fits in {{int}} range. 
Otherwise an object is created in cache, but when deserializing, 
{{OverflowException}} is thrown in user code within 
{{ISerializable.GetObjectData}}.


was (Author: ptupitsyn):
1) Done, log warning added: "Type '{0}' implements '{1}'. It will be written in 
Ignite binary format, however, the following limitations apply: DateTime fields 
would not work in SQL; sbyte, ushort, uint, ulong fields would not work in DML."

2) Flag added. SQL and DML tests for {{ISerializable}} added.

{{uint}} and such can be used from DML when the value fits in {{int}} range, 
otherwise an {{OverflowException}} is thrown in user code within 
{{ISerializable.GetObjectData}}.

> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api, important
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



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

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2703:


1) Done, log warning added: "Type '{0}' implements '{1}'. It will be written in 
Ignite binary format, however, the following limitations apply: DateTime fields 
would not work in SQL; sbyte, ushort, uint, ulong fields would not work in DML."

2) Flag added. SQL and DML tests for {{ISerializable}} added.

{{uint}} and such can be used from DML when the value fits in {{int}} range, 
otherwise an {{OverflowException}} is thrown in user code within 
{{ISerializable.GetObjectData}}.

> .NET: Dynamically registered classes must use binary serialization if possible
> --
>
> Key: IGNITE-2703
> URL: https://issues.apache.org/jira/browse/IGNITE-2703
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>  Labels: .net, breaking-api, important
> Fix For: 2.0
>
>
> At present we support dynamic class registration in .NET, but they are 
> written using deafult .NET mechanism. This is counterintuitive for users and 
> not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could 
> be serialized through binary or not. If not - print a warning and fallback to 
> .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is 
> known to the cluster. If not - write full class name instead of type ID. Java 
> already do that.
> 3) Last, to support backward compatibility we must be able to fallback to 
> current mode with help of some boolean flag.



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

[jira] [Closed] (IGNITE-4888) An assertion error in TcpDiscoverySelfTest

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov closed IGNITE-4888.
-

> An assertion error in TcpDiscoverySelfTest
> --
>
> Key: IGNITE-4888
> URL: https://issues.apache.org/jira/browse/IGNITE-4888
> Project: Ignite
>  Issue Type: Bug
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>
> The exception as shown below sometimes appears in output:
> {noformat}
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:735)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:503)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1678)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Assigned] (IGNITE-4897) Web console: Do not escape optional symbols in XML

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-4897:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web console: Do not escape optional symbols in XML
> --
>
> Key: IGNITE-4897
> URL: https://issues.apache.org/jira/browse/IGNITE-4897
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.0
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> Optional symbols >, ', " can be not escaped.



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

[jira] [Commented] (IGNITE-4897) Web console: Do not escape optional symbols in XML

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-4897:
---

Removed escaping of optional symbols in generated XML.

> Web console: Do not escape optional symbols in XML
> --
>
> Key: IGNITE-4897
> URL: https://issues.apache.org/jira/browse/IGNITE-4897
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.0
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>
> Optional symbols >, ', " can be not escaped.



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

[jira] [Created] (IGNITE-4897) Web console: Do not escape optional symbols in XML

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-4897:
-

 Summary: Web console: Do not escape optional symbols in XML
 Key: IGNITE-4897
 URL: https://issues.apache.org/jira/browse/IGNITE-4897
 Project: Ignite
  Issue Type: Task
  Components: wizards
Affects Versions: 2.0
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


Optional symbols >, ', " can be not escaped.



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

[jira] [Created] (IGNITE-4896) OptimizedMarshaller should not failed on GridClientNodeBean serialization

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-4896:


 Summary: OptimizedMarshaller should not failed on 
GridClientNodeBean serialization
 Key: IGNITE-4896
 URL: https://issues.apache.org/jira/browse/IGNITE-4896
 Project: Ignite
  Issue Type: Bug
  Components: clients
Affects Versions: 1.9
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.0


If node attributes contain some unknown for Optimized marshaller classes (not 
present in classnames.properties) it will failed to serialize them.

I think it is better to skip such objects and print warning in node log and 
GridClient log.



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

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 10:19 AM:
---

The property {{prefetchBlocks}} must be set to non-zero value to reproduce the 
problem:
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The property ```prefetchBlocks``` must be set to non-zero value to reproduce 
the problem:
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)

> NPE in reading data from IGFS
> -
>
> 

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 10:17 AM:
---

The property `prefetchBlocks` must be set to non-zero value to reproduce the 
problem:
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The following properties should be set to reproduce the problem:
{code}



{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)

> NPE in reading data from IGFS
> -
>
> Key: IGNITE-4862
>   

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 10:18 AM:
---

The property ```prefetchBlocks``` must be set to non-zero value to reproduce 
the problem:
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The property `prefetchBlocks` must be set to non-zero value to reproduce the 
problem:
{code}

 .

{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)

> NPE in reading data from IGFS
> -
>
> Key: 

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 10:12 AM:
---

The following properties should be set to reproduce the problem:
{code}



{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The following properties should be set to reproduce the problem:
{code}





{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)

> NPE in reading data from IGFS
> -
>
> Key: IGNITE-4862
> 

[jira] [Comment Edited] (IGNITE-4862) NPE in reading data from IGFS

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4862 at 3/31/17 10:12 AM:
---

The following properties should be set to reproduce the problem:
{code}





{code}

The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)


was (Author: iveselovskiy):
The following exception happens on the Ignite node at the same time: 
{code}
Exception in thread "igfs-#50%null%" java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable.read(HadoopIgfsSecondaryFileSystemPositionedReadable.java:104)
at 
org.apache.ignite.internal.processors.igfs.IgfsLazySecondaryFileSystemPositionedReadable.read(IgfsLazySecondaryFileSystemPositionedReadable.java:64)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager.secondaryDataBlock(IgfsDataManager.java:419)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:357)
at 
org.apache.ignite.internal.processors.igfs.IgfsDataManager$4.applyx(IgfsDataManager.java:346)
at 
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener.access$000(GridFutureChainListener.java:30)
at 
org.apache.ignite.internal.util.future.GridFutureChainListener$1.run(GridFutureChainListener.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}

The problem is that class 
`org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable`
 was designed fro single-threaded access, but in fact was accessed by multiple 
threads. That lead to unexpected situation, when 
org.apache.ignite.internal.processors.hadoop.impl.igfs.HadoopIgfsSecondaryFileSystemPositionedReadable#in
 returned null , that caused a bunch of further errors. 
Fixed by making HadoopIgfsSecondaryFileSystemPositionedReadable thread safe 
(underlying secondary file system input stream has its own mechanisms to 
preserve consistency upon multithreaded access.)

> NPE in reading data from IGFS
> -
>
> Key: IGNITE-4862
> URL: https://issues.apache.org/jira/browse/IGNITE-4862
> Project: Ignite
>  Issue Type: Bug
>  Components: 

[jira] [Commented] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException

[Michael Griggs (JIRA)]

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

Michael Griggs commented on IGNITE-4878:


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

> IgniteH2Indexing can throw java.util.ConcurrentModificationException
> 
>
> Key: IGNITE-4878
> URL: https://issues.apache.org/jira/browse/IGNITE-4878
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> From the Collections#synchronizedCollection method:
> {noformat}
>  * It is imperative that the user manually synchronize on the returned
>  * collection when traversing it via {@link Iterator}, {@link Spliterator}
>  * or {@link Stream}:
>  * 
>  *  Collection c = Collections.synchronizedCollection(myCollection);
>  * ...
>  *  synchronized (c) {
>  *  Iterator i = c.iterator(); // Must be in the synchronized block
>  *  while (i.hasNext())
>  * foo(i.next());
>  *  }
>  * 
>  * Failure to follow this advice may result in non-deterministic behavior.
> {noformat}



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

[jira] [Issue Comment Deleted] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException

[Michael Griggs (JIRA)]

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

Michael Griggs updated IGNITE-4878:
---
Comment: was deleted

(was: https://github.com/apache/ignite/pull/1692)

> IgniteH2Indexing can throw java.util.ConcurrentModificationException
> 
>
> Key: IGNITE-4878
> URL: https://issues.apache.org/jira/browse/IGNITE-4878
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> From the Collections#synchronizedCollection method:
> {noformat}
>  * It is imperative that the user manually synchronize on the returned
>  * collection when traversing it via {@link Iterator}, {@link Spliterator}
>  * or {@link Stream}:
>  * 
>  *  Collection c = Collections.synchronizedCollection(myCollection);
>  * ...
>  *  synchronized (c) {
>  *  Iterator i = c.iterator(); // Must be in the synchronized block
>  *  while (i.hasNext())
>  * foo(i.next());
>  *  }
>  * 
>  * Failure to follow this advice may result in non-deterministic behavior.
> {noformat}



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

[jira] [Created] (IGNITE-4895) TC should fail suite if AssertionError is output to logs

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-4895:
-

 Summary: TC should fail suite if AssertionError is output to logs
 Key: IGNITE-4895
 URL: https://issues.apache.org/jira/browse/IGNITE-4895
 Project: Ignite
  Issue Type: Test
Reporter: Yakov Zhdanov
Assignee: Anton Vinogradov
Priority: Blocker
 Fix For: 2.0


AssertionError is never thrown on purpose during the tests opposite to 
exceptions which are normal for plenty of scenarios.

TC should fail if assertion error is output to logs.



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

[jira] [Commented] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-4727:


Merged to master.

> Web Console: Fix the position of tooltips in modal windows
> --
>
> Key: IGNITE-4727
> URL: https://issues.apache.org/jira/browse/IGNITE-4727
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Attachments: tooltips.png
>
>
> Tooltips (in modal windows) should not go beyond the modal windows.



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

[jira] [Closed] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-4727.
--
Assignee: Alexey Kuznetsov  (was: Andrey Novikov)

> Web Console: Fix the position of tooltips in modal windows
> --
>
> Key: IGNITE-4727
> URL: https://issues.apache.org/jira/browse/IGNITE-4727
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Attachments: tooltips.png
>
>
> Tooltips (in modal windows) should not go beyond the modal windows.



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

[jira] [Updated] (IGNITE-4892) Support DML for thin client based JDBC driver

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4892:

Component/s: SQL
 jdbc-driver

> Support DML for thin client based JDBC driver
> -
>
> Key: IGNITE-4892
> URL: https://issues.apache.org/jira/browse/IGNITE-4892
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc-driver, SQL
>Reporter: Denis Magda
> Fix For: 2.1
>
>
> Support all DML operations for the thin client based JDBC driver:
> https://apacheignite.readme.io/docs/jdbc-driver#hostname-based-jdbc-connection



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

[jira] [Updated] (IGNITE-4893) Release Ignite JDBC driver(s) under a single JAR

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4893:

Component/s: SQL
 jdbc-driver

> Release Ignite JDBC driver(s) under a single JAR
> 
>
> Key: IGNITE-4893
> URL: https://issues.apache.org/jira/browse/IGNITE-4893
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc-driver, SQL
>Reporter: Denis Magda
>
> Presently, if someone uses the client node based driver (with Spring XML 
> config) from an SQL tool we demand to add to the classpath all the jars from 
> "libs" and "ignite-spring", "ignite-indexing" subdirectories (up to 15! jars 
> in total).
> As for the thin client based driver, the things are easier but the driver is 
> in "ignite-core.jar".
> It would be more user-friendly if the JDBC drivers are packaged under single 
> “ignite-jdbc.jar” and located in special directory of a release bundle. All 
> the dependencies have to be in this jar.



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

[jira] [Commented] (IGNITE-4803) Create a test to check processing doesn't break when discovery cache history overflows

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4803:


Github user gvvinblade closed the pull request at:

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


> Create a test to check processing doesn't break when discovery cache history 
> overflows
> --
>
> Key: IGNITE-4803
> URL: https://issues.apache.org/jira/browse/IGNITE-4803
> Project: Ignite
>  Issue Type: Test
>Reporter: Igor Seliverstov
> Fix For: 2.0
>
>




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

[jira] [Commented] (IGNITE-4888) An assertion error in TcpDiscoverySelfTest

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4888:


Github user gvvinblade closed the pull request at:

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


> An assertion error in TcpDiscoverySelfTest
> --
>
> Key: IGNITE-4888
> URL: https://issues.apache.org/jira/browse/IGNITE-4888
> Project: Ignite
>  Issue Type: Bug
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>
> The exception as shown below sometimes appears in output:
> {noformat}
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:735)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:503)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1678)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Commented] (IGNITE-4779) Missed discovery data snapshot during exchange processing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4779:


Github user gvvinblade closed the pull request at:

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


> Missed discovery data snapshot during exchange processing
> -
>
> Key: IGNITE-4779
> URL: https://issues.apache.org/jira/browse/IGNITE-4779
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Priority: Critical
> Fix For: 2.0
>
>
> Currently GridDiscoveryManager stores only 500 last discovery data snapshots, 
> if in 'resolveDiscoCache' requested version is not available it just throws 
> IgniteException. It is possible while exchange is processed on topology 
> version N, lot of discovery events is generated (e.g. in case of client 
> caches start) and version N is removed from history. For exchange solution is 
> simple: when exchange is triggered need save discovery snapshot in exchange 
> future.
> Also need review others places where discovery history is used.



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

[jira] [Assigned] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows

[Vica Abramova (JIRA)]

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

Vica Abramova reassigned IGNITE-4727:
-

Assignee: Andrey Novikov  (was: Vica Abramova)

> Web Console: Fix the position of tooltips in modal windows
> --
>
> Key: IGNITE-4727
> URL: https://issues.apache.org/jira/browse/IGNITE-4727
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Andrey Novikov
>Priority: Minor
> Attachments: tooltips.png
>
>
> Tooltips (in modal windows) should not go beyond the modal windows.



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

[jira] [Commented] (IGNITE-4727) Web Console: Fix the position of tooltips in modal windows

[Vica Abramova (JIRA)]

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

Vica Abramova commented on IGNITE-4727:
---

[~anovikov], done! Everything is good.

> Web Console: Fix the position of tooltips in modal windows
> --
>
> Key: IGNITE-4727
> URL: https://issues.apache.org/jira/browse/IGNITE-4727
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Vica Abramova
>Priority: Minor
> Attachments: tooltips.png
>
>
> Tooltips (in modal windows) should not go beyond the modal windows.



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

[jira] [Resolved] (IGNITE-4888) An assertion error in TcpDiscoverySelfTest

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov resolved IGNITE-4888.
---
Resolution: Fixed

I have merged the changes. Thanks for contribution.

> An assertion error in TcpDiscoverySelfTest
> --
>
> Key: IGNITE-4888
> URL: https://issues.apache.org/jira/browse/IGNITE-4888
> Project: Ignite
>  Issue Type: Bug
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>
> The exception as shown below sometimes appears in output:
> {noformat}
> java.lang.AssertionError
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:735)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:503)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1678)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2313:


GitHub user SomeFire opened a pull request:

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

IGNITE-2313



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

$ git pull https://github.com/SomeFire/ignite ignite-2313

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

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


commit 630f6db753e1fee024209cd122b7f3aae991cee4
Author: Дмитрий Рябов 
Date:   2017-03-06T12:53:27Z

Merge pull request #2 from apache/master

update

commit 1c6c3adf7d6b504e2f805c8fbb2139652f6dbd15
Author: Dmitrii Ryabov 
Date:   2017-03-30T08:25:56Z

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

commit abae25b3ecd364c3924167d1ca04bffcd21c3bc9
Author: Dmitrii Ryabov 
Date:   2017-03-30T13:17:07Z

Atomic cache throws exception while in transaction now.




> 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: Blocker
> Fix For: 2.0
>
>
> 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
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-4839) Remove CacheTypeMetadata

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4839 at 3/31/17 8:06 AM:
---

Tests 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1667%2Fhead]
 is OK with me.


was (Author: tledkov-gridgain):
Waits fo TC 
[results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1667%2Fhead]
 again

> Remove CacheTypeMetadata
> 
>
> Key: IGNITE-4839
> URL: https://issues.apache.org/jira/browse/IGNITE-4839
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>




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

[jira] [Assigned] (IGNITE-4564) Ensure that builder approach is used for all setters in public API

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4564:
---

Assignee: Andrew Mashenkov  (was: Vladimir Ozerov)

> Ensure that builder approach is used for all setters in public API
> --
>
> Key: IGNITE-4564
> URL: https://issues.apache.org/jira/browse/IGNITE-4564
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Andrew Mashenkov
>  Labels: important
> Fix For: 2.0
>
>
> *Problem*
> We employed "builder" approach for some configuration classes:
> {code}
> class Configuration {
> Configuration setSomething(Something);
> }
> {code}
> This is very convenient for users. However, only part of our configs employ 
> this approach.
> *Task*
> Let's make sure that all other parts of our API follow this rule.



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

[jira] [Commented] (IGNITE-4564) Ensure that builder approach is used for all setters in public API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4564:


Github user asfgit closed the pull request at:

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


> Ensure that builder approach is used for all setters in public API
> --
>
> Key: IGNITE-4564
> URL: https://issues.apache.org/jira/browse/IGNITE-4564
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: important
> Fix For: 2.0
>
>
> *Problem*
> We employed "builder" approach for some configuration classes:
> {code}
> class Configuration {
> Configuration setSomething(Something);
> }
> {code}
> This is very convenient for users. However, only part of our configs employ 
> this approach.
> *Task*
> Let's make sure that all other parts of our API follow this rule.



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

[jira] [Commented] (IGNITE-4847) Upgrade log4j2 to version 2.8.1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4847:


Github user endian675 closed the pull request at:

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


> Upgrade log4j2 to version 2.8.1
> ---
>
> Key: IGNITE-4847
> URL: https://issues.apache.org/jira/browse/IGNITE-4847
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>Priority: Minor
> Fix For: 2.0
>
>




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

[jira] [Created] (IGNITE-4894) Yardstick-Cassandra

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-4894:


 Summary: Yardstick-Cassandra
 Key: IGNITE-4894
 URL: https://issues.apache.org/jira/browse/IGNITE-4894
 Project: Ignite
  Issue Type: New Feature
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin
Priority: Minor
 Fix For: 2.1


We need to create a project based on Yardstick framework which we could use to 
compare Ignite performance against Apache Cassandra.



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

[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-4211:


[~avinogradov]
Your notes were resolved.
But I have one question at the Upsorce, about cluster with 2+ nodes test. (If 
it is necessary)
[ci.tests|http://ci.ignite.apache.org/viewLog.html?buildId=524207] look good.
Please, rewiew it again, thanks.

> Update Spring dependency to latest stable version
> -
>
> Key: IGNITE-4211
> URL: https://issues.apache.org/jira/browse/IGNITE-4211
> Project: Ignite
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.7
>Reporter: Sergey Kozlov
>Assignee: Vyacheslav Daradur
> Fix For: 2.0
>
>
> It seems the Spring dependency looks outdated for now. Apache Ignite still 
> uses 4.1.0 released two years ago. Could we to update to latest stable 
> version (4.3.4 at the moment)?



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