[jira] [Comment Edited] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-4531 at 1/10/17 8:21 PM:
--

Fixed; patch: https://github.com/apache/ignite/pull/1419; TC tests are on the 
run.
This affected not just UPDATE, but actually all operations. Suggested fix 
should help with them all.


was (Author: al.psc):
Fixed; patch: https://github.com/apache/ignite/pull/1419; TC tests are on the 
run.

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Assignee: Alexander Paschenko
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Commented] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4531:
-

Fixed; patch: https://github.com/apache/ignite/pull/1419; TC tests are on the 
run.

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Assignee: Alexander Paschenko
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Assigned] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-4531:
---

Assignee: Alexander Paschenko

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Assignee: Alexander Paschenko
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Commented] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4531:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-4531 Use correct property name in BinaryProperty.



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

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

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

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


commit e930dfa54112a5374ac4acd6c6ac88510fa9d3e9
Author: Alexander Paschenko 
Date:   2017-01-10T20:12:58Z

IGNITE-4531 Use correct property name in BinaryProperty.




> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Commented] (IGNITE-4530) Passing AWSCredentialsProvider to TcpDiscoveryS3IpFinder

[Aliaksandr Kazlou (JIRA)]

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

Aliaksandr Kazlou commented on IGNITE-4530:
---

Hi, [~dmagda] I will take a look and address them tomorrow. I also think have 
to put `testIpFinder` in every of the test class (I think the one from the 
abstract parent will not be picked, see below). Also I have not tested it yet, 
expected there to be some CI which will fail if there is an issue. Will then 
test it manually as well, and after will move into "patch available" state if 
everything works and comments addressed.

> Passing AWSCredentialsProvider to TcpDiscoveryS3IpFinder
> 
>
> Key: IGNITE-4530
> URL: https://issues.apache.org/jira/browse/IGNITE-4530
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Aliaksandr Kazlou
>
> {{TcpDiscoveryS3IpFinder}} accepts credentials in a form of 
> {{AWSCredentials}} only. This might not be enough for all the cases. In a 
> situation when the credentials get expired a special instance of 
> {{AWSCredentialsProvider}} can renew them automatically.
> However, the credentials will not be updated if {{StaticCredentialsProvider}} 
> is used. This provider is created automatically if user provides raw 
> {{AWSCredentials}}.
> We need to add new method to {{TcpDiscoveryS3IpFinder}} that will accept 
> {{AWSCredentialsProvider}}:
> {code}
> public void setAwsCredentialsProvider(AWSCredentialsProvider provider) {
> {code}
> A new test has to be added to {{TcpDiscoveryS3IpFinderSelfTest}} as well.
> For more details refer to a discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Old-AWS-SDK-version-why-td9824.html



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

[jira] [Updated] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4523:

Fix Version/s: (was: 2.0)
   1.9

> Allow distributed SQL query execution over explicit set of partitions
> -
>
> Key: IGNITE-4523
> URL: https://issues.apache.org/jira/browse/IGNITE-4523
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL
>Affects Versions: 1.8
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.9
>
>
> Currently distributed SQL query is executed on all nodes containing primary 
> partitions for a cache, sending map query requests on all nodes in grid.
> Sometimes we know in advance which partitions hold a data for query, on 
> example, in case of custom affinity function. 
> Therefore it's possible to reduce number of nodes receiving map query request 
> by providing explicit set of partitions, which will give significant 
> performance advantage and traffic reduction in case of very large clusters.
> Internally we already have such functionality, so the only necessary thing is 
> to provide public API for what.



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

[jira] [Updated] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4106:

Fix Version/s: (was: 2.0)
   1.9

> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: performance, sql
> Fix For: 1.9
>
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



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

[jira] [Updated] (IGNITE-4517) Add ability to execute SQL queries on certain partition(s)

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4517:

Fix Version/s: (was: 2.0)
   1.9

> Add ability to execute SQL queries on certain partition(s)
> --
>
> Key: IGNITE-4517
> URL: https://issues.apache.org/jira/browse/IGNITE-4517
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Reporter: Vladimir Ozerov
> Fix For: 1.9
>
>
> *Motivation*
> This could be useful for certain cases:
> 1) Simple queries where partition can be determined easily in advance, either 
> automatically (IGNITE-4509, IGNITE-4510), or manually.
> 2) Spark data frame integration (IGNITE-3084)
> *Proposed API*
> class Query {
> int[] partitions();
> void partitions(int...);
> }
> Important points:
> 1) Partitions are defined in the very base {{Query}} class because we already 
> has this feature for {{ScanQuery}} and potentially any query type can benefit 
> from it. If query doesn't support partitions, exception should be thrown.
> 2) User should be able to specify multiple partitions, not only one. This 
> will make our API more flexible for 3-rd party integrations like Spark. Also 
> it will help users with fine-grained tuning. E.g. if user has a query {{... 
> WHERE attribute IN (?, ?, ...)}}, he can determine partitions for {{IN}} 
> arguments in advance.
> Probably this feature should not be supported for distributed joins. On the 
> other hand - why not? Query is always created from some cache, so the first 
> map step can be executed only against target partitions, and the rest 
> execution flow can go through all partitions of other caches.



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

[jira] [Commented] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-4523:
---

Almost ready for TC.

Have to add a test with distributed join.

PR: https://github.com/apache/ignite/pull/1418

Please review API changes please while I'm finishing the test.

I'm followed [~vozerov]'s API proposal, just added support for efficient 
partition range assignment.

This is handy in case we split partitions in ranges and assign independent data 
set to each range, which is described in details in IGNITE-4378.



> Allow distributed SQL query execution over explicit set of partitions
> -
>
> Key: IGNITE-4523
> URL: https://issues.apache.org/jira/browse/IGNITE-4523
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL
>Affects Versions: 1.8
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.9
>
>
> Currently distributed SQL query is executed on all nodes containing primary 
> partitions for a cache, sending map query requests on all nodes in grid.
> Sometimes we know in advance which partitions hold a data for query, on 
> example, in case of custom affinity function. 
> Therefore it's possible to reduce number of nodes receiving map query request 
> by providing explicit set of partitions, which will give significant 
> performance advantage and traffic reduction in case of very large clusters.
> Internally we already have such functionality, so the only necessary thing is 
> to provide public API for what.



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

