[jira] [Comment Edited] (IGNITE-3318) Web console: schema name must be unique for each cache

2016-09-27 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko edited comment on IGNITE-3318 at 9/28/16 4:42 AM:


Added showing of message when SQL query name is cleared. 
Fixed case when clusters are not selected.
ignite-3318


was (Author: vsisko):
Added showing of message when SQL query name is cleared. ignite-3318

> Web console: schema name must be unique for each cache
> --
>
> Key: IGNITE-3318
> URL: https://issues.apache.org/jira/browse/IGNITE-3318
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
> Fix For: 1.8
>
>
> Currently we don't check that schema name is unique.
> Just clone cache with schema name ans Save.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-3318) Web console: schema name must be unique for each cache

2016-09-27 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko reassigned IGNITE-3318:
-

Assignee: Vasiliy Sisko  (was: Alexey Kuznetsov)

> Web console: schema name must be unique for each cache
> --
>
> Key: IGNITE-3318
> URL: https://issues.apache.org/jira/browse/IGNITE-3318
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
> Fix For: 1.8
>
>
> Currently we don't check that schema name is unique.
> Just clone cache with schema name ans Save.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3986) Web console: Wrong defaults in special case

2016-09-27 Thread Vasiliy Sisko (JIRA)
Vasiliy Sisko created IGNITE-3986:
-

 Summary: Web console: Wrong defaults in special case
 Key: IGNITE-3986
 URL: https://issues.apache.org/jira/browse/IGNITE-3986
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.8
Reporter: Vasiliy Sisko


On cache with configured cluster:
# Clear cluster and save cache,
# Clone cache,
# Set cluster in cache clone and save,
# Switch to source cache.
Source cache show configured cluster of clone cache.
On refresh of page source cache show empty clusters field.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3985) Web Console: Refactor test database init in backend tests.

2016-09-27 Thread Andrey Novikov (JIRA)
Andrey Novikov created IGNITE-3985:
--

 Summary: Web Console: Refactor test database init in backend tests.
 Key: IGNITE-3985
 URL: https://issues.apache.org/jira/browse/IGNITE-3985
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 1.8
Reporter: Andrey Novikov
Priority: Minor
 Fix For: 1.8


Need simplify database init before test. As example may be  used 
modules/web-console/backend/test/unit/AuthService.test.js



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-3985) Web Console: Refactor test database init in backend tests.

2016-09-27 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko reassigned IGNITE-3985:
-

Assignee: Vasiliy Sisko

> Web Console: Refactor test database init in backend tests.
> --
>
> Key: IGNITE-3985
> URL: https://issues.apache.org/jira/browse/IGNITE-3985
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Andrey Novikov
>Assignee: Vasiliy Sisko
>Priority: Minor
> Fix For: 1.8
>
>
> Need simplify database init before test. As example may be  used 
> modules/web-console/backend/test/unit/AuthService.test.js



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (IGNITE-3262) Web console: Implement test runner

2016-09-27 Thread Andrey Novikov (JIRA)

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

Andrey Novikov resolved IGNITE-3262.

Resolution: Fixed

Reviewed. Merged.

> Web console: Implement test runner 
> ---
>
> Key: IGNITE-3262
> URL: https://issues.apache.org/jira/browse/IGNITE-3262
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (IGNITE-3262) Web console: Implement test runner

2016-09-27 Thread Andrey Novikov (JIRA)

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

Andrey Novikov closed IGNITE-3262.
--
Assignee: (was: Andrey Novikov)

> Web console: Implement test runner 
> ---
>
> Key: IGNITE-3262
> URL: https://issues.apache.org/jira/browse/IGNITE-3262
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Dmitriy Shabalin
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (IGNITE-3965) @GridInternal tasks should not go through user load balancing SPI

2016-09-27 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov closed IGNITE-3965.


> @GridInternal tasks should not go through user load balancing SPI
> -
>
> Key: IGNITE-3965
> URL: https://issues.apache.org/jira/browse/IGNITE-3965
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.8
>
>
> User can specify some custom load balancing SPI, but internal task should use 
> default load balancing SPI with predictable behaviour. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-3968) Failed test VisorOpenCommandSpec

2016-09-27 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko reassigned IGNITE-3968:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Failed test VisorOpenCommandSpec
> 
>
> Key: IGNITE-3968
> URL: https://issues.apache.org/jira/browse/IGNITE-3968
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> ScalaTestFailureLocation: 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2
>  at (VisorOpenCommandSpec.scala:33)
> org.scalatest.exceptions.TestFailedException: Expected exception 
> org.apache.ignite.IgniteException to be thrown, but no exception was thrown.
>   at 
> org.scalatest.Assertions$class.newAssertionFailedException(Assertions.scala:495)
>   at org.scalatest.FunSpec.newAssertionFailedException(FunSpec.scala:1626)
>   at org.scalatest.Assertions$class.intercept(Assertions.scala:1014)
>   at org.scalatest.FunSpec.intercept(FunSpec.scala:1626)
>   at 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2.apply$mcV$sp(VisorOpenCommandSpec.scala:33)
>   at 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2.apply(VisorOpenCommandSpec.scala:33)
>   at 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2.apply(VisorOpenCommandSpec.scala:33)
>   at 
> org.scalatest.Transformer$$anonfun$apply$1.apply$mcV$sp(Transformer.scala:22)
>   at org.scalatest.OutcomeOf$class.outcomeOf(OutcomeOf.scala:85)
>   at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
>   at org.scalatest.Transformer.apply(Transformer.scala:22)
>   at org.scalatest.Transformer.apply(Transformer.scala:20)
>   at org.scalatest.FunSpecLike$$anon$1.apply(FunSpecLike.scala:422)
>   at org.scalatest.Suite$class.withFixture(Suite.scala:1122)
>   at org.scalatest.FunSpec.withFixture(FunSpec.scala:1626)
>   at 
> org.scalatest.FunSpecLike$class.invokeWithFixture$1(FunSpecLike.scala:419)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTest$1.apply(FunSpecLike.scala:431)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTest$1.apply(FunSpecLike.scala:431)
>   at org.scalatest.SuperEngine.runTestImpl(Engine.scala:306)
>   at org.scalatest.FunSpecLike$class.runTest(FunSpecLike.scala:431)
>   at 
> org.apache.ignite.visor.VisorRuntimeBaseSpec.org$scalatest$BeforeAndAfterEach$$super$runTest(VisorRuntimeBaseSpec.scala:29)
>   at 
> org.scalatest.BeforeAndAfterEach$class.runTest(BeforeAndAfterEach.scala:255)
>   at 
> org.apache.ignite.visor.VisorRuntimeBaseSpec.runTest(VisorRuntimeBaseSpec.scala:29)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTests$1.apply(FunSpecLike.scala:464)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTests$1.apply(FunSpecLike.scala:464)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:413)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:401)
>   at scala.collection.immutable.List.foreach(List.scala:381)
>   at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
>   at 
> org.scalatest.SuperEngine.org$scalatest$SuperEngine$$runTestsInBranch(Engine.scala:390)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:427)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:401)
>   at scala.collection.immutable.List.foreach(List.scala:381)
>   at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
>   at 
> org.scalatest.SuperEngine.org$scalatest$SuperEngine$$runTestsInBranch(Engine.scala:396)
>   at org.scalatest.SuperEngine.runTestsImpl(Engine.scala:483)
>   at org.scalatest.FunSpecLike$class.runTests(FunSpecLike.scala:464)
>   at org.scalatest.FunSpec.runTests(FunSpec.scala:1626)
>   at org.scalatest.Suite$class.run(Suite.scala:1424)
>   at 
> org.scalatest.FunSpec.org$scalatest$FunSpecLike$$super$run(FunSpec.scala:1626)
>   at org.scalatest.FunSpecLike$$anonfun$run$1.apply(FunSpecLike.scala:468)
>   at org.scalatest.FunSpecLike$$anonfun$run$1.apply(FunSpecLike.scala:468)
>   at org.scalatest.SuperEngine.runImpl(Engine.scala:545)
>   at org.scalatest.FunSpecLike$class.run(FunSpecLike.scala:468)
>   at 
> org.apache.ignite.visor.VisorRuntimeBaseSpec.org$scalatest$BeforeAndAfterAll$$super$run(VisorRuntimeBaseSpec.scala:29)
>   at 
> org.scalatest.BeforeAndAfterAll$class.liftedTree1$1(BeforeAndAfterAll.scala:257)
>   at 
> 

[jira] [Updated] (IGNITE-3983) CacheBinaryAutoStoreExample get wrong result

2016-09-27 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov updated IGNITE-3983:
-
Affects Version/s: (was: 1.7)
   1.8