[jira] [Commented] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-4523:
---

BTW, I think the best data structure for represeting partition set is a 
compressed bitmap. Why don't we have the implementation in Ignite? It may be 
useful in other curcumstances.

> Allow distributed SQL query execution over explicit set of partitions
> -
>
> Key: IGNITE-4523
> URL: https://issues.apache.org/jira/browse/IGNITE-4523
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL
>Affects Versions: 1.8
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 1.9
>
>
> Currently distributed SQL query is executed on all nodes containing primary 
> partitions for a cache, sending map query requests on all nodes in grid.
> Sometimes we know in advance which partitions hold a data for query, on 
> example, in case of custom affinity function. 
> Therefore it's possible to reduce number of nodes receiving map query request 
> by providing explicit set of partitions, which will give significant 
> performance advantage and traffic reduction in case of very large clusters.
> Internally we already have such functionality, so the only necessary thing is 
> to provide public API for what.



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

[jira] [Created] (IGNITE-4538) BinaryObjectImpl: lack of context information upon deserialization

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-4538:
--

 Summary: BinaryObjectImpl: lack of context information upon 
deserialization
 Key: IGNITE-4538
 URL: https://issues.apache.org/jira/browse/IGNITE-4538
 Project: Ignite
  Issue Type: Improvement
  Components: binary
Affects Versions: 1.8, 1.7
Reporter: Alexandr Kuramshin


Taking an error we don't know the cache name was accessed, the type of 
BinaryClassDescriptor was used, and the entry was accessed (the key of an entry 
should be logged with respect to the *include sensitive* system property).

Such context information should be appended by wrapping inner exception on the 
every key stack frame.

{noformat}
org.apache.ignite.binary.BinaryObjectException: Unexpected flag value [pos=24, 
expected=4, actual=9]
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.checkFlagNoHandles(BinaryReaderExImpl.java:1423)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readLongNullable(BinaryReaderExImpl.java:723)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:677)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:818)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1481)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:717)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:272)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:160)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:147)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1706)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.advance(GridCacheQueryManager.java:2875)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.(GridCacheQueryManager.java:2814)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.(GridCacheQueryManager.java:2752)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$5.(GridCacheQueryManager.java:863)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.scanIterator(GridCacheQueryManager.java:863)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.scanQueryLocal(GridCacheQueryManager.java:1436)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:552)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4115)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4092)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.iterator(IgniteCacheProxy.java:1979)
 ~[ignite-core-1.10.1.ea7.jar:1.10.1.ea7]
{noformat}



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

[jira] [Created] (IGNITE-4539) RocketMQ data streamer

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-4539:


 Summary: RocketMQ data streamer
 Key: IGNITE-4539
 URL: https://issues.apache.org/jira/browse/IGNITE-4539
 Project: Ignite
  Issue Type: New Feature
  Components: streaming
Reporter: Roman Shtykh
Assignee: Roman Shtykh


Streamer for RocketMQ (https://github.com/rocketmq)



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

[jira] [Updated] (IGNITE-4537) Update Notifier must not transfer system properties

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4537:

Assignee: Denis Magda

> Update Notifier must not transfer system properties
> ---
>
> Key: IGNITE-4537
> URL: https://issues.apache.org/jira/browse/IGNITE-4537
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 1.9
>
>
> Apache Ignite Update Notifier that is used for sending updates about new 
> Apache Ignite versions gathers and transfers all system properties.
> The script must not do this. Instead, it has to get only those system 
> properties like Java version, OS versions that are needed. Otherwise, the 
> script might send sensitive information like passwords stored in the system 
> properties.



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

[jira] [Commented] (IGNITE-4493) ODBC: Add missing diagnostic records in case of API errors

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4493:


Looks good to me, merged to master.

> ODBC: Add missing diagnostic records in case of API errors
> --
>
> Key: IGNITE-4493
> URL: https://issues.apache.org/jira/browse/IGNITE-4493
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
>Assignee: Pavel Tupitsyn
> Fix For: 2.0
>
>
> The following functions in Ignite ODBC driver do not strictly follow the API 
> documentation with regard to diagnostics. It should be possible to obtain 
> additional information about errors via SQLGetDiagRec() call.
> SQLAllocHandle
> SQLFreeHandle
> SQLFreeStmt
> SQLBindCol
> SQLFetchScroll
> SQLBindParameter



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

[jira] [Commented] (IGNITE-4493) ODBC: Add missing diagnostic records in case of API errors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4493:


Github user asfgit closed the pull request at:

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


> ODBC: Add missing diagnostic records in case of API errors
> --
>
> Key: IGNITE-4493
> URL: https://issues.apache.org/jira/browse/IGNITE-4493
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
> Fix For: 2.0
>
>
> The following functions in Ignite ODBC driver do not strictly follow the API 
> documentation with regard to diagnostics. It should be possible to obtain 
> additional information about errors via SQLGetDiagRec() call.
> SQLAllocHandle
> SQLFreeHandle
> SQLFreeStmt
> SQLBindCol
> SQLFetchScroll
> SQLBindParameter



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

[jira] [Updated] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-4374:
---
Attachment: x32_optimized.png
x32_not_optimized.png

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png, 
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Commented] (IGNITE-4523) Allow distributed SQL query execution over explicit set of partitions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4523:
-

IGNITE-4510 is a bit different beast - I meant that in some cases our SQL 
engine can determine partitions automatically, e.g. when there is a simple 
{{WHERE}} condition on affinity column. Probably you meant IGNITE-4517 where I 
propose to have an API to set target partitions by hand.

> Allow distributed SQL query execution over explicit set of partitions
> -
>
> Key: IGNITE-4523
> URL: https://issues.apache.org/jira/browse/IGNITE-4523
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, SQL
>Affects Versions: 1.8
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.0
>
>
> Currently distributed SQL query is executed on all nodes containing primary 
> partitions for a cache, sending map query requests on all nodes in grid.
> Sometimes we know in advance which partitions hold a data for query, on 
> example, in case of custom affinity function. 
> Therefore it's possible to reduce number of nodes receiving map query request 
> by providing explicit set of partitions, which will give significant 
> performance advantage and traffic reduction in case of very large clusters.
> Internally we already have such functionality, so the only necessary thing is 
> to provide public API for what.



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