> CacheBinaryAutoStoreExample get wrong result
> 
>
> Key: IGNITE-3983
> URL: https://issues.apache.org/jira/browse/IGNITE-3983
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.8
> Environment: Ubuntu 14.04, Win7, Apache Ignite 1.8
>Reporter: Vasilisa  Sidorova
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 1.8
>
>
> -
> DESCRIPTION
> -
> CacheBinaryAutoStoreExample get wrong result
> -
> STEPS FOR REPRODUCE
> -
> # Build examples project
> # Start H2 database TCP server using
> # Start a few nodes using ExampleNodeStartup (it's stable reproducible with 
> different numbers of nodes)
> -
> ACTUAL RESULT
> -
> {noformat}
> >>> Populate database with data...
> >>> Cache auto store example started...
> >>> Read value: null
> >>> Overwrote old value: null
> >>> Read value: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=100.1, resume=English physicist and mathematician]
> >>> Update salary in transaction...
> >>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
> >>> --
> >>> Load data to cache from DB with custom SQL...
> >>> Loaded cache entries: 3
> >>> Load ALL data to cache from DB...
> >>> Loaded cache entries: 0
> {noformat}
> -
> EXPECTED RESULT
> -
> {noformat}
> >>> Populate database with data...
> >>> Cache auto store example started...
> >>> Read value: null
> >>> Overwrote old value: null
> >>> Read value: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=100.1, resume=English physicist and mathematician]
> >>> Update salary in transaction...
> >>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
> >>> --
> >>> Load data to cache from DB with custom SQL...
> >>> Loaded cache entries: 3
> >>> Load ALL data to cache from DB...
> >>> Loaded cache entries: 7
> {noformat}
> -
> ADDITIONAL INFO
> -
> Isn't reproducible for previous versions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3983) CacheBinaryAutoStoreExample get wrong result

2016-09-27 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov updated IGNITE-3983:
-
Environment: Ubuntu 14.04, Win7, Apache Ignite 1.8  (was: Ubuntu 14.04, 
Win7, Apache Ignite 1.7.2)

> CacheBinaryAutoStoreExample get wrong result
> 
>
> Key: IGNITE-3983
> URL: https://issues.apache.org/jira/browse/IGNITE-3983
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.8
> Environment: Ubuntu 14.04, Win7, Apache Ignite 1.8
>Reporter: Vasilisa  Sidorova
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 1.8
>
>
> -
> DESCRIPTION
> -
> CacheBinaryAutoStoreExample get wrong result
> -
> STEPS FOR REPRODUCE
> -
> # Build examples project
> # Start H2 database TCP server using
> # Start a few nodes using ExampleNodeStartup (it's stable reproducible with 
> different numbers of nodes)
> -
> ACTUAL RESULT
> -
> {noformat}
> >>> Populate database with data...
> >>> Cache auto store example started...
> >>> Read value: null
> >>> Overwrote old value: null
> >>> Read value: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=100.1, resume=English physicist and mathematician]
> >>> Update salary in transaction...
> >>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
> >>> --
> >>> Load data to cache from DB with custom SQL...
> >>> Loaded cache entries: 3
> >>> Load ALL data to cache from DB...
> >>> Loaded cache entries: 0
> {noformat}
> -
> EXPECTED RESULT
> -
> {noformat}
> >>> Populate database with data...
> >>> Cache auto store example started...
> >>> Read value: null
> >>> Overwrote old value: null
> >>> Read value: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=100.1, resume=English physicist and mathematician]
> >>> Update salary in transaction...
> >>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
> >>> --
> >>> Load data to cache from DB with custom SQL...
> >>> Loaded cache entries: 3
> >>> Load ALL data to cache from DB...
> >>> Loaded cache entries: 7
> {noformat}
> -
> ADDITIONAL INFO
> -
> Isn't reproducible for previous versions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3413) Node is not started if continuous query remote filter class is not found

2016-09-27 Thread Jason Man (JIRA)

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

Jason Man commented on IGNITE-3413:
---

Hi Alexander, fixing this seem to have introduced a NullPointerException in a 
slightly different scenario.  I have filed issue IGNITE-3984 with the 
description of a scenario I encountered.

> Node is not started if continuous query remote filter class is not found
> 
>
> Key: IGNITE-3413
> URL: https://issues.apache.org/jira/browse/IGNITE-3413
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
> Fix For: 1.7
>
> Attachments: ContQueryTest.java
>
>
> Test attached.
> The scenario is the following:
> * First node starts with the special attribute and creates a cache with the 
> node filter that allows to deploy it only on nodes with this attribute.
> * Continuous query with a remote filter is executed.
> * Second node without the attribute is started. It doesn't have the remote 
> filter class, the factory throws an exception and the node doesn't start at 
> all, regardless of the fact that it doesn't even has the cache.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query

2016-09-27 Thread Jason Man (JIRA)

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

Jason Man updated IGNITE-3984:
--
Description: 
Test attached.  This used to work fine in 1.6.  This seem to be related to this 
jira and PR:

{code}
Exception in thread "main" javax.cache.CacheException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
at ContQueryTest.main(ContQueryTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:660)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery(CacheContinuousQueryManager.java:482)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.queryContinuous(IgniteCacheProxy.java:611)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
... 6 more
{code}

https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284

Here's the scenario:
* First node starts with special attribute and creates a cache with the node 
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started.  When creating a 
continuous query to query the cache created by the first node, a 
NullPointerException is thrown.

At first glance, it seems that because the NodeFilter prevented the 
GridContinuousProcessor.registerHandler() to be called , the 
ConcurrentMap rcvs is not initialized properly and 
NullPointerException is thrown on this line:
{code}
@NotNull private PartitionRecovery 
getOrCreatePartitionRecovery(GridKernalContext ctx, int partId) {
PartitionRecovery rec = rcvs.get(partId);
{code}


  was:
Test attached.  This used to work fine in 1.6.  This seem to be related to this 
jira and PR:

https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284

Here's the scenario:
* First node starts with special attribute and creates a cache with the node 
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started.  When creating a 
continuous query to query the cache created by the first node, a 
NullPointerException is thrown.


> NullPointerException in IgniteCacheProxy when creating continuous query
> ---
>
> Key: IGNITE-3984
> URL: https://issues.apache.org/jira/browse/IGNITE-3984
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Jason Man
> Attachments: ContQueryTest.java
>
>
> Test attached.  This used to work fine in 1.6.  This seem to be related to 
> this jira and PR:
> {code}
> Exception in thread "main" javax.cache.CacheException: 
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
>   at ContQueryTest.main(ContQueryTest.java:33)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
>   at 
> 

[jira] [Updated] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query

2016-09-27 Thread Jason Man (JIRA)

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

Jason Man updated IGNITE-3984:
--
Description: 
Test attached.  This used to work fine in 1.6.  

{code}
Exception in thread "main" javax.cache.CacheException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
at ContQueryTest.main(ContQueryTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:660)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery(CacheContinuousQueryManager.java:482)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.queryContinuous(IgniteCacheProxy.java:611)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
... 6 more
{code}

This seem to be related to this jira and PR:
https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284

Here's the scenario:
* First node starts with special attribute and creates a cache with the node 
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started.  When creating a 
continuous query to query the cache created by the first node, a 
NullPointerException is thrown.

At first glance, it seems that because the NodeFilter prevented the 
GridContinuousProcessor.registerHandler() to be called , the 
ConcurrentMap rcvs is not initialized properly and 
NullPointerException is thrown on this line:
{code}
@NotNull private PartitionRecovery 
getOrCreatePartitionRecovery(GridKernalContext ctx, int partId) {
PartitionRecovery rec = rcvs.get(partId);
{code}


  was:
Test attached.  This used to work fine in 1.6.  This seem to be related to this 
jira and PR:

{code}
Exception in thread "main" javax.cache.CacheException: 
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
at ContQueryTest.main(ContQueryTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:660)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery(CacheContinuousQueryManager.java:482)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.queryContinuous(IgniteCacheProxy.java:611)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
... 6 more
{code}

https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284

Here's the scenario:
* First node starts with special attribute and creates a cache with the node 
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started.  When creating a 
continuous query to query the cache created by the first node, a 
NullPointerException is thrown.

At first glance, it seems that because the NodeFilter prevented the 

[jira] [Updated] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query

2016-09-27 Thread Jason Man (JIRA)

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

Jason Man updated IGNITE-3984:
--
Attachment: ContQueryTest.java

> NullPointerException in IgniteCacheProxy when creating continuous query
> ---
>
> Key: IGNITE-3984
> URL: https://issues.apache.org/jira/browse/IGNITE-3984
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Jason Man
> Attachments: ContQueryTest.java
>
>
> Test attached.  This used to work fine in 1.6.  This seem to be related to 
> this jira and PR:
> https://issues.apache.org/jira/browse/IGNITE-3413
> https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284
> Here's the scenario:
> * First node starts with special attribute and creates a cache with the node 
> filter that allows to deploy it only on nodes with this attribute
> * Second node starts without the attribute is started.  When creating a 
> continuous query to query the cache created by the first node, a 
> NullPointerException is thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query

2016-09-27 Thread Jason Man (JIRA)
Jason Man created IGNITE-3984:
-

 Summary: NullPointerException in IgniteCacheProxy when creating 
continuous query
 Key: IGNITE-3984
 URL: https://issues.apache.org/jira/browse/IGNITE-3984
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Jason Man


Test attached.  This used to work fine in 1.6.  This seem to be related to this 
jira and PR:

https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284

Here's the scenario:
* First node starts with special attribute and creates a cache with the node 
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started.  When creating a 
continuous query to query the cache created by the first node, a 
NullPointerException is thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-3983) CacheBinaryAutoStoreExample get wrong result

2016-09-27 Thread Alexey Kuznetsov (JIRA)

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

Alexey Kuznetsov reassigned IGNITE-3983:


Assignee: Alexey Kuznetsov

> CacheBinaryAutoStoreExample get wrong result
> 
>
> Key: IGNITE-3983
> URL: https://issues.apache.org/jira/browse/IGNITE-3983
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
> Environment: Ubuntu 14.04, Win7, Apache Ignite 1.7.2
>Reporter: Vasilisa  Sidorova
>Assignee: Alexey Kuznetsov
>Priority: Critical
>
> -
> DESCRIPTION
> -
> CacheBinaryAutoStoreExample get wrong result
> -
> STEPS FOR REPRODUCE
> -
> # Build examples project
> # Start H2 database TCP server using
> # Start a few nodes using ExampleNodeStartup (it's stable reproducible with 
> different numbers of nodes)
> -
> ACTUAL RESULT
> -
> {noformat}
> >>> Populate database with data...
> >>> Cache auto store example started...
> >>> Read value: null
> >>> Overwrote old value: null
> >>> Read value: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=100.1, resume=English physicist and mathematician]
> >>> Update salary in transaction...
> >>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
> >>> --
> >>> Load data to cache from DB with custom SQL...
> >>> Loaded cache entries: 3
> >>> Load ALL data to cache from DB...
> >>> Loaded cache entries: 0
> {noformat}
> -
> EXPECTED RESULT
> -
> {noformat}
> >>> Populate database with data...
> >>> Cache auto store example started...
> >>> Read value: null
> >>> Overwrote old value: null
> >>> Read value: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=100.1, resume=English physicist and mathematician]
> >>> Update salary in transaction...
> >>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
> >>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
> >>> --
> >>> Load data to cache from DB with custom SQL...
> >>> Loaded cache entries: 3
> >>> Load ALL data to cache from DB...
> >>> Loaded cache entries: 7
> {noformat}
> -
> ADDITIONAL INFO
> -
> Isn't reproducible for previous versions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-1924) Incomplete marshaller cache rebalancing causes Grid hangs