[jira] [Comment Edited] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur edited comment on IGNITE-4374 at 1/10/17 8:03 AM:
-

[^x64_not_optimized.png]
[^x64_optimized.png]
[^x32_not_optimized.png]
[^x32_optimized.png]
'-server' option checks only on not x64 VM
bq. On a 64-bit capable JDK, only the Java Hotspot Server VM is supported so 
the -server option is implicit
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html


was (Author: daradurvs):
x64 - not optimized
[^x64_not_optimized.png]

x64 - optimized
!x64_optimized.png|thumbnail!

x32 - not optimized
!x32_not_optimized.png|thumbnail!

x32 - optimized
!x32_optimized.png|thumbnail!

'-server' option checks only on not x64 VM
bq. On a 64-bit capable JDK, only the Java Hotspot Server VM is supported so 
the -server option is implicit
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: check-output.png, x32_not_optimazed.png, 
> x32_optimazed.png, x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Updated] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-4374:
---
Attachment: (was: x32_not_optimazed.png)

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Updated] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-4374:
---
Attachment: (was: x32_optimazed.png)

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Updated] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-4374:
---
Attachment: (was: check-output.png)

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Assigned] (IGNITE-4470) ODBC: Add support for logger configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4470:
--

Assignee: Sergey Kalashnikov  (was: Pavel Tupitsyn)

> ODBC: Add support for logger configuration
> --
>
> Key: IGNITE-4470
> URL: https://issues.apache.org/jira/browse/IGNITE-4470
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.0
>
>
> Users of ODBC driver should be able to configure logging without driver 
> recompilation.
> Logger should be setup via environment variable.



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

[jira] [Commented] (IGNITE-4470) ODBC: Add support for logger configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4470:


Please merge from master and resolve conflicts.

> ODBC: Add support for logger configuration
> --
>
> Key: IGNITE-4470
> URL: https://issues.apache.org/jira/browse/IGNITE-4470
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
>Assignee: Pavel Tupitsyn
> Fix For: 2.0
>
>
> Users of ODBC driver should be able to configure logging without driver 
> recompilation.
> Logger should be setup via environment variable.



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

[jira] [Updated] (IGNITE-4302) Exchange binary metadata with discovery custom messages instead of system cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-4302:

Summary: Exchange binary metadata with discovery custom messages instead of 
system cache  (was: Use discovery custom messages instead of system cache)

> Exchange binary metadata with discovery custom messages instead of system 
> cache
> ---
>
> Key: IGNITE-4302
> URL: https://issues.apache.org/jira/browse/IGNITE-4302
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> h4. Notes
> See [IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] for more 
> details about context.
> h4. Acceptance Criteria
> # Binary metadata cache is deleted.
> # Binary metadata exchange is performed using *DiscoveryCustomMessage* events.



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

[jira] [Created] (IGNITE-4537) Update Notifier must not transfer system properties

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4537:
---

 Summary: Update Notifier must not transfer system properties
 Key: IGNITE-4537
 URL: https://issues.apache.org/jira/browse/IGNITE-4537
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Priority: Critical
 Fix For: 1.9


Apache Ignite Update Notifier that is used for sending updates about new Apache 
Ignite versions gathers and transfers all system properties.

The script must not do this. Instead, it has to get only those system 
properties like Java version, OS versions that are needed. Otherwise, the 
script might send sensitive information like passwords stored in the system 
properties.





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

[jira] [Updated] (IGNITE-4425) .NET: Support "Array.Contains" in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4425:
---
Description: 
SQL supports IN queries and, as a better alternative, temporary table join, as 
described in the docs:
https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations

Example SQL:
{code}
new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i on 
p.OrgId = i.id", new object[] { new object[] {1,3}})
{code}

Add support in LINQ like this:

{code}
persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.OrgId))
{code}


  was:
SQL supports IN queries and, as a better alternative, temporary table join, as 
described in the docs:
https://apacheignite.readme.io/docs/performance-and-debugging#performance-and-usability-considerations

Example SQL:
{code}
new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i on 
p.OrgId = i.id", new object[] { new object[] {1,3}})
{code}

Add support in LINQ like this:

{code}
persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.OrgId))
{code}



> .NET: Support "Array.Contains" in LINQ
> --
>
> Key: IGNITE-4425
> URL: https://issues.apache.org/jira/browse/IGNITE-4425
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET, LINQ
> Fix For: 2.0
>
>
> SQL supports IN queries and, as a better alternative, temporary table join, 
> as described in the docs:
> https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations
> Example SQL:
> {code}
> new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i 
> on p.OrgId = i.id", new object[] { new object[] {1,3}})
> {code}
> Add support in LINQ like this:
> {code}
> persons.AsCacheQueryable().Where(x => new[] {1,3}.Contains(x.Value.OrgId))
> {code}



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

[jira] [Closed] (IGNITE-4488) ODBC: First query execution takes much more time than any subsequent

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-4488.
---

> ODBC: First query execution takes much more time than any subsequent
> 
>
> Key: IGNITE-4488
> URL: https://issues.apache.org/jira/browse/IGNITE-4488
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc, platforms
>Affects Versions: 1.8
>Reporter: Igor Sapego
> Fix For: 2.0
>
>
> When we perform SQL query on small dataset just to measure latency, the very 
> first call takes much more time to execute than the same subsequent requests 
> (~70ms vs ~10ms).
> The same behavior can be observed with C++ client.



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

[jira] [Resolved] (IGNITE-3904) Add an option to serialize specific type(s) with OptimizedMarshaller when binary format is used

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko resolved IGNITE-3904.
-
Resolution: Won't Fix
  Assignee: (was: Amelchev Nikita)

Not needed anymore.

> Add an option to serialize specific type(s) with OptimizedMarshaller when 
> binary format is used
> ---
>
> Key: IGNITE-3904
> URL: https://issues.apache.org/jira/browse/IGNITE-3904
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 2.0
>
>
> Currently binary marshaller delegates to optimized marshaller for 
> {{Externalizable}} classes and classes that have {{write/readObject}} 
> methods. It can be useful to manually force this behavior for other classes 
> as well.
> We can add {{BinaryTypeConfiguration.useOptimizedMarshaller}} property for 
> this.



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

[jira] [Closed] (IGNITE-3758) ODBC: Add tests for SQL_SQL92_DATETIME_FUNCTIONS.

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-3758.
---

> ODBC: Add tests for SQL_SQL92_DATETIME_FUNCTIONS.
> -
>
> Key: IGNITE-3758
> URL: https://issues.apache.org/jira/browse/IGNITE-3758
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Minor
> Fix For: 2.0
>
>
> Let's add tests for SQL_SQL92_DATETIME_FUNCTIONS [1]
> Affected functions:
> SQL_SDF_CURRENT_DATE
> SQL_SDF_CURRENT_TIME
> SQL_SDF_CURRENT_TIMESTAMP
> [1] https://msdn.microsoft.com/en-us/library/ms711681(v=vs.85).aspx#Anchor_16



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

[jira] [Commented] (IGNITE-3885) .NET: Describe development process on Wiki

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3885:


Page created: 
https://cwiki.apache.org/confluence/display/IGNITE/Ignite.NET+Development
Link added to 
https://github.com/apache/ignite/tree/master/modules/platforms/dotnet

> .NET: Describe development process on Wiki
> --
>
> Key: IGNITE-3885
> URL: https://issues.apache.org/jira/browse/IGNITE-3885
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.0
>
>
> Ignite wiki: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Home
> Add .NET development process page:
> * Coding guidelines (naming conventions, etc)
> * Project structure
> * Code inspections, how to run locally and on TC
> * Test coverage
> * How to build (AnyCPU nuances, NuGet, embedded CPP part, Java, etc)



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

[jira] [Closed] (IGNITE-3904) Add an option to serialize specific type(s) with OptimizedMarshaller when binary format is used

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko closed IGNITE-3904.
---

> Add an option to serialize specific type(s) with OptimizedMarshaller when 
> binary format is used
> ---
>
> Key: IGNITE-3904
> URL: https://issues.apache.org/jira/browse/IGNITE-3904
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 2.0
>
>
> Currently binary marshaller delegates to optimized marshaller for 
> {{Externalizable}} classes and classes that have {{write/readObject}} 
> methods. It can be useful to manually force this behavior for other classes 
> as well.
> We can add {{BinaryTypeConfiguration.useOptimizedMarshaller}} property for 
> this.



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

[jira] [Commented] (IGNITE-4212) Ignite Benchmarking Simplification and Automation

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-4212:
--

I'm working on executable files to run benchmarks on aws. 

> Ignite Benchmarking Simplification and Automation
> -
>
> Key: IGNITE-4212
> URL: https://issues.apache.org/jira/browse/IGNITE-4212
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> There is a plenty of useful Yardstick benchmarks located in ignite-yardstick 
> module that is used by the community to check Ignite performance across 
> deployments of different configurations.
> However, it's not easy to start with the benchmarking process because the 
> user needs to download Ignite, build and set up benchmarks and only after 
> that run them.
> The goal of this task is to simplify the process in the following way:
> 1) ignite-yardstick benchmarks have to be pre-compiled and available with 
> every Ignite deliverable.
> 2) every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 3) the executable has to use some default yardstick configuration. The first 
> configuration should be intented for local execution (multicast IP finder) 
> and the second needs to be AWS oriented.



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

[jira] [Commented] (IGNITE-4367) .NET: Fix flaky tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4367:


Github user asfgit closed the pull request at:

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


> .NET: Fix flaky tests
> -
>
> Key: IGNITE-4367
> URL: https://issues.apache.org/jira/browse/IGNITE-4367
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET
> Fix For: 1.9
>
>
> TeamCity has detected a number of flaky tests in .NET: 
> http://ci.ignite.apache.org/project.html?projectId=IgniteTests=flakyTests=IgniteTests_IgnitePlatformNetCoverage



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

[jira] [Created] (IGNITE-4534) Implement offheap eviction policies based on page memory

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-4534:


 Summary: Implement offheap eviction policies based on page memory
 Key: IGNITE-4534
 URL: https://issues.apache.org/jira/browse/IGNITE-4534
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexey Goncharuk


Since the internal structure of offheap storage has changed, we need to 
re-implement Fifo, Lru and Sorted eviction policies



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

[jira] [Created] (IGNITE-4535) Add option to store deserialized values on-heap

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-4535:


 Summary: Add option to store deserialized values on-heap
 Key: IGNITE-4535
 URL: https://issues.apache.org/jira/browse/IGNITE-4535
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexey Goncharuk


Now cache data is always stored in offheap (pagememory). Need implement option 
to also store deserialised values in heap memory, this should be replacement 
for existing CacheConfiguration.memoryMode configuration.



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

[jira] [Created] (IGNITE-4536) Update metrics for new offheap storage

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-4536:


 Summary: Update metrics for new offheap storage
 Key: IGNITE-4536
 URL: https://issues.apache.org/jira/browse/IGNITE-4536
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexey Goncharuk


Since the new implementation of offheap storage and memory pools, we need to 
actualize existing cache metrics



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

[jira] [Comment Edited] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht edited comment on IGNITE-4531 at 1/10/17 10:15 AM:
--

Attached a test  file to reproduce the behaviour


was (Author: sawfish):
Test to reproduce the behaviour

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: IgniteOperationCacheTest.java

Test to reproduce the behaviour

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Comment Edited] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht edited comment on IGNITE-4531 at 1/10/17 10:15 AM:
--

Hi,

I am using -DIGNITE_H2_DEBUG_CONSOLE=true as debug console. 


was (Author: sawfish):
Hi,

I am using -DIGNITE_H2_DEBUG_CONSOLE=true as debug console. Currently I don't 
have a test.which reproduces the behaviour.

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Updated] (IGNITE-4532) .NET: Fix build warnings

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4532:
---
Description: 
There are ~70 warnings in VS 2015 after build.
Fix them and make sure thet build fails on warnings.

  was:There are ~70 warnings in VS 2015 after build.