2016-09-27 Thread Valentin Kulichenko (JIRA)

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

Valentin Kulichenko updated IGNITE-1924:

Priority: Critical  (was: Major)

> Incomplete marshaller cache rebalancing causes Grid hangs
> -
>
> Key: IGNITE-1924
> URL: https://issues.apache.org/jira/browse/IGNITE-1924
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Priority: Critical
>  Labels: Muted_test
> Fix For: 1.8
>
>
> End of the log.
> [11:49:32] :   [org.apache.ignite:ignite-core] [11:49:32,947][INFO 
> ][exchange-worker-#220584%tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander]
>   Starting rebalancing 
> [cache=ignite-marshaller-sys-cache, mode=SYNC, 
> fromNode=108bffdb-1c1e-49aa-9525-b434784fa001, partitionsCount=7, 
> topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], updateSeq=1]
> [11:49:32] :   [org.apache.ignite:ignite-core] [11:49:32,962][INFO 
> ][exchange-worker-#220584%tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander]
>   Starting rebalancing 
> [cache=ignite-marshaller-sys-cache, mode=SYNC, 
> fromNode=20660c29-91a1-4279-9dc1-88d192bc6002, partitionsCount=6, 
> topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], updateSeq=1]
> [11:49:32] :   [org.apache.ignite:ignite-core] [11:49:32,962][INFO 
> ][exchange-worker-#220584%tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander]
>   Starting rebalancing 
> [cache=ignite-marshaller-sys-cache, mode=SYNC, 
> fromNode=00b3a75a-074d-46a5-a158-3956c0ec4000, partitionsCount=7, 
> topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], updateSeq=1]
> [11:49:32] :   [org.apache.ignite:ignite-core] [11:49:32,963][INFO 
> ][ignite-#220587%marshaller-cache-tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander]
>   Completed rebalancing 
> [cache=ignite-marshaller-sys-cache, 
> fromNode=00b3a75a-074d-46a5-a158-3956c0ec4000, 
> topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], time=21 ms]
> [11:49:32] :   [org.apache.ignite:ignite-core] [11:49:32,963][INFO 
> ][ignite-#220586%marshaller-cache-tcp.IgniteCacheSslStartStopSelfTest3%][GridDhtPartitionDemander]
>   Completed rebalancing 
> [cache=ignite-marshaller-sys-cache, 
> fromNode=108bffdb-1c1e-49aa-9525-b434784fa001, 
> topology=AffinityTopologyVersion [topVer=594, minorTopVer=0], time=21 ms]
> Hang on:
> [11:51:56] :   [org.apache.ignite:ignite-core] Thread 
> [name="ignite-#220562%sys-tcp.IgniteCacheSslStartStopSelfTest3%", id=287517, 
> state=WAITING, blockCnt=0, waitCnt=3]
> [11:51:56] :   [org.apache.ignite:ignite-core] Lock 
> [object=o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture@b402f89,
>  ownerName=null, ownerId=-1]
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> sun.misc.Unsafe.park(Native Method)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.waitForCacheRebalancing(GridDhtPartitionDemander.java:265)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.access$400(GridDhtPartitionDemander.java:85)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$3.call(GridDhtPartitionDemander.java:323)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$3.call(GridDhtPartitionDemander.java:320)
> [11:51:56] :   [org.apache.ignite:ignite-core] at 
> 

[jira] [Created] (IGNITE-3983) CacheBinaryAutoStoreExample get wrong result

2016-09-27 Thread Vasilisa Sidorova (JIRA)
Vasilisa  Sidorova created IGNITE-3983:
--

 Summary: CacheBinaryAutoStoreExample get wrong result
 Key: IGNITE-3983
 URL: https://issues.apache.org/jira/browse/IGNITE-3983
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
 Environment: Ubuntu 14.04, Win7, Apache Ignite 1.7.2
Reporter: Vasilisa  Sidorova
Priority: Critical


-
DESCRIPTION
-
CacheBinaryAutoStoreExample get wrong result
-
STEPS FOR REPRODUCE
-
# Build examples project
# Start H2 database TCP server using
# Start a few nodes using ExampleNodeStartup (it's stable reproducible with 
different numbers of nodes)
-
ACTUAL RESULT
-
{noformat}
>>> Populate database with data...

>>> Cache auto store example started...
>>> Read value: null
>>> Overwrote old value: null
>>> Read value: Person [id=25121642, orgId=1, lastName=Newton, firstName=Isaac, 
>>> salary=100.1, resume=English physicist and mathematician]
>>> Update salary in transaction...
>>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
>>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
>>> --
>>> Load data to cache from DB with custom SQL...
>>> Loaded cache entries: 3
>>> Load ALL data to cache from DB...
>>> Loaded cache entries: 0
{noformat}
-
EXPECTED RESULT
-
{noformat}
>>> Populate database with data...

>>> Cache auto store example started...
>>> Read value: null
>>> Overwrote old value: null
>>> Read value: Person [id=25121642, orgId=1, lastName=Newton, firstName=Isaac, 
>>> salary=100.1, resume=English physicist and mathematician]
>>> Update salary in transaction...
>>> Read value after commit: Person [id=25121642, orgId=1, lastName=Newton, 
>>> firstName=Isaac, salary=200.2, resume=English physicist and mathematician]
>>> --
>>> Load data to cache from DB with custom SQL...
>>> Loaded cache entries: 3
>>> Load ALL data to cache from DB...
>>> Loaded cache entries: 7
{noformat}
-
ADDITIONAL INFO
-
Isn't reproducible for previous versions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

2016-09-27 Thread Igor Sapego (JIRA)

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

Igor Sapego edited comment on IGNITE-3982 at 9/27/16 4:12 PM:
--

Done.
* Edited connection string page: 
https://apacheignite.readme.io/v1.8/docs/connecting-string
* Edited conformance page: https://apacheignite.readme.io/v1.8/docs/conformance



was (Author: isapego):
Done.
*Edited connection string page: 
https://apacheignite.readme.io/v1.8/docs/connecting-string
*Edited conformance page: https://apacheignite.readme.io/v1.8/docs/conformance


> ODBC: Add documentation for added connection string attributes and features.
> 
>
> Key: IGNITE-3982
> URL: https://issues.apache.org/jira/browse/IGNITE-3982
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
>  Labels: odbc
> Fix For: 1.8
>
>
> Add documentation for the following connection string attributes:
> * ADDRESS
> * DSN
> * PROTOCOL_VERSION
> * PAGE_SIZE
> Add documentation for the following features:
> * Data-at-execution dialog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3961) IGFS: Support direct PROXY mode invocation in method: affinity

2016-09-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov commented on IGNITE-3961:
--

Merged.

> IGFS: Support direct PROXY mode invocation in method: affinity
> --
>
> Key: IGNITE-3961
> URL: https://issues.apache.org/jira/browse/IGNITE-3961
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 1.8
>
>
> See 
> {{org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.getFileBlockLocations}}
>  for reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

2016-09-27 Thread Igor Sapego (JIRA)

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

Igor Sapego updated IGNITE-3982:

Labels: odbc  (was: )

> ODBC: Add documentation for added connection string attributes and features.
> 
>
> Key: IGNITE-3982
> URL: https://issues.apache.org/jira/browse/IGNITE-3982
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

2016-09-27 Thread Igor Sapego (JIRA)

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

Igor Sapego updated IGNITE-3982:

Description: 
Add documentation for the following connection string attributes:
* ADDRESS
* DSN
* PROTOCOL_VERSION
* PAGE_SIZE

Add documentation for the following features:
* Data-at-execution dialog.



> ODBC: Add documentation for added connection string attributes and features.
> 
>
> Key: IGNITE-3982
> URL: https://issues.apache.org/jira/browse/IGNITE-3982
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 1.8
>
>
> Add documentation for the following connection string attributes:
> * ADDRESS
> * DSN
> * PROTOCOL_VERSION
> * PAGE_SIZE
> Add documentation for the following features:
> * Data-at-execution dialog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

2016-09-27 Thread Igor Sapego (JIRA)

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

Igor Sapego updated IGNITE-3982:

Fix Version/s: 1.8

> ODBC: Add documentation for added connection string attributes and features.
> 
>
> Key: IGNITE-3982
> URL: https://issues.apache.org/jira/browse/IGNITE-3982
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

2016-09-27 Thread Igor Sapego (JIRA)

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

Igor Sapego updated IGNITE-3982:

Affects Version/s: 1.7

> ODBC: Add documentation for added connection string attributes and features.
> 
>
> Key: IGNITE-3982
> URL: https://issues.apache.org/jira/browse/IGNITE-3982
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

2016-09-27 Thread Igor Sapego (JIRA)

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

Igor Sapego reassigned IGNITE-3982:
---

Assignee: Igor Sapego

> ODBC: Add documentation for added connection string attributes and features.
> 
>
> Key: IGNITE-3982
> URL: https://issues.apache.org/jira/browse/IGNITE-3982
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3982) ODBC: Add documentation for added connection string attributes and features.

2016-09-27 Thread Igor Sapego (JIRA)
Igor Sapego created IGNITE-3982:
---

 Summary: ODBC: Add documentation for added connection string 
attributes and features.
 Key: IGNITE-3982
 URL: https://issues.apache.org/jira/browse/IGNITE-3982
 Project: Ignite
  Issue Type: Task
  Components: odbc
Reporter: Igor Sapego






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3868) ODBC: DSN support for Windows works incorrectly

2016-09-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-3868:


GitHub user isapego opened a pull request:

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

IGNITE-3868: Fix for Tableau connect using DSN.



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

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

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

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


commit b2f92954cc5adc3f35f2478e521b8c613035b4ee
Author: isapego 
Date:   2016-09-27T15:12:09Z

IGNITE-3868: Fix for Tableau connect using DSN.




> ODBC: DSN support for Windows works incorrectly
> ---
>
> Key: IGNITE-3868
> URL: https://issues.apache.org/jira/browse/IGNITE-3868
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.7
> Environment: Win 8, Apache Ignite 1.6.7
>Reporter: Vasilisa  Sidorova
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 1.8
>
>
> -
> DESCRIPTION
> -
> Some keys aren't registered in the registry during odbc driver installation 
> and during DSN user data source adding:
> HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup
> HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite 
> DSN\{port,protocol_version}
> -
> STEPS FOR REPRODUCE
> -
> # Build and install odbc driver according to instruction from product binaries
> # Go to Control Panel\System and Security\Administrative Tools\ODBC Data 
> Source Administrator (or run "odbcad32" command)
> # Try to add Apache Ignite DSN source
> -
> ACTUAL RESULT
> -
> Error message appear. Source isn't adding. There isn't 
> HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup key in the 
> registry
> -
> EXPECTED RESULT
> -
> Source is installed without any exception
> -
> NEXT STEPS FOR REPRODUCE
> -
> # Add HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache 
> Ignite\Setup=[path_to_ignite_odbc_driver] into registry
> # Add Apache Ignite DSN source in the ODBC Data Source Administrator
> # Start some cache
> # Run Tableau
> # Try to connect to the cache using DSN
> -
> ACTUAL RESULT
> -
> Connection error message appears. There aren't 
> HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite 
> DSN\{port,protocol_version} keys in the registry
> -
> EXPECTED RESULT
> -
> Connection is successful
> -
> ADDITIONAL INFO
> -
> Keys HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite 
> DSN\{port,protocol_version} are registered in the registry after user run 
> "Configure" command (without any changes) for Apache Ignite DSN source



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3280) .NET: Log4net integration

2016-09-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-3280:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3280 .NET: Log4net integration



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

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

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

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


commit f1540e352feee9ec9580b63c5815c9bb6becb97a
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:07:35Z

Add log4net project

commit 5ecbdeb08e1bb5974153b344ce54aed0b9c9534e
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:08:40Z

Fix sln

commit cdf0bbedfbaddd3230c3b5ce1555275a93af0cc7
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:23:45Z

wip tests

commit 38b9047eb67a8c4461fdc1ae7163d893738bc5a9
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:31:54Z

Add log4net NuGet dependency

commit 1ac175c12027ccbcf8e0c6cacbaca9971815df8f
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:38:52Z

Fix csproj version

commit a70b529c93c631d4a578b2069c772efff227d481
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:41:17Z

wip

commit fd64e97ee425188e4b6288d7c5da96553e7de2c8
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:45:11Z

log level conversion

commit d05a65e9a20d60f4a557f36ee34efa545f67ac33
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:45:35Z

wip rename

commit 919731358df50c22ab8ec2c46e4f3402e6486254
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:45:52Z

Fix letter case in file name

commit b7a2f179477213364194e7145e26913a2f534762
Author: Pavel Tupitsyn 
Date:   2016-09-27T10:58:02Z

Logger implemented

commit 77260828a8802b704df41431f3b6568f52c9eda5
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:04:33Z

wip tests

commit bfd9c5a0c74076967d1a43767b6bc89066618d28
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:05:56Z

wip

commit b7b914bd61c50197af993b0e68eca7409c709487
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:07:31Z

wip

commit c6f884b1abbe56fa34831ab3e098691d8066f2c4
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:07:59Z

wip

commit 41c2a2ae723802f664d9c5821848b95684963ff1
Author: Pavel Tupitsyn 
Date:   2016-09-27T12:08:56Z

Sign the assembly

commit c76c09a6c35daa581964e1508f20e5587cde7e26
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:13:38Z

TestLogLevelConversion done

commit a4cdc58cb98cfcd5e9e6db30789e24c3a1e6955f
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:19:21Z

wip

commit 222dca2433bd7240eb161424bf4d83bca574f584
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:31:59Z

wip

commit 6f48519a0aba3025f0487bc2565dd273fc4d8468
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:41:02Z

wip

commit cc895d02c70b395e9cc3a08b5f7fbe9ab922f503
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:51:31Z

wip

commit 611f956aa981aea708d4f81276fb193fc32132bb
Author: Pavel Tupitsyn 
Date:   2016-09-27T13:57:12Z

logger done

commit 798f3dc8e75389380c8d6ed00090d5313236f790
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:00:17Z

wip

commit b7d28dfa7dd042856155d1b864a044db26cb7b43
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:02:39Z

wip tests

commit f3f88bd2ec39109547ea6541c50277a9fad9f4ed
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:04:59Z

wip

commit e7552e2480065270aa22d89dac2da1c7ce46e41d
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:10:49Z

Tests done

commit c9ec04ed668d11a955b66771de39d1f9c166e2a6
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:31:22Z

Tests fixed

commit f7f4c2b8b319cd3d258aba1e72c4dff26e17f9e4
Author: Pavel Tupitsyn 
Date:   2016-09-27T14:40:47Z

Add nuspec

commit 0e40da8a88aa223c77ae5c355c51bc7760484395
Author: Pavel Tupitsyn 
Date:   2016-09-27T15:05:21Z

wip

commit 404fbc77555aa1c7a117aa621ae5f3b29d0a7d08
Author: Pavel Tupitsyn 
Date:   2016-09-27T15:06:35Z

wip

commit d672ab03f90493c1510092af5444b13d78292c58
Author: Pavel Tupitsyn 
Date:   2016-09-27T15:10:34Z

fix 

[jira] [Assigned] (IGNITE-3956) .NET: NuGet examples for LinqPad failed for specific scenario

2016-09-27 Thread Vasilisa Sidorova (JIRA)

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

Vasilisa  Sidorova reassigned IGNITE-3956:
--

Assignee: Vasilisa  Sidorova