> .NET: Fix build warnings
> 
>
> Key: IGNITE-4532
> URL: https://issues.apache.org/jira/browse/IGNITE-4532
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: newbie, platforms
> Fix For: 2.0
>
>
> There are ~70 warnings in VS 2015 after build.
> Fix them and make sure thet build fails on warnings.



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: (was: IgniteOperationCacheTest.java)

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Commented] (IGNITE-4489) Maintain correct MERGE semantic in DML

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4489:
-

Re-structured the code for better maintainability (split 
{{DmlStatementsProcessor}} that started getting huge into classes that 
encompass logic of INSERT, UPDATE, and MERGE); added a test. Started TC tests, 
after they pass will convert this to *patch available*.
I also suggest that we release fixes for this, as well as IGNITE-4363 and 
IGNITE-4490 in a single branch (corresponding to this issue) as long as this 
looks like a major improvement and and the same time depends on fixes from 
aforementioned branches. [~vozerov]

> Maintain correct MERGE semantic in DML
> --
>
> Key: IGNITE-4489
> URL: https://issues.apache.org/jira/browse/IGNITE-4489
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Currently it's impossible to MERGE object in UPDATE style - i.e. when key is 
> present in cache, unaffected field values should be retained, and instead of 
> building new object we should base it on previous one for given key.



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: (was: IgniteOperationCacheTest.java)

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: IgniteOperationCacheTest.java

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: IgniteOperationCacheTest.java

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: (was: IgniteOperationCacheTest.java)

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: IgniteOperationCacheTest.java

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Updated] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Attachment: IgniteOperationCacheTest.java

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
> Attachments: IgniteOperationCacheTest.java
>
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Resolved] (IGNITE-3667) IGFS: Local secondary: Ensure that user context is propagated properly to underlying FS operation.

[Taras Ledkov (JIRA)]

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

Taras Ledkov resolved IGNITE-3667.
--
Resolution: Won't Fix

> IGFS: Local secondary: Ensure that user context is propagated properly to 
> underlying FS operation.
> --
>
> Key: IGNITE-3667
> URL: https://issues.apache.org/jira/browse/IGNITE-3667
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> If operation was initiated by user X, then it should be processed on behalf 
> of this user, not on behalf of Ignite process owner. 
> See {{IgniteHadoopIgfsSecondaryFileSystem.fileSystemForUser()}} for reference.



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

[jira] [Commented] (IGNITE-3667) IGFS: Local secondary: Ensure that user context is propagated properly to underlying FS operation.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3667:
--

HDFS uses the user parameter only for java security with JAAS. Ignite doesn't 
work with java {{SecurityManager}}. So java security with {{ FilePermission}} 
is no applied for IGFS local secondary.

The operation with the native file systems are performed with process owner's 
permissions (not supported by java, not supported by Ignite). 
So hdfs doesn't set the default user for file operation.

Looks like the propagation of a user context is not necessary for IGFS local 
secondary.

> IGFS: Local secondary: Ensure that user context is propagated properly to 
> underlying FS operation.
> --
>
> Key: IGNITE-3667
> URL: https://issues.apache.org/jira/browse/IGNITE-3667
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> If operation was initiated by user X, then it should be processed on behalf 
> of this user, not on behalf of Ignite process owner. 
> See {{IgniteHadoopIgfsSecondaryFileSystem.fileSystemForUser()}} for reference.



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

[jira] [Comment Edited] (IGNITE-3667) IGFS: Local secondary: Ensure that user context is propagated properly to underlying FS operation.

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3667 at 1/10/17 10:23 AM:


HDFS uses the user parameter only for java security with JAAS. Ignite doesn't 
work with java {{SecurityManager}}. So java security with {{FilePermission}} is 
no applied for IGFS local secondary.

The operation with the native file systems are performed with process owner's 
permissions (not supported by java, not supported by Ignite). 
So hdfs doesn't set the default user for file operation.

Looks like the propagation of a user context is not necessary for IGFS local 
secondary.


was (Author: tledkov-gridgain):
HDFS uses the user parameter only for java security with JAAS. Ignite doesn't 
work with java {{SecurityManager}}. So java security with {{ FilePermission}} 
is no applied for IGFS local secondary.

The operation with the native file systems are performed with process owner's 
permissions (not supported by java, not supported by Ignite). 
So hdfs doesn't set the default user for file operation.

Looks like the propagation of a user context is not necessary for IGFS local 
secondary.

> IGFS: Local secondary: Ensure that user context is propagated properly to 
> underlying FS operation.
> --
>
> Key: IGNITE-3667
> URL: https://issues.apache.org/jira/browse/IGNITE-3667
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> If operation was initiated by user X, then it should be processed on behalf 
> of this user, not on behalf of Ignite process owner. 
> See {{IgniteHadoopIgfsSecondaryFileSystem.fileSystemForUser()}} for reference.



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

[jira] [Commented] (IGNITE-4532) .NET: Fix build warnings

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4532:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-4532 .NET: Fix build warnings



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

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

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

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


commit f110b62ea0d3eb18821d41ea9db9848db54f924e
Author: Pavel Tupitsyn 
Date:   2017-01-10T09:36:48Z

IGNITE-4532 .NET: Fix build warnings

commit 58acbbb347e9a3da9fa72f40579238955aac6fe3
Author: Pavel Tupitsyn 
Date:   2017-01-10T09:49:51Z

Suppress processor architecture mismatch warning in x64/x86 modes

commit d52cd0a98e4bc106c2d421fa8085da3cfa53404e
Author: Pavel Tupitsyn 
Date:   2017-01-10T09:59:50Z

Fix log4net project warnings

commit 7df8d34889c89a6d1dd17dfa4dc194f699eacf6c
Author: Pavel Tupitsyn 
Date:   2017-01-10T10:10:50Z

IGNITE-4532 .NET: Suppress CA1822 in test projects

commit f0348d88c91202406280e7ef6905efd4390fac1f
Author: Pavel Tupitsyn 
Date:   2017-01-10T10:12:29Z