> .NET: NuGet examples for LinqPad failed for specific scenario
> -
>
> Key: IGNITE-3956
> URL: https://issues.apache.org/jira/browse/IGNITE-3956
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.6
> Environment: Win7, Apache Ignite 1.6.8, LINQPad 4
>Reporter: Vasilisa  Sidorova
>Assignee: Vasilisa  Sidorova
>Priority: Minor
>  Labels: .net
> Fix For: 1.8
>
> Attachments: LINQPad 4_exampleError.png
>
>
> -
> DESCRIPTION
> -
> Nuget examples for LinqPad fail if they are running one-by-one with pure Java 
> node. Proposal: remove "CreateCache" method by "GetOrCreateCache" and/or get 
> different names to caches from different examples
> -
> STEPS FOR REPRODUCE
> -
> # In the  default-config.xml  add properties dor class 
> org.apache.ignite.configuration.IgniteConfiguration:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>class="org.apache.ignite.binary.BinaryBasicNameMapper">
>   
>   
>   
>   
>  
> {noformat}
> # Run pure Java node (ignite.bat)
> # Run LinqPad 4
> # Add  Apache.Ignite package
> # Go to  "Samples" Tab -> run all examples from nuget -> Apache.Ignite and 
> nuget -> Apache.Ignite.Linq
> -
> ACTUAL RESULT
> -
> Query and PutGet examples fail with "Failed to start cache" exception. Look 
> at the attached picture 
> -
> EXPECTED RESULT
> -
> Examples can be runnable on the one pure Java node many times without any 
> exceptions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-2079) GridCacheIoManager eats exception trail if it falls into the directed case

2016-09-27 Thread Dmitriy Govorukhin (JIRA)

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

Dmitriy Govorukhin reassigned IGNITE-2079:
--

Assignee: Dmitriy Govorukhin  (was: Andrey Velichko)

> GridCacheIoManager eats exception trail if it falls into the directed case
> --
>
> Key: IGNITE-2079
> URL: https://issues.apache.org/jira/browse/IGNITE-2079
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Govorukhin
>  Labels: ignite-3424
> Fix For: 1.8
>
> Attachments: IgniteCacheP2pUnmarshallingContinuousQueryErrorTest.java
>
>
> During a recent test I have run into an issue where a storage disabled client 
> of a Fabric that has services deployed for which the client does not have the 
> fabric in the class path failed with the following exception:
> com.company.fabric.HelloWorldTest STANDARD_ERROR
> Nov 08, 2015 6:15:20 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to process message 
> [senderId=30775397-457a-400f-a6c9-077c9e762d61, messageType=class 
> o.a.i.i.processors.cache.query.GridCacheQueryResponse]
> class org.apache.ignite.IgniteCheckedException: Failed to send response to 
> node. Unsupported direct type [message=GridCacheQueryResponse [finished=true, 
> reqId=5, err=null, fields=false, metadata=null]]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:546)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:272)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:77)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1078)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
>  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)
> This unfortunately gives me 0 information to work on to resolve the issue, as 
> the original unmarshalling exception (from the JdkMarshaller) was eaten as 
> this is the code for the default process failed message:
> default:
> throw new IgniteCheckedException("Failed to send response to node. 
> Unsupported direct type [message="
> + msg + "]");
> }
> you should also include the original stack from msg.getError() in the newly 
> thrown IgniteCheckedException



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3807) IgniteSpiContext registers message listeners incorrectly

2016-09-27 Thread Saikat Maitra (JIRA)

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

Saikat Maitra commented on IGNITE-3807:
---

[~vkulichenko]

Thank you Valentin.

Regards
Saikat

> IgniteSpiContext registers message listeners incorrectly
> 
>
> Key: IGNITE-3807
> URL: https://issues.apache.org/jira/browse/IGNITE-3807
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
> Fix For: 1.8
>
>
> {{IgniteSpiContext}} implementation provided by {{GridManagerAdapter}} uses 
> {{ctx.io().addMessageListener(..)}} method to register message listeners. 
> This is incorrect, because this creates a listener for internal Ignite 
> messages, not for user messages. Thus, when user tries to send a message on 
> this topic, the listener is not invoked. To fix this, 
> {{ctx.io().addUserMessageListener(..)}} method should be used instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-3965) @GridInternal tasks should not go through user load balancing SPI

2016-09-27 Thread Semen Boikov (JIRA)

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

Semen Boikov reassigned IGNITE-3965:


Assignee: Alexey Kuznetsov  (was: Semen Boikov)

Reviewed, looks good to merge.

Thanks!

> @GridInternal tasks should not go through user load balancing SPI
> -
>
> Key: IGNITE-3965
> URL: https://issues.apache.org/jira/browse/IGNITE-3965
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 1.8
>
>
> User can specify some custom load balancing SPI, but internal task should use 
> default load balancing SPI with predictable behaviour. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3981) GridTestProperties should be test instance member.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3981:
---

 Summary: GridTestProperties should be test instance member.
 Key: IGNITE-3981
 URL: https://issues.apache.org/jira/browse/IGNITE-3981
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3645) IGFS: Local secondary: Implement update() operation.

2016-09-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov commented on IGNITE-3645:
--

[Tests 
results|http://195.239.208.174/project.html?projectId=IgniteTests=projectOverview_IgniteTests=pull%2F1003%2Fhead]
 with lazy read of properties

> IGFS: Local secondary: Implement update() operation.
> 
>
> Key: IGNITE-3645
> URL: https://issues.apache.org/jira/browse/IGNITE-3645
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3980) Process failing Binary Object Queries tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3980:
---

 Summary: Process failing Binary Object Queries tests.
 Key: IGNITE-3980
 URL: https://issues.apache.org/jira/browse/IGNITE-3980
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (IGNITE-3978) Process failing AWS tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov closed IGNITE-3978.
---

> Process failing AWS tests.
> --
>
> Key: IGNITE-3978
> URL: https://issues.apache.org/jira/browse/IGNITE-3978
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3873) ODBC: Create installer for the ODBC.

2016-09-27 Thread Igor Sapego (JIRA)

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

Igor Sapego commented on IGNITE-3873:
-

Ready.

> ODBC: Create installer for the ODBC.
> 
>
> Key: IGNITE-3873
> URL: https://issues.apache.org/jira/browse/IGNITE-3873
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
>  Labels: odbc
> Fix For: 1.8
>
>
> It would be nice to have .msi installer for our ODBC driver, so that user 
> would not have a need to compile and install driver manually.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3873) ODBC: Create installer for the ODBC.

2016-09-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-3873:


GitHub user isapego opened a pull request:

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

IGNITE-3873: Added configs for WiX to generate ODBC installers.



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

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

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

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


commit 8d66eadcfa7b84fa871654d406d18e8b8cc01617
Author: isapego 
Date:   2016-09-23T18:04:33Z

IGNITE-3873: First version of the x86 install config.

commit 98cb20f3fbc4a2433c043f2e3ac477a245d23152
Author: isapego 
Date:   2016-09-23T18:12:11Z

IGNITE-3873: Renamed.

commit e2b910e177be4b25b4860293c78186cff56c1cb7
Author: isapego 
Date:   2016-09-23T18:29:59Z

IGNITE-3873: Added 64-bit installer.

commit 398e8a1ba4a6d59e040bfd3cff5d0e865fb3205c
Author: isapego 
Date:   2016-09-26T18:03:15Z

IGNITE-3873: Added to version update.

commit 7910a4984d24c98103fe2b350494d433bc921e2c
Author: isapego 
Date:   2016-09-27T12:59:07Z

IGNITE-3873: Readme edited.




> ODBC: Create installer for the ODBC.
> 
>
> Key: IGNITE-3873
> URL: https://issues.apache.org/jira/browse/IGNITE-3873
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
>
> It would be nice to have .msi installer for our ODBC driver, so that user 
> would not have a need to compile and install driver manually.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3978) Process failing AWS tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-3978:
-

PR #1123.

> Process failing AWS tests.
> --
>
> Key: IGNITE-3978
> URL: https://issues.apache.org/jira/browse/IGNITE-3978
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3979) .NET: Reorganize test suites

2016-09-27 Thread Pavel Tupitsyn (JIRA)
Pavel Tupitsyn created IGNITE-3979:
--

 Summary: .NET: Reorganize test suites
 Key: IGNITE-3979
 URL: https://issues.apache.org/jira/browse/IGNITE-3979
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 1.8


Considerations:
* Ignite.NET has core module and a bunch of optional modules (LINQ, ASP.NET, 
NLog, log4net, EntityFramework)
* Good design is to have a separate test project per module
* TeamCity spends considerable amount of time just to build sources (Java build 
takes 4 minutes)

Therefore, we should have separate test modules, but combine some of them on 
TeamCity.

For example, all optional modules can be combined into one TeamCity suite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (IGNITE-3973) Nodes can form separate clusters with TcpDiscoveryMulticastIpFinder

2016-09-27 Thread Semen Boikov (JIRA)

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