wip

commit 6a925b04622997fcb8ac0fcc437a9ec25dec9171
Author: Pavel Tupitsyn 
Date:   2017-01-10T10:15:33Z

Fixing warnings

commit 82677a2d39acb8cb98e7195e014d83b931029a9d
Author: Pavel Tupitsyn 
Date:   2017-01-10T10:17:11Z

wip

commit c3bfcd6f2189258a43f52ea6e6bb7c0611d1b91a
Author: Pavel Tupitsyn 
Date:   2017-01-10T10:18:57Z

wip

commit 24d16e53912d93d62f37f4289234cb6067021828
Author: Pavel Tupitsyn 
Date:   2017-01-10T10:23:15Z

Treat warnings as errors in all projects

commit d111b1e0a6c46672ba6bcc3449c9f152a2ecf432
Author: Pavel Tupitsyn 
Date:   2017-01-10T10:29:21Z

Fix jni project reference in Core




> .NET: Fix build warnings
> 
>
> Key: IGNITE-4532
> URL: https://issues.apache.org/jira/browse/IGNITE-4532
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: newbie, platforms
> Fix For: 2.0
>
>
> There are ~70 warnings in VS 2015 after build.
> Fix them and make sure thet build fails on warnings.



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

[jira] [Issue Comment Deleted] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-4374:
---
Comment: was deleted

(was: [^x64_not_optimized.png]
[^x64_optimized.png]
[^x32_not_optimized.png]
[^x32_optimized.png]
'-server' option checks only on not x64 VM
bq. On a 64-bit capable JDK, only the Java Hotspot Server VM is supported so 
the -server option is implicit
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html)

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png, 
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Commented] (IGNITE-4374) Ignite should validate JVM and OS configuration and output warning in log

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-4374:


[^x64_not_optimized.png]
[^x64_optimized.png]
[^x32_not_optimized.png]
[^x32_optimized.png]
'-server' option checks only on not x64 VM
bq. On a 64-bit capable JDK, only the Java Hotspot Server VM is supported so 
the -server option is implicit
http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

> Ignite should validate JVM and OS configuration and output warning in log
> -
>
> Key: IGNITE-4374
> URL: https://issues.apache.org/jira/browse/IGNITE-4374
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Yakov Zhdanov
>Assignee: Vyacheslav Daradur
> Attachments: x32_not_optimized.png, x32_optimized.png, 
> x64_not_optimized.png, x64_optimized.png
>
>
> Currently we have GridPerformanceSuggestions that output suggestions to logs 
> on Ignite start on how Ignite can be improved.
> I suggest to go a little bit deeper and validate more configuration options 
> and add validation for JVM and OS settings.
> Ignite should output warning if:
> * GC logging is not enabled
> * MaxDirectMemorySize is not set (-XX:MaxDirectMemorySize)
> * Heap size is greater than 30,5G and JVM cannot use compressed oops
> * Any of the recommended OS setting described here 
> https://apacheignite.readme.io/docs/jvm-and-system-tuning are not properly 
> set 



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

[jira] [Created] (IGNITE-4533) GridDhtPartitionsExchangeFuture stores unnecessary messages after processing done

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-4533:
--

 Summary: GridDhtPartitionsExchangeFuture stores unnecessary 
messages after processing done
 Key: IGNITE-4533
 URL: https://issues.apache.org/jira/browse/IGNITE-4533
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8, 1.7
Reporter: Alexandr Kuramshin


After GridDhtPartitionsExchangeFuture has been completed, 
GridCachePartitionExchangeManager still stores it in field ExchangeFutureSet 
exchFuts (for race condition handling).

But many GridDhtPartitionsSingleMessage objects stored in field 
ConcurrentMap msgs is not needed after 
the future has been processed.

This map should be cleared in the end of the method onAllReceived().



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

[jira] [Updated] (IGNITE-3170) .NET: Add user-friendly ToString overrides for public types

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3170:
---
Labels: .net newbie  (was: .net)

> .NET: Add user-friendly ToString overrides for public types
> ---
>
> Key: IGNITE-3170
> URL: https://issues.apache.org/jira/browse/IGNITE-3170
> Project: Ignite
>  Issue Type: Improvement
>  Components: newbie, platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net, newbie
> Fix For: 2.0
>
>
> Events, cache entry events, mutable cache entries, etc, should have 
> {{ToString}} overridden. See {{CacheEntry}} for example.
> {{IgniteConfiguration}} (and inner property classes) can be displayed as XML.



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

[jira] [Commented] (IGNITE-3905) Optimize RendezvousAffinityFunction

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3905:
--

The results of optimization is available at the IGNITE-3018.

> Optimize RendezvousAffinityFunction
> ---
>
> Key: IGNITE-3905
> URL: https://issues.apache.org/jira/browse/IGNITE-3905
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, community, general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Priority: Critical
> Fix For: 2.0
>
>
> Currently RendezvousAffinityFunction.assignPartition generates a lot of 
> garbage if called very often, on example in case of rebalancing a lot of 
> caches.
> This causes excessive pressure on GC, which is not always fast enough to 
> clear memory, producing long GC pauses leading to node segmentation.
> We should cache calculation of nodeHashBytes in node attribute or resort to 
> more efficient node hash calculation.



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

[jira] [Updated] (IGNITE-1508) .NET: Create common ToString() method

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1508:
---
Labels: .net newbie  (was: .net)

> .NET: Create common ToString() method
> -
>
> Key: IGNITE-1508
> URL: https://issues.apache.org/jira/browse/IGNITE-1508
> Project: Ignite
>  Issue Type: Improvement
>  Components: newbie, platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net, newbie
>
> We have lots of places with the same code pattern in ToString() method: 
> culture info + String.Format(). 
> Let's move it to utilities and re-use just like it is done in Java.



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

[jira] [Commented] (IGNITE-3018) Cache affinity calculation is slow with large nodes number

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3018:
--