Semen Boikov resolved IGNITE-3973.
--
Resolution: Fixed
  Assignee: (was: Semen Boikov)

Changed TcpDiscoveryMulticastIpFinder.requestAddresses to do not stop when 
first remote address is received.

Better fix is send together with adress flag indicating whether node already 
joined topology, requestAddresses can stop when address from joined node is 
received. But this breaks binary compatibility.

> Nodes can form separate clusters with TcpDiscoveryMulticastIpFinder
> ---
>
> Key: IGNITE-3973
> URL: https://issues.apache.org/jira/browse/IGNITE-3973
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Semen Boikov
>Priority: Critical
> Fix For: 1.8
>
>
> Currently TcpDiscoveryMulticastIpFinder on start sends mcast address request 
> and stops wait when at least one remote address is received.
> This scenario is possible:
> - 4 nodes start concurrently
> - node1 receive first address of node2, node2 from node1
> - node3 receive first address of node4, node4 from node3
> - node1/node2 and node3/node4 can form separate clusters



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3978) Process failing AWS tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3978:
---

 Summary: Process failing AWS tests.
 Key: IGNITE-3978
 URL: https://issues.apache.org/jira/browse/IGNITE-3978
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3976) Process failing SPI tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3976:
---

 Summary: Process failing SPI tests.
 Key: IGNITE-3976
 URL: https://issues.apache.org/jira/browse/IGNITE-3976
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3977) Process failing OSGI tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3977:
---

 Summary: Process failing OSGI tests.
 Key: IGNITE-3977
 URL: https://issues.apache.org/jira/browse/IGNITE-3977
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3975) Process failing Streamers tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3975:

Summary: Process failing Streamers tests.  (was: Process failing streamer 
tests.)

> Process failing Streamers tests.
> 
>
> Key: IGNITE-3975
> URL: https://issues.apache.org/jira/browse/IGNITE-3975
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Priority: Minor
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3974) Process failing ZooKeeper tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3974:
---

 Summary: Process failing ZooKeeper tests.
 Key: IGNITE-3974
 URL: https://issues.apache.org/jira/browse/IGNITE-3974
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3975) Process failing streamer tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3975:
---

 Summary: Process failing streamer tests.
 Key: IGNITE-3975
 URL: https://issues.apache.org/jira/browse/IGNITE-3975
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Priority: Minor
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (IGNITE-3661) Process failing web sessions tests.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov closed IGNITE-3661.
---

> Process failing web sessions tests.
> ---
>
> Key: IGNITE-3661
> URL: https://issues.apache.org/jira/browse/IGNITE-3661
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general, websession
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3973) Nodes can form separate clusters with TcpDiscoveryMulticastIpFinder

2016-09-27 Thread Semen Boikov (JIRA)
Semen Boikov created IGNITE-3973:


 Summary: Nodes can form separate clusters with 
TcpDiscoveryMulticastIpFinder
 Key: IGNITE-3973
 URL: https://issues.apache.org/jira/browse/IGNITE-3973
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.7
Reporter: Semen Boikov
Assignee: Semen Boikov
Priority: Critical
 Fix For: 1.8


Currently TcpDiscoveryMulticastIpFinder on start sends mcast address request 
and stops wait when at least one remote address is received.
This scenario is possible:
- 4 nodes start concurrently
- node1 receive first address of node2, node2 from node1
- node3 receive first address of node4, node4 from node3
- node1/node2 and node3/node4 can form separate clusters



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3235) Failed to initialize primitive boolean cache property of superclass

2016-09-27 Thread Semen Boikov (JIRA)

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

Semen Boikov commented on IGNITE-3235:
--

Reviewedm looks good to me. Anton, please merge.

> Failed to initialize primitive boolean cache property of superclass
> ---
>
> Key: IGNITE-3235
> URL: https://issues.apache.org/jira/browse/IGNITE-3235
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Sergey Lemekhov
>Assignee: Anton Vinogradov
>Priority: Minor
> Fix For: 1.8
>
>
> When a superclass of a cache class contains a primitive boolean field marked 
> with {{@QuerySqlField}} annotation the cache initialization fails with an 
> exception:
> {{org.apache.ignite.IgniteCheckedException: Failed to initialize property 
> '' for key class '' and value class 'value class'. 
> Make sure that one of these classes contains respective getter method or 
> field.}}
> For example:
> {code}
> public class Base {
>@QuerySqlField
> private boolean flag;
> public boolean isFlag() {
> return flag;
> }
> public void setFlag(boolean flag) {
> this.flag = flag;
> }
> }
> public class Derived extends Base {
> private String field;
> public String getField() {
> return field;
> }
> public void setField(String field) {
> this.field = field;
> }
> }
> {code}
> This related to method 
> {{org.apache.ignite.internal.processors.query.GridQueryProcessor#buildClassProperty(boolean,
>  java.lang.Class, java.lang.String, java.lang.Class, 
> java.util.Map, 
> org.apache.ignite.internal.processors.cache.CacheObjectContext)}}.
> Method expects that all fields accessors start with "get" but for primitive 
> boolean fields usually the "is" prefix is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (IGNITE-3235) Failed to initialize primitive boolean cache property of superclass

2016-09-27 Thread Semen Boikov (JIRA)

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

Semen Boikov edited comment on IGNITE-3235 at 9/27/16 11:35 AM:


Reviewed, looks good to me. Anton, please merge.


was (Author: sboikov):
Reviewedm looks good to me. Anton, please merge.

> Failed to initialize primitive boolean cache property of superclass
> ---
>
> Key: IGNITE-3235
> URL: https://issues.apache.org/jira/browse/IGNITE-3235
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Sergey Lemekhov
>Assignee: Anton Vinogradov
>Priority: Minor
> Fix For: 1.8
>
>
> When a superclass of a cache class contains a primitive boolean field marked 
> with {{@QuerySqlField}} annotation the cache initialization fails with an 
> exception:
> {{org.apache.ignite.IgniteCheckedException: Failed to initialize property 
> '' for key class '' and value class 'value class'. 
> Make sure that one of these classes contains respective getter method or 
> field.}}
> For example:
> {code}
> public class Base {
>@QuerySqlField
> private boolean flag;
> public boolean isFlag() {
> return flag;
> }
> public void setFlag(boolean flag) {
> this.flag = flag;
> }
> }
> public class Derived extends Base {
> private String field;
> public String getField() {
> return field;
> }
> public void setField(String field) {
> this.field = field;
> }
> }
> {code}
> This related to method 
> {{org.apache.ignite.internal.processors.query.GridQueryProcessor#buildClassProperty(boolean,
>  java.lang.Class, java.lang.String, java.lang.Class, 
> java.util.Map, 
> org.apache.ignite.internal.processors.cache.CacheObjectContext)}}.
> Method expects that all fields accessors start with "get" but for primitive 
> boolean fields usually the "is" prefix is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (IGNITE-3639) IGFS: Local secondary: investigate whether we need BufferedOutputStream for create/append.

2016-09-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov edited comment on IGNITE-3639 at 9/27/16 11:25 AM:


Simple benchmark results:
||with BufferedOutputStream (base) || without BufferedOutputStream (changes) ||
|Write 6091 +/- 199
Read 297 +/- 9
Delete 1957 +/- 86 | Write 6201 +/- 242
Read 324 +/- 27
Delete 2103 +/- 44 |

Looks like the similar results.


was (Author: tledkov-gridgain):
Simple benchmark results:
||with BufferedOutputStream || without BufferedOutputStream ||
|Write 6091 +/- 199
Read 297 +/- 9
Delete 1957 +/- 86 | Write 6201 +/- 242
Read 324 +/- 27
Delete 2103 +/- 44 |

Looks like the similar results.

> IGFS: Local secondary: investigate whether we need BufferedOutputStream for 
> create/append.
> --
>
> Key: IGNITE-3639
> URL: https://issues.apache.org/jira/browse/IGNITE-3639
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 1.8
>
>
> We already have a buffer inside {{IgfsOutputStreamImpl}}. Do we really need 
> to wrap {{FileOutputStream}} into another buffer?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3639) IGFS: Local secondary: investigate whether we need BufferedOutputStream for create/append.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-3639:
-

Looks like there is no improvement, is it?

> IGFS: Local secondary: investigate whether we need BufferedOutputStream for 
> create/append.
> --
>
> Key: IGNITE-3639
> URL: https://issues.apache.org/jira/browse/IGNITE-3639
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 1.8
>
>
> We already have a buffer inside {{IgfsOutputStreamImpl}}. Do we really need 
> to wrap {{FileOutputStream}} into another buffer?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (IGNITE-3632) IGFS: Use task execution for PARTITIONED cache when metadata is co-located and current node is not affinity node.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov closed IGNITE-3632.
---