[Pull request|https://github.com/apache/ignite/pull/684]

> Cache affinity calculation is slow with large nodes number
> --
>
> Key: IGNITE-3018
> URL: https://issues.apache.org/jira/browse/IGNITE-3018
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
> Attachments: 003.png, 064.png, 100.png, 128.png, 200.png, 300.png, 
> 400.png, 500.png, 600.png
>
>
> With large number of cache server nodes (> 200)  RendezvousAffinityFunction 
> and FairAffinityFunction work pretty slow .
> For RendezvousAffinityFunction.assignPartitions can take hundredes of 
> milliseconds, for FairAffinityFunction it can take seconds.
> For RendezvousAffinityFunction most time is spent in MD5 hash calculation and 
> nodes list sorting. As optimization we can try to cache {partion, node} MD5 
> hash or try another hash function. Also several minor optimizations are 
> possible (avoid unncecessary allocations, only one thread local 'get', etc).



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

[jira] [Updated] (IGNITE-3207) Rename IgniteConfiguration.gridName

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-3207:
-
Labels: 1 important  (was: important)

> Rename IgniteConfiguration.gridName
> ---
>
> Key: IGNITE-3207
> URL: https://issues.apache.org/jira/browse/IGNITE-3207
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Fedotov
>  Labels: important
> Fix For: 2.0
>
>
> We have got a TON of questions on gridName property. Everyone thinks that 
> clusters are formed based on the gridName, that is, nodes with the same grid 
> name will join one cluster, and nodes with a different name will be in a 
> separate cluster.
> Let's do the following:
> * Deprecate IgniteConfiguration.gridName
> * Add IgniteConfiguration.localInstanceName
> * Rename related parameters in Ignition class (and other places, if present)
> * Update Javadoc: clearly state that this name only works locally and has no 
> effect on topology.



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

[jira] [Updated] (IGNITE-3207) Rename IgniteConfiguration.gridName

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-3207:
-
Labels: important  (was: 1 important)

> Rename IgniteConfiguration.gridName
> ---
>
> Key: IGNITE-3207
> URL: https://issues.apache.org/jira/browse/IGNITE-3207
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Fedotov
>  Labels: important
> Fix For: 2.0
>
>
> We have got a TON of questions on gridName property. Everyone thinks that 
> clusters are formed based on the gridName, that is, nodes with the same grid 
> name will join one cluster, and nodes with a different name will be in a 
> separate cluster.
> Let's do the following:
> * Deprecate IgniteConfiguration.gridName
> * Add IgniteConfiguration.localInstanceName
> * Rename related parameters in Ignition class (and other places, if present)
> * Update Javadoc: clearly state that this name only works locally and has no 
> effect on topology.



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

[jira] [Assigned] (IGNITE-3885) .NET: Describe development process on Wiki

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-3885:
--

Assignee: Pavel Tupitsyn

> .NET: Describe development process on Wiki
> --
>
> Key: IGNITE-3885
> URL: https://issues.apache.org/jira/browse/IGNITE-3885
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.0
>
>
> Ignite wiki: 
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Home
> Add .NET development process page:
> * Coding guidelines (naming conventions, etc)
> * Project structure
> * Code inspections, how to run locally and on TC
> * Test coverage
> * How to build (AnyCPU nuances, NuGet, embedded CPP part, Java, etc)



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

[jira] [Commented] (IGNITE-4531) Update DML operation not working for @QuerySqlField with name

[David Albrecht (JIRA)]

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

David Albrecht commented on IGNITE-4531:


Hi,

I am using -DIGNITE_H2_DEBUG_CONSOLE=true as debug console. Currently I don't 
have a test.which reproduces the behaviour.

> Update DML operation not working for @QuerySqlField with name
> -
>
> Key: IGNITE-4531
> URL: https://issues.apache.org/jira/browse/IGNITE-4531
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 1.8
>Reporter: David Albrecht
>Priority: Critical
>
> After putting a java class Operation with
> {code}
> @QuerySqlField(name = "operationNumber", index = true)
> private String mOperationNumber;
> @QuerySqlField(index = true)
> private String mUuid;
> {code}
> in the cache. Via debug console I can see the following fields:
> _val:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The query
> {code}
> String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
> mUuid =  ?";
> SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
> ).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
> cache.query(updateQuery);
> {code}
> results in:
> Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
> 0010, operationNumber=SCHEDULED, ...]
> and a column named: OPERATIONNUMBER with value 0010.
> The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



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

[jira] [Commented] (IGNITE-4470) ODBC: Add support for logger configuration

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-4470:


Pavel, I have resolved the conflicts.

> ODBC: Add support for logger configuration
> --
>
> Key: IGNITE-4470
> URL: https://issues.apache.org/jira/browse/IGNITE-4470
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.0
>
>
> Users of ODBC driver should be able to configure logging without driver 
> recompilation.
> Logger should be setup via environment variable.



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

[jira] [Updated] (IGNITE-4470) ODBC: Add support for logger configuration

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-4470:
---
Assignee: Pavel Tupitsyn  (was: Sergey Kalashnikov)

> ODBC: Add support for logger configuration
> --
>
> Key: IGNITE-4470
> URL: https://issues.apache.org/jira/browse/IGNITE-4470
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
>Assignee: Pavel Tupitsyn
> Fix For: 2.0
>
>
> Users of ODBC driver should be able to configure logging without driver 
> recompilation.
> Logger should be setup via environment variable.



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

[jira] [Commented] (IGNITE-4503) HadoopDirectDataInput must have boundary checks

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-4503:
-

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

> HadoopDirectDataInput must have boundary checks
> ---
>
> Key: IGNITE-4503
> URL: https://issues.apache.org/jira/browse/IGNITE-4503
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
> Fix For: 2.0
>
>
> Otherwise we may end up with JVM crash in case of invalid implementation of 
> key/value deserialization routine.



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

[jira] [Commented] (IGNITE-4470) ODBC: Add support for logger configuration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4470:


Looks good, merged to master.

> ODBC: Add support for logger configuration
> --
>
> Key: IGNITE-4470
> URL: https://issues.apache.org/jira/browse/IGNITE-4470
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
>Assignee: Pavel Tupitsyn
> Fix For: 2.0
>
>
> Users of ODBC driver should be able to configure logging without driver 
> recompilation.
> Logger should be setup via environment variable.



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

[jira] [Commented] (IGNITE-4470) ODBC: Add support for logger configuration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4470:


Github user asfgit closed the pull request at:

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


> ODBC: Add support for logger configuration
> --
>
> Key: IGNITE-4470
> URL: https://issues.apache.org/jira/browse/IGNITE-4470
> Project: Ignite
>  Issue Type: Improvement
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Sergey Kalashnikov
> Fix For: 2.0
>
>
> Users of ODBC driver should be able to configure logging without driver 
> recompilation.
> Logger should be setup via environment variable.



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

[jira] [Commented] (IGNITE-4532) .NET: Fix build warnings

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4532:


Github user ptupitsyn closed the pull request at:

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


> .NET: Fix build warnings
> 
>
> Key: IGNITE-4532
> URL: https://issues.apache.org/jira/browse/IGNITE-4532
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: newbie, platforms
> Fix For: 2.0
>
>
> There are ~70 warnings in VS 2015 after build.
> Fix them and make sure thet build fails on warnings.



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

[jira] [Closed] (IGNITE-4532) .NET: Fix build warnings

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn closed IGNITE-4532.
--

> .NET: Fix build warnings
> 
>
> Key: IGNITE-4532
> URL: https://issues.apache.org/jira/browse/IGNITE-4532
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: newbie, platforms
> Fix For: 2.0
>
>
> There are ~70 warnings in VS 2015 after build.
> Fix them and make sure thet build fails on warnings.



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

[jira] [Resolved] (IGNITE-4532) .NET: Fix build warnings

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4532.

Resolution: Fixed

Fixed in master

> .NET: Fix build warnings
> 
>
> Key: IGNITE-4532
> URL: https://issues.apache.org/jira/browse/IGNITE-4532
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: newbie, platforms
> Fix For: 2.0
>
>
> There are ~70 warnings in VS 2015 after build.
> Fix them and make sure thet build fails on warnings.



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

[jira] [Commented] (IGNITE-4487) NPE on query execution

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-4487:
-

Done, please look again.

> NPE on query execution
> --
>
> Key: IGNITE-4487
> URL: https://issues.apache.org/jira/browse/IGNITE-4487
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Dmitry Karachentsev
>Assignee: Alexander Menshikov
> Fix For: 1.8
>
> Attachments: IgniteThread.java, Main.java
>
>
> NPE may be thrown when called destroyCache() and started querying.
> Attached example reproduces this case when 
> GridDiscoveryManager#removeCacheFilter called but cache state haven't been 
> changed to STOPPED 
> org.apache.ignite.internal.processors.cache.GridCacheGateway#onStopped.
> {code:none}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
> null
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:740)
> at 
> com.intellica.evam.engine.event.future.FutureEventWorker.processFutureEvents(FutureEventWorker.java:117)
> at 
> com.intellica.evam.engine.event.future.FutureEventWorker.run(FutureEventWorker.java:66)
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1693)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:494)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:732)
> ... 2 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter$ScanQueryFallbackClosableIterator.init(GridCacheQueryAdapter.java:712)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter$ScanQueryFallbackClosableIterator.(GridCacheQueryAdapter.java:677)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter$ScanQueryFallbackClosableIterator.(GridCacheQueryAdapter.java:628)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:548)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy$2.applyx(IgniteCacheProxy.java:497)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy$2.applyx(IgniteCacheProxy.java:495)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1670)
> ... 4 more
> {code}



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

[jira] [Commented] (IGNITE-3400) IGFS: Does not correctly deallocate free space in courner case.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3400:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3400: add available size check before data blocks writing



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

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

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

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


commit 1d0da67942b2c0938c8bc1b720ab0fe4225d6dfd
Author: tledkov-gridgain 
Date:   2016-09-07T05:51:47Z

IGNITE-3400 IGFS: Does not correctly deallocate free space in courner case 
- add test

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

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

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

Merge branch 'master' into ignite-2.0

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

Merge branch 'master' into ignite-2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge branch 'master' into ignite-2.0

commit 0eb6c90bb4752f0a2a54cb332d69054c7587d24c
Author: tledkov-gridgain 
Date:   2017-01-10T11:28:42Z

Merge branch 'ignite-2.0' into ignite-3400

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/igfs/IgfsAbstractBaseSelfTest.java

commit e5d00443fbb7f384d93515c5f82c0a000b563ede
Author: tledkov-gridgain 
Date:   2017-01-10T13:26:24Z

IGNITE-3400: add check before block writing

commit 3b261ac85dc17fdea6cba0c2d3bfcc1c83262891
Author: tledkov-gridgain 
Date:   2017-01-10T14:05:04Z

IGNITE-3400: add check available size before writing blocks




> IGFS: Does not correctly deallocate free space in courner case.
> ---
>
> Key: IGNITE-3400
> URL: https://issues.apache.org/jira/browse/IGNITE-3400
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 2.0
>
>
> Steps to reproduce:
> 1) Run node with configured IGFS limited by max space (f.e. 104857600).
> 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb)
> 3) Copy to IGFS file with size more than free space size.
>   Second file have 0 size in IGFS. Used IGFS size approximately equal to the 
> IGFS space size.
> 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. 
> 10-15 Mb)
>   New file have 0 size.
> 5) Remove all files of format IGFS
>   IGFS free space approximately equal to the size of first file.



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

[jira] [Commented] (IGNITE-3400) IGFS: Does not correctly deallocate free space in courner case.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3400:
--

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

> IGFS: Does not correctly deallocate free space in courner case.
> ---
>
> Key: IGNITE-3400
> URL: https://issues.apache.org/jira/browse/IGNITE-3400
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Taras Ledkov
>Priority: Minor
> Fix For: 2.0
>
>
> Steps to reproduce:
> 1) Run node with configured IGFS limited by max space (f.e. 104857600).
> 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb)
> 3) Copy to IGFS file with size more than free space size.
>   Second file have 0 size in IGFS. Used IGFS size approximately equal to the 
> IGFS space size.
> 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. 
> 10-15 Mb)
>   New file have 0 size.
> 5) Remove all files of format IGFS
>   IGFS free space approximately equal to the size of first file.



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