> IGFS: Use task execution for PARTITIONED cache when metadata is co-located 
> and current node is not affinity node.
> -
>
> Key: IGNITE-3632
> URL: https://issues.apache.org/jira/browse/IGNITE-3632
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 1.8
>
> Attachments: IGNITE_3632.patch
>
>
> If the following conditions are valid:
> 1) Metadata cache is PARTITIONED
> 2) Metadata co-location is enabled
> 3) Current node is not primary node
> Then we should use client task execution because this situation is 
> indistinguishable from running IGFS method on a client node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-3632) IGFS: Use task execution for PARTITIONED cache when metadata is co-located and current node is not affinity node.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov updated IGNITE-3632:

Attachment: IGNITE_3632.patch

> IGFS: Use task execution for PARTITIONED cache when metadata is co-located 
> and current node is not affinity node.
> -
>
> Key: IGNITE-3632
> URL: https://issues.apache.org/jira/browse/IGNITE-3632
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 1.8
>
> Attachments: IGNITE_3632.patch
>
>
> If the following conditions are valid:
> 1) Metadata cache is PARTITIONED
> 2) Metadata co-location is enabled
> 3) Current node is not primary node
> Then we should use client task execution because this situation is 
> indistinguishable from running IGFS method on a client node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3632) IGFS: Use task execution for PARTITIONED cache when metadata is co-located and current node is not affinity node.

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-3632:
-

Looks like changes doesn't give us any benefit. I will attach the patch and 
close the ticket.

> IGFS: Use task execution for PARTITIONED cache when metadata is co-located 
> and current node is not affinity node.
> -
>
> Key: IGNITE-3632
> URL: https://issues.apache.org/jira/browse/IGNITE-3632
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 1.8
>
>
> If the following conditions are valid:
> 1) Metadata cache is PARTITIONED
> 2) Metadata co-location is enabled
> 3) Current node is not primary node
> Then we should use client task execution because this situation is 
> indistinguishable from running IGFS method on a client node.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (IGNITE-3621) Make GridCacheTtlManager singleton

2016-09-27 Thread Semen Boikov (JIRA)

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

Semen Boikov reassigned IGNITE-3621:


Assignee: Semen Boikov  (was: Andrey Martianov)

> Make GridCacheTtlManager singleton
> --
>
> Key: IGNITE-3621
> URL: https://issues.apache.org/jira/browse/IGNITE-3621
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Eduard Shangareev
>Assignee: Semen Boikov
>  Labels: performance
>
> Now every cache has own TTL manager, which creates CleanupWorker = new extra 
> thread. This can cause to extra hundreds of threads (redundant context 
> switches = performance penalty).
> Also, under IGNITE-3513 every put can enter critical section to notify 
> worker. Obviously, it is not good from performance point of view.
> So, my proposal is next:
> 1. Expiration should be done on every cache action (on exit thread which 
> updates cache should invoke {{expire}}).
> 2. TtlManager will exist only in one instance.
> 3. CleanupWorker will be the only backup if there is no cache activity. It 
> will wake up with some period to check for work (500 ms, for example).
> Moreover, now we keep on-heap pending entries even if a cache is kept 
> off-head. At least, this issue needs discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-2662) .NET Standard support

2016-09-27 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn updated IGNITE-2662:
---
Description: 
Ignite.NET should target .NET Standard so it is available on maximum number of 
platforms, see
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

This will allow us to run on Windows, OSX, and Linux, and target .NET Core in 
additional to good old regular .NET.

Possible difficulties:
* JNI interop. Core has dllImport and it works on linux, and our C++ client 
works on linux, so it should be possible
* Reflection. We use it a lot, and API has changed.

  was:
.NET core is next gen open-source cross-platform implementation of .NET: 
https://github.com/dotnet/core

Since Ignite mostly does not use any platform-specific .NET features, it may be 
possible to add Core support.

Benefits:
* ASP.NET Core (ver 5) https://www.asp.net/vnext
* OSX & Linux

Possible difficulties:
* JNI interop. Core has dllImport and it works on linux, and our C++ client 
works on linux, so it should be possible
* Reflection. We use it a lot, and API has changed.


> .NET Standard support
> -
>
> Key: IGNITE-2662
> URL: https://issues.apache.org/jira/browse/IGNITE-2662
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Ignite.NET should target .NET Standard so it is available on maximum number 
> of platforms, see
> https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
> This will allow us to run on Windows, OSX, and Linux, and target .NET Core in 
> additional to good old regular .NET.
> Possible difficulties:
> * JNI interop. Core has dllImport and it works on linux, and our C++ client 
> works on linux, so it should be possible
> * Reflection. We use it a lot, and API has changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (IGNITE-2662) .NET Standard support

2016-09-27 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn updated IGNITE-2662:
---
Summary: .NET Standard support  (was: .NET Core support)

> .NET Standard support
> -
>
> Key: IGNITE-2662
> URL: https://issues.apache.org/jira/browse/IGNITE-2662
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> .NET core is next gen open-source cross-platform implementation of .NET: 
> https://github.com/dotnet/core
> Since Ignite mostly does not use any platform-specific .NET features, it may 
> be possible to add Core support.
> Benefits:
> * ASP.NET Core (ver 5) https://www.asp.net/vnext
> * OSX & Linux
> Possible difficulties:
> * JNI interop. Core has dllImport and it works on linux, and our C++ client 
> works on linux, so it should be possible
> * Reflection. We use it a lot, and API has changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3972) Continuous query events could be lost on backup node when primary leaves.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3972:
---

 Summary: Continuous query events could be lost on backup node when 
primary leaves.
 Key: IGNITE-3972
 URL: https://issues.apache.org/jira/browse/IGNITE-3972
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Andrew Mashenkov
 Fix For: 1.8


Consider the following scenario:
1) One node in topology;
2) PARTITIONED cache with 1 backup;
3) Continuous query is set on the cache;

If another node joins the cluster, it will handle some updates. If it leaves 
the topology, the first node must flush it's own events from backup queue thus 
ensuring that no events are lost.

But this doesn't happen because 
{{GridContinuousProcessor.addBackupNotification}} method perform lookup only on 
remote infos map, while handler is local and hence located in local infos map.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3957) Swap space is not cleared when the cache is destroyed

2016-09-27 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on IGNITE-3957:


GitHub user amartianov opened a pull request:

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

IGNITE-3957: clear swap space when cache is destroyed



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

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

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

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


commit 6e101bda907d0f95bbfb5c9fa1361995fb7eb8bf
Author: Andrey Martianov 
Date:   2016-09-27T09:59:54Z

IGNITE-3957: clear swap space when cache is destroyed




> Swap space is not cleared when the cache is destroyed
> -
>
> Key: IGNITE-3957
> URL: https://issues.apache.org/jira/browse/IGNITE-3957
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Andrey Martianov
> Attachments: SwapTest.java
>
>
> Test attached.
> When the cache is destroyed, corresponding swap filed are not deleted. 
> However, they are deleted on node stop.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (IGNITE-3639) IGFS: Local secondary: investigate whether we need BufferedOutputStream for create/append.

2016-09-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov edited comment on IGNITE-3639 at 9/27/16 10:10 AM:


Simple benchmark results:
||with BufferedOutputStream || without BufferedOutputStream ||
|Write 6091 +/- 199
Read 297 +/- 9
Delete 1957 +/- 86 | Write 6201 +/- 242
Read 324 +/- 27
Delete 2103 +/- 44 |

Looks like the similar results.


was (Author: tledkov-gridgain):
Simple benchmark results:
||with BufferedOutputStream || without BufferedOutputStream ||
|Write 6091 +/- 199
Read 297 +/- 9
Delete 1957 +/- 86 | Write 6201 +/- 242
Read 324 +/- 27
Delete 2103 +/- 44 |

> IGFS: Local secondary: investigate whether we need BufferedOutputStream for 
> create/append.
> --
>
> Key: IGNITE-3639
> URL: https://issues.apache.org/jira/browse/IGNITE-3639
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 1.8
>
>
> We already have a buffer inside {{IgfsOutputStreamImpl}}. Do we really need 
> to wrap {{FileOutputStream}} into another buffer?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3639) IGFS: Local secondary: investigate whether we need BufferedOutputStream for create/append.

2016-09-27 Thread Taras Ledkov (JIRA)

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

Taras Ledkov commented on IGNITE-3639:
--

Simple benchmark results:
||with BufferedOutputStream || without BufferedOutputStream ||
|Write 6091 +/- 199
Read 297 +/- 9
Delete 1957 +/- 86 | Write 6201 +/- 242
Read 324 +/- 27
Delete 2103 +/- 44 |

> IGFS: Local secondary: investigate whether we need BufferedOutputStream for 
> create/append.
> --
>
> Key: IGNITE-3639
> URL: https://issues.apache.org/jira/browse/IGNITE-3639
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 1.8
>
>
> We already have a buffer inside {{IgfsOutputStreamImpl}}. Do we really need 
> to wrap {{FileOutputStream}} into another buffer?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3597) IgniteConfiguration.igniteWorkDir has no effect

2016-09-27 Thread Vladimir Ozerov (JIRA)

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

Vladimir Ozerov commented on IGNITE-3597:
-

Adopted implementation to current branch state (mainly Hadoop changes). 
PR: #1121.

> IgniteConfiguration.igniteWorkDir has no effect
> ---
>
> Key: IGNITE-3597
> URL: https://issues.apache.org/jira/browse/IGNITE-3597
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.8
>
>
> U.setWorkDirectory method ensures that work dir is set only once.
> If there are multiple nodes in a process, or a node is stopped and then 
> started, IgniteConfiguration.igniteWorkDir is ignored.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3971) Web console: Add links to documentaiton on section tooltips

2016-09-27 Thread Vasiliy Sisko (JIRA)
Vasiliy Sisko created IGNITE-3971:
-

 Summary: Web console: Add links to documentaiton on section 
tooltips
 Key: IGNITE-3971
 URL: https://issues.apache.org/jira/browse/IGNITE-3971
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.8
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (IGNITE-3970) .NET: Cyrillic 'C' letter in code

2016-09-27 Thread Pavel Tupitsyn (JIRA)

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

Pavel Tupitsyn resolved IGNITE-3970.

Resolution: Fixed
  Assignee: (was: Pavel Tupitsyn)

> .NET: Cyrillic 'C' letter in code
> -
>
> Key: IGNITE-3970
> URL: https://issues.apache.org/jira/browse/IGNITE-3970
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 1.8
>
>
> The following places have Cyrillic 'C' instead of English 'C' in code:
> * СlusterNodeFilterApplyCallbackDelegate
> * СlusterNodeFilterApply
> * Comments in ICompute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3970) .NET: Cyrillic 'C' letter in code

2016-09-27 Thread Pavel Tupitsyn (JIRA)
Pavel Tupitsyn created IGNITE-3970:
--

 Summary: .NET: Cyrillic 'C' letter in code
 Key: IGNITE-3970
 URL: https://issues.apache.org/jira/browse/IGNITE-3970
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.7
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.8


The following places have Cyrillic 'C' instead of English 'C' in code:

* СlusterNodeFilterApplyCallbackDelegate
* СlusterNodeFilterApply
* Comments in ICompute



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3965) @GridInternal tasks should not go through user load balancing SPI

2016-09-27 Thread Semen Boikov (JIRA)

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

Semen Boikov commented on IGNITE-3965:
--

Hi,

I still see some issues:
- in GridJobProcessor it is not correct to use 'internal()' method to create 
session, correct way is use 'req.isInternal()'
- in GridTaskProcessor you call 'dep.internalTask', but at this line 'dep' can 
be null, you need move session creation after 'dep' is checked for null
- also since you initialize 'internal' flag for session we can use this value 
in GridTaskWorker:493 instead of calling 'dep.internalTask' one more time

Thanks

> @GridInternal tasks should not go through user load balancing SPI
> -
>
> Key: IGNITE-3965
> URL: https://issues.apache.org/jira/browse/IGNITE-3965
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Semen Boikov
> Fix For: 1.8
>
>
> User can specify some custom load balancing SPI, but internal task should use 
> default load balancing SPI with predictable behaviour. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (IGNITE-3969) Hadoop: Add installation instructions for MapR to readme.io.

2016-09-27 Thread Vladimir Ozerov (JIRA)
Vladimir Ozerov created IGNITE-3969:
---

 Summary: Hadoop: Add installation instructions for MapR to 
readme.io.
 Key: IGNITE-3969
 URL: https://issues.apache.org/jira/browse/IGNITE-3969
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.8






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (IGNITE-3968) Failed test VisorOpenCommandSpec

2016-09-27 Thread Vasiliy Sisko (JIRA)

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

Vasiliy Sisko commented on IGNITE-3968:
---

Tesl look outdated after changes in VisorOpenCommand class.

> Failed test VisorOpenCommandSpec
> 
>
> Key: IGNITE-3968
> URL: https://issues.apache.org/jira/browse/IGNITE-3968
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>
> ScalaTestFailureLocation: 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2
>  at (VisorOpenCommandSpec.scala:33)
> org.scalatest.exceptions.TestFailedException: Expected exception 
> org.apache.ignite.IgniteException to be thrown, but no exception was thrown.
>   at 
> org.scalatest.Assertions$class.newAssertionFailedException(Assertions.scala:495)
>   at org.scalatest.FunSpec.newAssertionFailedException(FunSpec.scala:1626)
>   at org.scalatest.Assertions$class.intercept(Assertions.scala:1014)
>   at org.scalatest.FunSpec.intercept(FunSpec.scala:1626)
>   at 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2.apply$mcV$sp(VisorOpenCommandSpec.scala:33)
>   at 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2.apply(VisorOpenCommandSpec.scala:33)
>   at 
> org.apache.ignite.visor.commands.open.VisorOpenCommandSpec$$anonfun$1$$anonfun$apply$mcV$sp$2.apply(VisorOpenCommandSpec.scala:33)
>   at 
> org.scalatest.Transformer$$anonfun$apply$1.apply$mcV$sp(Transformer.scala:22)
>   at org.scalatest.OutcomeOf$class.outcomeOf(OutcomeOf.scala:85)
>   at org.scalatest.OutcomeOf$.outcomeOf(OutcomeOf.scala:104)
>   at org.scalatest.Transformer.apply(Transformer.scala:22)
>   at org.scalatest.Transformer.apply(Transformer.scala:20)
>   at org.scalatest.FunSpecLike$$anon$1.apply(FunSpecLike.scala:422)
>   at org.scalatest.Suite$class.withFixture(Suite.scala:1122)
>   at org.scalatest.FunSpec.withFixture(FunSpec.scala:1626)
>   at 
> org.scalatest.FunSpecLike$class.invokeWithFixture$1(FunSpecLike.scala:419)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTest$1.apply(FunSpecLike.scala:431)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTest$1.apply(FunSpecLike.scala:431)
>   at org.scalatest.SuperEngine.runTestImpl(Engine.scala:306)
>   at org.scalatest.FunSpecLike$class.runTest(FunSpecLike.scala:431)
>   at 
> org.apache.ignite.visor.VisorRuntimeBaseSpec.org$scalatest$BeforeAndAfterEach$$super$runTest(VisorRuntimeBaseSpec.scala:29)
>   at 
> org.scalatest.BeforeAndAfterEach$class.runTest(BeforeAndAfterEach.scala:255)
>   at 
> org.apache.ignite.visor.VisorRuntimeBaseSpec.runTest(VisorRuntimeBaseSpec.scala:29)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTests$1.apply(FunSpecLike.scala:464)
>   at 
> org.scalatest.FunSpecLike$$anonfun$runTests$1.apply(FunSpecLike.scala:464)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:413)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:401)
>   at scala.collection.immutable.List.foreach(List.scala:381)
>   at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
>   at 
> org.scalatest.SuperEngine.org$scalatest$SuperEngine$$runTestsInBranch(Engine.scala:390)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:427)
>   at 
> org.scalatest.SuperEngine$$anonfun$traverseSubNodes$1$1.apply(Engine.scala:401)
>   at scala.collection.immutable.List.foreach(List.scala:381)
>   at org.scalatest.SuperEngine.traverseSubNodes$1(Engine.scala:401)
>   at 
> org.scalatest.SuperEngine.org$scalatest$SuperEngine$$runTestsInBranch(Engine.scala:396)
>   at org.scalatest.SuperEngine.runTestsImpl(Engine.scala:483)
>   at org.scalatest.FunSpecLike$class.runTests(FunSpecLike.scala:464)
>   at org.scalatest.FunSpec.runTests(FunSpec.scala:1626)
>   at org.scalatest.Suite$class.run(Suite.scala:1424)
>   at 
> org.scalatest.FunSpec.org$scalatest$FunSpecLike$$super$run(FunSpec.scala:1626)
>   at org.scalatest.FunSpecLike$$anonfun$run$1.apply(FunSpecLike.scala:468)
>   at org.scalatest.FunSpecLike$$anonfun$run$1.apply(FunSpecLike.scala:468)
>   at org.scalatest.SuperEngine.runImpl(Engine.scala:545)
>   at org.scalatest.FunSpecLike$class.run(FunSpecLike.scala:468)
>   at 
> org.apache.ignite.visor.VisorRuntimeBaseSpec.org$scalatest$BeforeAndAfterAll$$super$run(VisorRuntimeBaseSpec.scala:29)
>   at 
> org.scalatest.BeforeAndAfterAll$class.liftedTree1$1(BeforeAndAfterAll.scala:257)
>   at 
> 

[jira] [Commented] (IGNITE-3958) Client node should not start rest processor

2016-09-27 Thread Valentin Kulichenko (JIRA)

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

Valentin Kulichenko commented on IGNITE-3958:
-

Also a good point. Actually, I don't think it's a very common use case and a 
regular user would expect that REST will connect to server nodes. Having said 
that, ideally REST should be disabled on clients by default with an option to 
enable it. But this is an incompatible change, so probably it's better to do it 
in 2.0.

[~yzhdanov], can you chime in?

> Client node should not start rest processor
> ---
>
> Key: IGNITE-3958
> URL: https://issues.apache.org/jira/browse/IGNITE-3958
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yakov Zhdanov
> Fix For: 1.8
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)