[jira] [Updated] (IGNITE-4257) Web Console: Download project on Summary screen is broken under Safari browser

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-4257:
---
Assignee: Pavel Konstantinov  (was: Andrey Novikov)

> Web Console: Download project on Summary screen is broken under Safari browser
> --
>
> Key: IGNITE-4257
> URL: https://issues.apache.org/jira/browse/IGNITE-4257
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>




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

[jira] [Updated] (IGNITE-4348) Documentation: RDBMS Integration using Web Console

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4348:

Description: 
Ignite has a documentation which describes how to set up "automatic 
persistence" relying on the schema-import tool.
https://apacheignite-mix.readme.io/docs/automatic-persistence

Let's create a similar one but basing it on Web Console capabilities briefly 
listed on this page
https://ignite.apache.org/features/rdbmsintegration.html

The schema-import based document has to be removed after that.

  was:
Ignite has a documentation which describes how to set up "automatic 
persistence" relying on the schema-import tool.
https://apacheignite-mix.readme.io/docs/automatic-persistence

Let's create a similar one but basing it on Web Console capabilities briefly 
listed on this page
https://ignite.apache.org/features/rdbmsintegration.html


> Documentation: RDBMS Integration using Web Console
> --
>
> Key: IGNITE-4348
> URL: https://issues.apache.org/jira/browse/IGNITE-4348
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Prachi Garg
> Fix For: 1.9
>
>
> Ignite has a documentation which describes how to set up "automatic 
> persistence" relying on the schema-import tool.
> https://apacheignite-mix.readme.io/docs/automatic-persistence
> Let's create a similar one but basing it on Web Console capabilities briefly 
> listed on this page
> https://ignite.apache.org/features/rdbmsintegration.html
> The schema-import based document has to be removed after that.



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

[jira] [Created] (IGNITE-4349) Discontinue the schema-import utility

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4349:
---

 Summary: Discontinue the schema-import utility
 Key: IGNITE-4349
 URL: https://issues.apache.org/jira/browse/IGNITE-4349
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Alexey Kuznetsov
 Fix For: 2.0


Let's discontinue the maintenance of the schema-import utility in favor of Web 
Console that has the same capability.

The schema-import utility should be removed from sources once the following Web 
Console documentation is added 
https://issues.apache.org/jira/browse/IGNITE-4348



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

[jira] [Commented] (IGNITE-4346) DML and PHP PDO: double field is converted to bigdecimal

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4346:
-

Allora, signori, rilassatevi per favore: I'm sure this is fixed by IGNITE-4340. 
Igor, please try to reproduce everything described by Denis on branch 
ignite-4340 (prof. repo of course).

> DML and PHP PDO: double field is converted to bigdecimal
> 
>
> Key: IGNITE-4346
> URL: https://issues.apache.org/jira/browse/IGNITE-4346
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
> Fix For: 1.8
>
> Attachments: default-config.xml, dsn_configuration.png, insert.php, 
> update.php
>
>
> I've set up PHP PDO and ODBC environment according to the following 
> documentation
> https://apacheignite-mix.readme.io/docs/php-pdo
> In particular:
> - The ODBC driver was built from the latest 1.8 sources located in ignite-1.8 
> branch. 
> - The DSN configuration is shown in the attached screenshot name 
> "dsn_configuration"
> - Ignite's cluster configuration is attached as well.
> To reproduce the issue do the following:
> - start a node using attached default-config.xml
> - execute insert.php. There won't be any error.
> - execute update.php and you'll get the error with the stack trace below
> {code}
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> DML
>  statement [qry=UPDATE Person SET salary = 42000.0 WHERE salary > 5.0, 
> param
> s=[]]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1800)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryT
> woStep(GridQueryProcessor.java:810)
> ... 13 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException:
>  Failed to execute DML statement [qry=UPDATE Person SET salary = 42000.0 
> WHERE s
> alary > 5.0, params=[]]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.query
> TwoStep(IgniteH2Indexing.java:1270)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:812)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:810)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOu
> tClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1777)
> ... 14 more
> Caused by: class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicChecke
> dException: Failed to locally write to cache (all transaction entries will be 
> in
> validated, however there was a window when entries for this transaction were 
> vis
> ible to others): GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl 
> [mapping=G
> ridDistributedTxMapping [entries=[IgniteTxEntry [key=KeyCacheObjectImpl 
> [val=777
> , hasValBytes=false], cacheId=1215863053, partId=-1, txKey=IgniteTxKey 
> [key=KeyC
> acheObjectImpl [val=777, hasValBytes=false], cacheId=1215863053], 
> val=[op=TRANSF
> ORM, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryPr
> ocessorsCol=[IgniteBiTuple 
> [val1=org.apache.ignite.internal.processors.query.h2.
> DmlStatementsProcessor$ModifyingEntryProcessor@1f2f10da, 
> val2=[Ljava.lang.Object
> ;@2bfa5294]], ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null,
>  dhtVer=GridCacheVersion [topVer=92027384, time=1480547401695, 
> order=14805473813
> 93, nodeOrder=1], filters=[], filtersPassed=false, filtersSet=true, 
> entry=GridDh
> tColocatedCacheEntry [super=GridDhtCacheEntry [rdrs=[], 
> locPart=GridDhtLocalPart
> ition [id=777, 
> map=org.apache.ignite.internal.processors.cache.GridCacheConcurre
> ntMapImpl@24c94530, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=0], 
> cntr=1
> , shouldBeRenting=false, state=OWNING, reservations=0, empty=false, 
> createTime=1
> 1/30/2016 15:09:45], super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [k
> ey=KeyCacheObjectImpl [val=777, hasValBytes=false], val=Person 
> [idHash=659295625
> , hash=-322179972, resume=Secret Service agent, firstName=James, 
> lastName=Bond,
> salary=65000.0], startVer=1480547381389, ver=GridCacheVersion 
> [topVer=92027384,
> time=1480547394518, order=1480547381390, nodeOrder=1], hash=777, 
> extras=GridCach
> eMvccEntryExtras [mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate 
> [nodeId=08b20
> b4b-3ca6-4c05-aa9d-4219cbc3f3f5, ver=GridCacheVersion [topVer=92027384, 
> time=148
> 0547401693, order=1480547381392, nodeOrder=1], timeout=0, ts=1480547401693, 
> thre

[jira] [Created] (IGNITE-4348) Documentation: RDBMS Integration using Web Console

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4348:
---

 Summary: Documentation: RDBMS Integration using Web Console
 Key: IGNITE-4348
 URL: https://issues.apache.org/jira/browse/IGNITE-4348
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 1.9


Ignite has a documentation which describes how to set up "automatic 
persistence" relying on the schema-import tool.
https://apacheignite-mix.readme.io/docs/automatic-persistence

Let's create a similar one but basing it on Web Console capabilities briefly 
listed on this page
https://ignite.apache.org/features/rdbmsintegration.html



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

[jira] [Comment Edited] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-4018 at 12/1/16 12:35 AM:
---

[~al.psc], I've briefly looked over the current documentation [1] and have a 
minor note.

Instead of providing raw SQL code snippets like the one below

{code} 
merge into Person(_key, first_name, second_name) values
  (1, "John", "Smith"),
  (5, "Mary", "Jones")
{code}

please use our Java SQL API instead like it's done over there [2] for SELECT 
queries' code snippets.

In addition, as it mentioned in the ticket's description, please add a DML 
related section into JDBC documentation [3]. The section simply should include 
code snippets for UPDATE, INSERT and DELETE queries executed using a JDBC 
connection. A good example of how the section should look like is shown on a 
similar ODBC documentation page [4].

[1] https://apacheignite.readme.io/docs/distributed-dml#dml-operations
[2] https://apacheignite.readme.io/docs/sql-queries#cross-cache-queries
[3] https://apacheignite.readme.io/docs/jdbc-driver
[4] 
https://apacheignite.readme.io/docs/querying-and-modifying-data#inserting-data


was (Author: dmagda):
[~al.psc], I've briefly looked over the current documentation [1] and have a 
minor note.

Instead of providing raw SQL code snippets like the one below

{code} 
merge into Person(_key, first_name, second_name) values
  (1, "John", "Smith"),
  (5, "Mary", "Jones")
{code}

please use our Java SQL API instead like it's done over there [2] for SELECT 
queries code snippets.

In addition, as it mentioned in the ticket description, please add a DML 
related section into JDBC documentation [3]. The section simply should include 
code snippets for UPDATE, INSERT and DELETE queries executed using a JDBC 
connection. A good example of how the section should look like is shown on a 
similar ODBC documentation page [4].

[1] https://apacheignite.readme.io/docs/distributed-dml#dml-operations
[2] https://apacheignite.readme.io/docs/sql-queries#cross-cache-queries
[3] https://apacheignite.readme.io/docs/jdbc-driver
[4] 
https://apacheignite.readme.io/docs/querying-and-modifying-data#inserting-data

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, SQL
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



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

[jira] [Commented] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4018:
-

[~al.psc], I've briefly looked over the current documentation [1] and have a 
minor note.

Instead of providing raw SQL code snippets like the one below

{code} 
merge into Person(_key, first_name, second_name) values
  (1, "John", "Smith"),
  (5, "Mary", "Jones")
{code}

please use our Java SQL API instead like it's done over there [2] for SELECT 
queries code snippets.

In addition, as it mentioned in the ticket description, please add a DML 
related section into JDBC documentation [3]. The section simply should include 
code snippets for UPDATE, INSERT and DELETE queries executed using a JDBC 
connection. A good example of how the section should look like is shown on a 
similar ODBC documentation page [4].

[1] https://apacheignite.readme.io/docs/distributed-dml#dml-operations
[2] https://apacheignite.readme.io/docs/sql-queries#cross-cache-queries
[3] https://apacheignite.readme.io/docs/jdbc-driver
[4] 
https://apacheignite.readme.io/docs/querying-and-modifying-data#inserting-data

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, SQL
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



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

[jira] [Comment Edited] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-3921 at 12/1/16 12:23 AM:
---

[~pgarg], please edit the following documentation once you're back
https://apacheignite-mix.readme.io/v1.7/docs/php-pdo

After that we can close the ticket.


was (Author: dmagda):
[~pgarg], please edit the following documentation once you're back
https://apacheignite-mix.readme.io/v1.7/docs/php-pdo

> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Denis Magda
>  Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we 
> need to document it for our users.



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

[jira] [Commented] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3921:
-

[~pgarg], please edit the following documentation once you're back
https://apacheignite-mix.readme.io/v1.7/docs/php-pdo

> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Denis Magda
>  Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we 
> need to document it for our users.



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

[jira] [Updated] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3921:

Assignee: Prachi Garg  (was: Denis Magda)

> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Prachi Garg
>  Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we 
> need to document it for our users.



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

[jira] [Updated] (IGNITE-4347) ODBC: NPE when cache name is different from the one configured in DSN

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4347:

Attachment: exception.png

> ODBC: NPE when cache name is different from the one configured in DSN
> -
>
> Key: IGNITE-4347
> URL: https://issues.apache.org/jira/browse/IGNITE-4347
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 1.8
>
> Attachments: exception.png
>
>
> The following query was executed from PHP PDO side
> {code}
> $dbs = $dbh->prepare('INSERT INTO Person (_key, firstName, lastName, resume, 
> salary) 
> VALUES (?, ?, ?, ?, ?)');
> {code}
> The cache name in Spring XML configuration was "Person" while the DSN was 
> configured to use "PersonCache" as a default cache name.
> As a result, I was getting NPE shown in the attached screenshot. Only after I 
> sorted out the root cause of the NPE referring to the source code I could 
> finally fix the issue.
> Let's provide more meaningful explanation rather than throwing NPE saying 
> something like "The cache named {cache_name} has not been found. Make sure 
> that ODBC connection string or DSN is configured properly."



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

[jira] [Updated] (IGNITE-4347) ODBC: NPE when cache name is different from the one configured in DSN

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4347:

Fix Version/s: 1.8

> ODBC: NPE when cache name is different from the one configured in DSN
> -
>
> Key: IGNITE-4347
> URL: https://issues.apache.org/jira/browse/IGNITE-4347
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Denis Magda
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 1.8
>
> Attachments: exception.png
>
>
> The following query was executed from PHP PDO side
> {code}
> $dbs = $dbh->prepare('INSERT INTO Person (_key, firstName, lastName, resume, 
> salary) 
> VALUES (?, ?, ?, ?, ?)');
> {code}
> The cache name in Spring XML configuration was "Person" while the DSN was 
> configured to use "PersonCache" as a default cache name.
> As a result, I was getting NPE shown in the attached screenshot. Only after I 
> sorted out the root cause of the NPE referring to the source code I could 
> finally fix the issue.
> Let's provide more meaningful explanation rather than throwing NPE saying 
> something like "The cache named {cache_name} has not been found. Make sure 
> that ODBC connection string or DSN is configured properly."



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

[jira] [Updated] (IGNITE-4346) DML and PHP PDO: double field is converted to bigdecimal

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4346:

Attachment: dsn_configuration.png

> DML and PHP PDO: double field is converted to bigdecimal
> 
>
> Key: IGNITE-4346
> URL: https://issues.apache.org/jira/browse/IGNITE-4346
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
> Fix For: 1.8
>
> Attachments: default-config.xml, dsn_configuration.png, insert.php, 
> update.php
>
>
> I've set up PHP PDO and ODBC environment according to the following 
> documentation
> https://apacheignite-mix.readme.io/docs/php-pdo
> In particular:
> - The ODBC driver was built from the latest 1.8 sources located in ignite-1.8 
> branch. 
> - The DSN configuration is shown in the attached screenshot name 
> "dsn_configuration"
> - Ignite's cluster configuration is attached as well.
> To reproduce the issue do the following:
> - start a node using attached default-config.xml
> - execute insert.php. There won't be any error.
> - execute update.php and you'll get the error with the stack trace below
> {code}
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> DML
>  statement [qry=UPDATE Person SET salary = 42000.0 WHERE salary > 5.0, 
> param
> s=[]]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1800)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryT
> woStep(GridQueryProcessor.java:810)
> ... 13 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException:
>  Failed to execute DML statement [qry=UPDATE Person SET salary = 42000.0 
> WHERE s
> alary > 5.0, params=[]]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.query
> TwoStep(IgniteH2Indexing.java:1270)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:812)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:810)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOu
> tClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1777)
> ... 14 more
> Caused by: class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicChecke
> dException: Failed to locally write to cache (all transaction entries will be 
> in
> validated, however there was a window when entries for this transaction were 
> vis
> ible to others): GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl 
> [mapping=G
> ridDistributedTxMapping [entries=[IgniteTxEntry [key=KeyCacheObjectImpl 
> [val=777
> , hasValBytes=false], cacheId=1215863053, partId=-1, txKey=IgniteTxKey 
> [key=KeyC
> acheObjectImpl [val=777, hasValBytes=false], cacheId=1215863053], 
> val=[op=TRANSF
> ORM, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryPr
> ocessorsCol=[IgniteBiTuple 
> [val1=org.apache.ignite.internal.processors.query.h2.
> DmlStatementsProcessor$ModifyingEntryProcessor@1f2f10da, 
> val2=[Ljava.lang.Object
> ;@2bfa5294]], ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null,
>  dhtVer=GridCacheVersion [topVer=92027384, time=1480547401695, 
> order=14805473813
> 93, nodeOrder=1], filters=[], filtersPassed=false, filtersSet=true, 
> entry=GridDh
> tColocatedCacheEntry [super=GridDhtCacheEntry [rdrs=[], 
> locPart=GridDhtLocalPart
> ition [id=777, 
> map=org.apache.ignite.internal.processors.cache.GridCacheConcurre
> ntMapImpl@24c94530, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=0], 
> cntr=1
> , shouldBeRenting=false, state=OWNING, reservations=0, empty=false, 
> createTime=1
> 1/30/2016 15:09:45], super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [k
> ey=KeyCacheObjectImpl [val=777, hasValBytes=false], val=Person 
> [idHash=659295625
> , hash=-322179972, resume=Secret Service agent, firstName=James, 
> lastName=Bond,
> salary=65000.0], startVer=1480547381389, ver=GridCacheVersion 
> [topVer=92027384,
> time=1480547394518, order=1480547381390, nodeOrder=1], hash=777, 
> extras=GridCach
> eMvccEntryExtras [mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate 
> [nodeId=08b20
> b4b-3ca6-4c05-aa9d-4219cbc3f3f5, ver=GridCacheVersion [topVer=92027384, 
> time=148
> 0547401693, order=1480547381392, nodeOrder=1], timeout=0, ts=1480547401693, 
> thre
> adId=57, id=3, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0], 
> reentry
> =null, otherNodeId=08b20b4b-3ca6-4c05-aa9d-4219cbc3f3f5, 
> otherVer=GridCacheVersi
> on [topVer=92027384, 

[jira] [Commented] (IGNITE-4346) DML and PHP PDO: double field is converted to bigdecimal

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4346:
-

[~isapego], please assist Alexander with the debugging and fixing of the issue 
so that he doesn't need to set up PHP environment on his side.

Don't forget to add missing tests.

> DML and PHP PDO: double field is converted to bigdecimal
> 
>
> Key: IGNITE-4346
> URL: https://issues.apache.org/jira/browse/IGNITE-4346
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
> Fix For: 1.8
>
> Attachments: default-config.xml, insert.php, update.php
>
>
> I've set up PHP PDO and ODBC environment according to the following 
> documentation
> https://apacheignite-mix.readme.io/docs/php-pdo
> In particular:
> - The ODBC driver was built from the latest 1.8 sources located in ignite-1.8 
> branch. 
> - The DSN configuration is shown in the attached screenshot name 
> "dsn_configuration"
> - Ignite's cluster configuration is attached as well.
> To reproduce the issue do the following:
> - start a node using attached default-config.xml
> - execute insert.php. There won't be any error.
> - execute update.php and you'll get the error with the stack trace below
> {code}
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> DML
>  statement [qry=UPDATE Person SET salary = 42000.0 WHERE salary > 5.0, 
> param
> s=[]]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1800)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryT
> woStep(GridQueryProcessor.java:810)
> ... 13 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException:
>  Failed to execute DML statement [qry=UPDATE Person SET salary = 42000.0 
> WHERE s
> alary > 5.0, params=[]]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.query
> TwoStep(IgniteH2Indexing.java:1270)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:812)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:810)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOu
> tClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1777)
> ... 14 more
> Caused by: class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicChecke
> dException: Failed to locally write to cache (all transaction entries will be 
> in
> validated, however there was a window when entries for this transaction were 
> vis
> ible to others): GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl 
> [mapping=G
> ridDistributedTxMapping [entries=[IgniteTxEntry [key=KeyCacheObjectImpl 
> [val=777
> , hasValBytes=false], cacheId=1215863053, partId=-1, txKey=IgniteTxKey 
> [key=KeyC
> acheObjectImpl [val=777, hasValBytes=false], cacheId=1215863053], 
> val=[op=TRANSF
> ORM, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryPr
> ocessorsCol=[IgniteBiTuple 
> [val1=org.apache.ignite.internal.processors.query.h2.
> DmlStatementsProcessor$ModifyingEntryProcessor@1f2f10da, 
> val2=[Ljava.lang.Object
> ;@2bfa5294]], ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null,
>  dhtVer=GridCacheVersion [topVer=92027384, time=1480547401695, 
> order=14805473813
> 93, nodeOrder=1], filters=[], filtersPassed=false, filtersSet=true, 
> entry=GridDh
> tColocatedCacheEntry [super=GridDhtCacheEntry [rdrs=[], 
> locPart=GridDhtLocalPart
> ition [id=777, 
> map=org.apache.ignite.internal.processors.cache.GridCacheConcurre
> ntMapImpl@24c94530, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=0], 
> cntr=1
> , shouldBeRenting=false, state=OWNING, reservations=0, empty=false, 
> createTime=1
> 1/30/2016 15:09:45], super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [k
> ey=KeyCacheObjectImpl [val=777, hasValBytes=false], val=Person 
> [idHash=659295625
> , hash=-322179972, resume=Secret Service agent, firstName=James, 
> lastName=Bond,
> salary=65000.0], startVer=1480547381389, ver=GridCacheVersion 
> [topVer=92027384,
> time=1480547394518, order=1480547381390, nodeOrder=1], hash=777, 
> extras=GridCach
> eMvccEntryExtras [mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate 
> [nodeId=08b20
> b4b-3ca6-4c05-aa9d-4219cbc3f3f5, ver=GridCacheVersion [topVer=92027384, 
> time=148
> 0547401693, order=1480547381392, nodeOrder=1], timeout=0, ts=1480547401693, 
> thre
> adId=57, id=3, topVer=AffinityTopologyVersion 

[jira] [Updated] (IGNITE-4346) DML and PHP PDO: double field is converted to bigdecimal

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4346:

Fix Version/s: 1.8

> DML and PHP PDO: double field is converted to bigdecimal
> 
>
> Key: IGNITE-4346
> URL: https://issues.apache.org/jira/browse/IGNITE-4346
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
> Fix For: 1.8
>
> Attachments: default-config.xml, insert.php, update.php
>
>
> I've set up PHP PDO and ODBC environment according to the following 
> documentation
> https://apacheignite-mix.readme.io/docs/php-pdo
> In particular:
> - The ODBC driver was built from the latest 1.8 sources located in ignite-1.8 
> branch. 
> - The DSN configuration is shown in the attached screenshot name 
> "dsn_configuration"
> - Ignite's cluster configuration is attached as well.
> To reproduce the issue do the following:
> - start a node using attached default-config.xml
> - execute insert.php. There won't be any error.
> - execute update.php and you'll get the error with the stack trace below
> {code}
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> DML
>  statement [qry=UPDATE Person SET salary = 42000.0 WHERE salary > 5.0, 
> param
> s=[]]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1800)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryT
> woStep(GridQueryProcessor.java:810)
> ... 13 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException:
>  Failed to execute DML statement [qry=UPDATE Person SET salary = 42000.0 
> WHERE s
> alary > 5.0, params=[]]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.query
> TwoStep(IgniteH2Indexing.java:1270)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:812)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:810)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOu
> tClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1777)
> ... 14 more
> Caused by: class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicChecke
> dException: Failed to locally write to cache (all transaction entries will be 
> in
> validated, however there was a window when entries for this transaction were 
> vis
> ible to others): GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl 
> [mapping=G
> ridDistributedTxMapping [entries=[IgniteTxEntry [key=KeyCacheObjectImpl 
> [val=777
> , hasValBytes=false], cacheId=1215863053, partId=-1, txKey=IgniteTxKey 
> [key=KeyC
> acheObjectImpl [val=777, hasValBytes=false], cacheId=1215863053], 
> val=[op=TRANSF
> ORM, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryPr
> ocessorsCol=[IgniteBiTuple 
> [val1=org.apache.ignite.internal.processors.query.h2.
> DmlStatementsProcessor$ModifyingEntryProcessor@1f2f10da, 
> val2=[Ljava.lang.Object
> ;@2bfa5294]], ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null,
>  dhtVer=GridCacheVersion [topVer=92027384, time=1480547401695, 
> order=14805473813
> 93, nodeOrder=1], filters=[], filtersPassed=false, filtersSet=true, 
> entry=GridDh
> tColocatedCacheEntry [super=GridDhtCacheEntry [rdrs=[], 
> locPart=GridDhtLocalPart
> ition [id=777, 
> map=org.apache.ignite.internal.processors.cache.GridCacheConcurre
> ntMapImpl@24c94530, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=0], 
> cntr=1
> , shouldBeRenting=false, state=OWNING, reservations=0, empty=false, 
> createTime=1
> 1/30/2016 15:09:45], super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [k
> ey=KeyCacheObjectImpl [val=777, hasValBytes=false], val=Person 
> [idHash=659295625
> , hash=-322179972, resume=Secret Service agent, firstName=James, 
> lastName=Bond,
> salary=65000.0], startVer=1480547381389, ver=GridCacheVersion 
> [topVer=92027384,
> time=1480547394518, order=1480547381390, nodeOrder=1], hash=777, 
> extras=GridCach
> eMvccEntryExtras [mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate 
> [nodeId=08b20
> b4b-3ca6-4c05-aa9d-4219cbc3f3f5, ver=GridCacheVersion [topVer=92027384, 
> time=148
> 0547401693, order=1480547381392, nodeOrder=1], timeout=0, ts=1480547401693, 
> thre
> adId=57, id=3, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0], 
> reentry
> =null, otherNodeId=08b20b4b-3ca6-4c05-aa9d-4219cbc3f3f5, 
> otherVer=GridCacheVersi
> on [topVer=92027384, time=1480547401693, order=1480547381392, 

[jira] [Updated] (IGNITE-4346) DML and PHP PDO: double field is converted to bigdecimal

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4346:

Attachment: update.php
insert.php
default-config.xml

> DML and PHP PDO: double field is converted to bigdecimal
> 
>
> Key: IGNITE-4346
> URL: https://issues.apache.org/jira/browse/IGNITE-4346
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
> Attachments: default-config.xml, insert.php, update.php
>
>
> I've set up PHP PDO and ODBC environment according to the following 
> documentation
> https://apacheignite-mix.readme.io/docs/php-pdo
> In particular:
> - The ODBC driver was built from the latest 1.8 sources located in ignite-1.8 
> branch. 
> - The DSN configuration is shown in the attached screenshot name 
> "dsn_configuration"
> - Ignite's cluster configuration is attached as well.
> To reproduce the issue do the following:
> - start a node using attached default-config.xml
> - execute insert.php. There won't be any error.
> - execute update.php and you'll get the error with the stack trace below
> {code}
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute 
> DML
>  statement [qry=UPDATE Person SET salary = 42000.0 WHERE salary > 5.0, 
> param
> s=[]]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1800)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryT
> woStep(GridQueryProcessor.java:810)
> ... 13 more
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException:
>  Failed to execute DML statement [qry=UPDATE Person SET salary = 42000.0 
> WHERE s
> alary > 5.0, params=[]]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.query
> TwoStep(IgniteH2Indexing.java:1270)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:812)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
> yx(GridQueryProcessor.java:810)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOu
> tClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
> eQuery(GridQueryProcessor.java:1777)
> ... 14 more
> Caused by: class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicChecke
> dException: Failed to locally write to cache (all transaction entries will be 
> in
> validated, however there was a window when entries for this transaction were 
> vis
> ible to others): GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl 
> [mapping=G
> ridDistributedTxMapping [entries=[IgniteTxEntry [key=KeyCacheObjectImpl 
> [val=777
> , hasValBytes=false], cacheId=1215863053, partId=-1, txKey=IgniteTxKey 
> [key=KeyC
> acheObjectImpl [val=777, hasValBytes=false], cacheId=1215863053], 
> val=[op=TRANSF
> ORM, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryPr
> ocessorsCol=[IgniteBiTuple 
> [val1=org.apache.ignite.internal.processors.query.h2.
> DmlStatementsProcessor$ModifyingEntryProcessor@1f2f10da, 
> val2=[Ljava.lang.Object
> ;@2bfa5294]], ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null,
>  dhtVer=GridCacheVersion [topVer=92027384, time=1480547401695, 
> order=14805473813
> 93, nodeOrder=1], filters=[], filtersPassed=false, filtersSet=true, 
> entry=GridDh
> tColocatedCacheEntry [super=GridDhtCacheEntry [rdrs=[], 
> locPart=GridDhtLocalPart
> ition [id=777, 
> map=org.apache.ignite.internal.processors.cache.GridCacheConcurre
> ntMapImpl@24c94530, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=0], 
> cntr=1
> , shouldBeRenting=false, state=OWNING, reservations=0, empty=false, 
> createTime=1
> 1/30/2016 15:09:45], super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [k
> ey=KeyCacheObjectImpl [val=777, hasValBytes=false], val=Person 
> [idHash=659295625
> , hash=-322179972, resume=Secret Service agent, firstName=James, 
> lastName=Bond,
> salary=65000.0], startVer=1480547381389, ver=GridCacheVersion 
> [topVer=92027384,
> time=1480547394518, order=1480547381390, nodeOrder=1], hash=777, 
> extras=GridCach
> eMvccEntryExtras [mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate 
> [nodeId=08b20
> b4b-3ca6-4c05-aa9d-4219cbc3f3f5, ver=GridCacheVersion [topVer=92027384, 
> time=148
> 0547401693, order=1480547381392, nodeOrder=1], timeout=0, ts=1480547401693, 
> thre
> adId=57, id=3, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0], 
> reentry
> =null, otherNodeId=08b20b4b-3ca6-4c05-aa9d-4219cbc3f3f5, 
> otherVer=GridCacheVersi
> on [topVer=92027384, 

[jira] [Created] (IGNITE-4346) DML and PHP PDO: double field is converted to bigdecimal

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4346:
---

 Summary: DML and PHP PDO: double field is converted to bigdecimal
 Key: IGNITE-4346
 URL: https://issues.apache.org/jira/browse/IGNITE-4346
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Assignee: Alexander Paschenko
Priority: Blocker


I've set up PHP PDO and ODBC environment according to the following 
documentation
https://apacheignite-mix.readme.io/docs/php-pdo

In particular:
- The ODBC driver was built from the latest 1.8 sources located in ignite-1.8 
branch. 
- The DSN configuration is shown in the attached screenshot name 
"dsn_configuration"
- Ignite's cluster configuration is attached as well.

To reproduce the issue do the following:
- start a node using attached default-config.xml
- execute insert.php. There won't be any error.
- execute update.php and you'll get the error with the stack trace below

{code}
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute DML
 statement [qry=UPDATE Person SET salary = 42000.0 WHERE salary > 5.0, param
s=[]]
at org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
eQuery(GridQueryProcessor.java:1800)
at org.apache.ignite.internal.processors.query.GridQueryProcessor.queryT
woStep(GridQueryProcessor.java:810)
... 13 more
Caused by: class org.apache.ignite.internal.processors.query.IgniteSQLException:
 Failed to execute DML statement [qry=UPDATE Person SET salary = 42000.0 WHERE s
alary > 5.0, params=[]]
at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.query
TwoStep(IgniteH2Indexing.java:1270)
at org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
yx(GridQueryProcessor.java:812)
at org.apache.ignite.internal.processors.query.GridQueryProcessor$4.appl
yx(GridQueryProcessor.java:810)
at org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOu
tClosureX.java:36)
at org.apache.ignite.internal.processors.query.GridQueryProcessor.execut
eQuery(GridQueryProcessor.java:1777)
... 14 more
Caused by: class org.apache.ignite.internal.transactions.IgniteTxHeuristicChecke
dException: Failed to locally write to cache (all transaction entries will be in
validated, however there was a window when entries for this transaction were vis
ible to others): GridNearTxLocal [mappings=IgniteTxMappingsSingleImpl [mapping=G
ridDistributedTxMapping [entries=[IgniteTxEntry [key=KeyCacheObjectImpl [val=777
, hasValBytes=false], cacheId=1215863053, partId=-1, txKey=IgniteTxKey [key=KeyC
acheObjectImpl [val=777, hasValBytes=false], cacheId=1215863053], val=[op=TRANSF
ORM, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], entryPr
ocessorsCol=[IgniteBiTuple [val1=org.apache.ignite.internal.processors.query.h2.
DmlStatementsProcessor$ModifyingEntryProcessor@1f2f10da, val2=[Ljava.lang.Object
;@2bfa5294]], ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
 dhtVer=GridCacheVersion [topVer=92027384, time=1480547401695, order=14805473813
93, nodeOrder=1], filters=[], filtersPassed=false, filtersSet=true, entry=GridDh
tColocatedCacheEntry [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPart
ition [id=777, map=org.apache.ignite.internal.processors.cache.GridCacheConcurre
ntMapImpl@24c94530, rmvQueue=GridCircularBuffer [sizeMask=255, idxGen=0], cntr=1
, shouldBeRenting=false, state=OWNING, reservations=0, empty=false, createTime=1
1/30/2016 15:09:45], super=GridDistributedCacheEntry [super=GridCacheMapEntry [k
ey=KeyCacheObjectImpl [val=777, hasValBytes=false], val=Person [idHash=659295625
, hash=-322179972, resume=Secret Service agent, firstName=James, lastName=Bond,
salary=65000.0], startVer=1480547381389, ver=GridCacheVersion [topVer=92027384,
time=1480547394518, order=1480547381390, nodeOrder=1], hash=777, extras=GridCach
eMvccEntryExtras [mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate [nodeId=08b20
b4b-3ca6-4c05-aa9d-4219cbc3f3f5, ver=GridCacheVersion [topVer=92027384, time=148
0547401693, order=1480547381392, nodeOrder=1], timeout=0, ts=1480547401693, thre
adId=57, id=3, topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0], reentry
=null, otherNodeId=08b20b4b-3ca6-4c05-aa9d-4219cbc3f3f5, otherVer=GridCacheVersi
on [topVer=92027384, time=1480547401693, order=1480547381392, nodeOrder=1], mapp
edDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, key=KeyCach
eObjectImpl [val=777, hasValBytes=false], masks=local=1|owner=1|ready=1|reentry=
0|used=0|tx=1|single_implicit=1|dht_local=1|near_local=0|removed=0, prevVer=null
, nextVer=null]], rmts=null]], flags=0, prepared=1, locked=false, nodeId=08b
20b4b-3ca6-4c05-aa9d-4219cbc3f3f5, locMapped=false, expiryPlc=null, transferExpi
ryPlc=false, flags=6, partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion
 [topVer=92027384, time=1480547401693, 

[jira] [Updated] (IGNITE-4345) incorrect/outdated info on site

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4345:

Fix Version/s: 1.8

> incorrect/outdated info on site
> ---
>
> Key: IGNITE-4345
> URL: https://issues.apache.org/jira/browse/IGNITE-4345
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Sergey Korzhevsky
>Assignee: Nikolay Tikhonov
>Priority: Trivial
> Fix For: 1.8
>
>
> Old/icorrect info on the site.
> 1) http://ignite.apache.org/download.cgi#docker
>a) "guide" link points to 1.5 version
>b) "docker repository" is a broken link, should be 
> https://hub.docker.com/u/apacheignite/
> i guess.
> 2) https://apacheignite.readme.io/v1.7/docs/docker-deployment
> IGNITE_CONFIG "example url"'s file (https://raw.githubusercontent.com/
> bob/master/ignite-cfg.xml) does not exists.
> I think, it may be pointed to the some file in the current github repo. 



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

[jira] [Updated] (IGNITE-4345) incorrect/outdated info on site

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4345:

Assignee: Nikolay Tikhonov

> incorrect/outdated info on site
> ---
>
> Key: IGNITE-4345
> URL: https://issues.apache.org/jira/browse/IGNITE-4345
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Sergey Korzhevsky
>Assignee: Nikolay Tikhonov
>Priority: Trivial
> Fix For: 1.8
>
>
> Old/icorrect info on the site.
> 1) http://ignite.apache.org/download.cgi#docker
>a) "guide" link points to 1.5 version
>b) "docker repository" is a broken link, should be 
> https://hub.docker.com/u/apacheignite/
> i guess.
> 2) https://apacheignite.readme.io/v1.7/docs/docker-deployment
> IGNITE_CONFIG "example url"'s file (https://raw.githubusercontent.com/
> bob/master/ignite-cfg.xml) does not exists.
> I think, it may be pointed to the some file in the current github repo. 



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

[jira] [Commented] (IGNITE-4345) incorrect/outdated info on site

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4345:
-

I've fixed point 1.

[~ntikhonov], please take care of 2. 

In general, please review the overall Docker-related documentation cleaning out 
an outdated information
https://apacheignite.readme.io/docs/docker-deployment

In addition, please answer on the following:

1) Do we still need to use your own repository in this example 
(https://apacheignite.readme.io/docs/docker-deployment#section-example)?

2) Why AWS and GCE deployment is described in the Docker documentation? Any 
reason why we don't have dedicated pages for these cloud platforms?


> incorrect/outdated info on site
> ---
>
> Key: IGNITE-4345
> URL: https://issues.apache.org/jira/browse/IGNITE-4345
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Sergey Korzhevsky
>Priority: Trivial
>
> Old/icorrect info on the site.
> 1) http://ignite.apache.org/download.cgi#docker
>a) "guide" link points to 1.5 version
>b) "docker repository" is a broken link, should be 
> https://hub.docker.com/u/apacheignite/
> i guess.
> 2) https://apacheignite.readme.io/v1.7/docs/docker-deployment
> IGNITE_CONFIG "example url"'s file (https://raw.githubusercontent.com/
> bob/master/ignite-cfg.xml) does not exists.
> I think, it may be pointed to the some file in the current github repo. 



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

[jira] [Created] (IGNITE-4345) incorrect/outdated info on site

[Sergey Korzhevsky (JIRA)]

Sergey Korzhevsky created IGNITE-4345:
-

 Summary: incorrect/outdated info on site
 Key: IGNITE-4345
 URL: https://issues.apache.org/jira/browse/IGNITE-4345
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Reporter: Sergey Korzhevsky
Priority: Trivial


Old/icorrect info on the site.

1) http://ignite.apache.org/download.cgi#docker
   a) "guide" link points to 1.5 version
   b) "docker repository" is a broken link, should be 
https://hub.docker.com/u/apacheignite/
i guess.


2) https://apacheignite.readme.io/v1.7/docs/docker-deployment
IGNITE_CONFIG "example url"'s file (https://raw.githubusercontent.com/
bob/master/ignite-cfg.xml) does not exists.
I think, it may be pointed to the some file in the current github repo. 




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

[jira] [Closed] (IGNITE-1352) Platforms: move cpp and .Net examples to Ignite

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-1352.
---

> Platforms: move cpp and .Net examples to Ignite
> ---
>
> Key: IGNITE-1352
> URL: https://issues.apache.org/jira/browse/IGNITE-1352
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>
> Move the platform examples to Ignite.
> Portable API examples have already been moved and the changes should be 
> committed to the master soon. Track IGNITE-1351 status for that.
> When the platform examples are moved make sure that 
> {{CacheClientPortableCrossPlatformExample}} works as expected.



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

[jira] [Resolved] (IGNITE-4325) Proposing new marshaller mapping should be done in synchronous way

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov resolved IGNITE-4325.
-
Resolution: Fixed

Reimplemented marshalling data exchange using synchronous waiting for 
acceptance of proposed mapping by all grid server nodes.

> Proposing new marshaller mapping should be done in synchronous way
> --
>
> Key: IGNITE-4325
> URL: https://issues.apache.org/jira/browse/IGNITE-4325
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> h3. Notes
> Previous version of DiscoveryCustomEvent-based MarshallerContext 
> implementation returned immediately with "not registered" flag after 
> submitting request for new mapping.
> This may be ineffective in terms of network traffic and not well suited with 
> current implementation of BinaryCache.
> h3. Acceptance Criteria
> # Registration of new mapping should return when the mapping is accepted by 
> grid.
> # Registration of new mapping should throw an exception when the mapping is 
> in conflict with grid.



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

[jira] [Commented] (IGNITE-4140) KafkaStreamer should use tuple extractor instead of decoders

[Anil (JIRA)]

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

Anil commented on IGNITE-4140:
--

Hi [~avinogradov] 

Thanks for comments. 
#1 - Creating new steamer will provide backward compatibility and KafkaStreamer 
can be Deprecated when KafkaDataStreamer is ready. 
What do you say ? if team prefers refactoring of KafkaStreamer, i will do.
#2 - i am not sure how to use review tool. could you please share any 
references to use the tool ?

Thanks


 

> KafkaStreamer should use tuple extractor instead of decoders
> 
>
> Key: IGNITE-4140
> URL: https://issues.apache.org/jira/browse/IGNITE-4140
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Anil
>  Labels: patch-available
> Fix For: 2.0
>
>
> Current design of {{KafkaStreamer}} looks incorrect to me. In particular, it 
> extends {{StreamAdapter}}, but ignores tuple extractors provided there and 
> uses native Kafka decoders instead. This for example makes impossible to 
> produce several entries from one message, like it can be done via 
> {{StreamMultipleTupleExtractor}} in other streamers.
> To fix this, we should:
> # Declare the {{KafkaStreamer}} like this:
> {code}
> KafkaStreamer extends StreamAdapter, 
> K, V>
> {code}
> # Remove {{keyDecoder}} and {{valDecoder}} in favor of tuple extractors.
> # Instead of doing {{getStreamer().addData(...)}} directly, call 
> {{addMessage(...)}} method providing the raw message consumed from Kafka 
> ({{MessageAndMetadata}}). This method will make sure that 
> configured extractor is invoked and that all entries are added to 
> {{IgniteDataStreamer}}.



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

[jira] [Commented] (IGNITE-1352) Platforms: move cpp and .Net examples to Ignite

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1352:


Already done, closing

> Platforms: move cpp and .Net examples to Ignite
> ---
>
> Key: IGNITE-1352
> URL: https://issues.apache.org/jira/browse/IGNITE-1352
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>
> Move the platform examples to Ignite.
> Portable API examples have already been moved and the changes should be 
> committed to the master soon. Track IGNITE-1351 status for that.
> When the platform examples are moved make sure that 
> {{CacheClientPortableCrossPlatformExample}} works as expected.



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

[jira] [Commented] (IGNITE-4140) KafkaStreamer should use tuple extractor instead of decoders

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-4140:
--

Anil, 

Initial comments:
1) We have to refactor KafkaStreamer instead of creating KafkaDataStreamer. 
2) It will be easy to review changes using Apache Ignite review tool: 
http://reviews.ignite.apache.org/ignite/view
In case you're using IDEA just setup Upsource and start review, it will allow 
to discuss changes in simple way.
Add me and Valentin Kulichenko as reviewers.






> KafkaStreamer should use tuple extractor instead of decoders
> 
>
> Key: IGNITE-4140
> URL: https://issues.apache.org/jira/browse/IGNITE-4140
> Project: Ignite
>  Issue Type: Improvement
>  Components: streaming
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Anil
>  Labels: patch-available
> Fix For: 2.0
>
>
> Current design of {{KafkaStreamer}} looks incorrect to me. In particular, it 
> extends {{StreamAdapter}}, but ignores tuple extractors provided there and 
> uses native Kafka decoders instead. This for example makes impossible to 
> produce several entries from one message, like it can be done via 
> {{StreamMultipleTupleExtractor}} in other streamers.
> To fix this, we should:
> # Declare the {{KafkaStreamer}} like this:
> {code}
> KafkaStreamer extends StreamAdapter, 
> K, V>
> {code}
> # Remove {{keyDecoder}} and {{valDecoder}} in favor of tuple extractors.
> # Instead of doing {{getStreamer().addData(...)}} directly, call 
> {{addMessage(...)}} method providing the raw message consumed from Kafka 
> ({{MessageAndMetadata}}). This method will make sure that 
> configured extractor is invoked and that all entries are added to 
> {{IgniteDataStreamer}}.



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

[jira] [Updated] (IGNITE-4344) Client node allocates off heap memories for caches

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov updated IGNITE-4344:
-
Attachment: OffHeapClientTest.patch

> Client node allocates off heap memories for caches
> --
>
> Key: IGNITE-4344
> URL: https://issues.apache.org/jira/browse/IGNITE-4344
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6, 1.7
>Reporter: Nikolay Tikhonov
> Fix For: 1.9
>
> Attachments: OffHeapClientTest.patch
>
>
> Client node should not allocate memories. Test attached.



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

[jira] [Created] (IGNITE-4344) Client node allocates off heap memories for caches

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4344:


 Summary: Client node allocates off heap memories for caches
 Key: IGNITE-4344
 URL: https://issues.apache.org/jira/browse/IGNITE-4344
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7, 1.6
Reporter: Nikolay Tikhonov
 Fix For: 1.9


Client node should not allocate memories. Test attached.



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

[jira] [Updated] (IGNITE-3964) SQL: implement support for custom table name

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-3964:
-
Summary: SQL: implement support for custom table name  (was: SQL: implement 
support for table alias)

> SQL: implement support for custom table name
> 
>
> Key: IGNITE-3964
> URL: https://issues.apache.org/jira/browse/IGNITE-3964
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> We have ability to specify aliases for columns via 
> org.apache.ignite.cache.QueryEntity#getAliases.
> But how about alias for table name? This could be useful in case of moving 
> legacy application to Ignite with a lot of SQL statements.



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

[jira] [Commented] (IGNITE-3964) SQL: implement support for table alias

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-3964:
--

Andrew, 
I think it would be enough to have a possibility to set custom table name.

> SQL: implement support for table alias
> --
>
> Key: IGNITE-3964
> URL: https://issues.apache.org/jira/browse/IGNITE-3964
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> We have ability to specify aliases for columns via 
> org.apache.ignite.cache.QueryEntity#getAliases.
> But how about alias for table name? This could be useful in case of moving 
> legacy application to Ignite with a lot of SQL statements.



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

[jira] [Created] (IGNITE-4343) Check mutable entries for existence properly inside DML entry processors

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4343:
---

 Summary: Check mutable entries for existence properly inside DML 
entry processors
 Key: IGNITE-4343
 URL: https://issues.apache.org/jira/browse/IGNITE-4343
 Project: Ignite
  Issue Type: Improvement
  Components: SQL
Affects Versions: 1.8
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.8






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

[jira] [Assigned] (IGNITE-4340) Implicitly cast new column values to expected types on SQL UPDATE

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-4340:
---

Assignee: Alexander Paschenko  (was: Sergi Vladykin)

> Implicitly cast new column values to expected types on SQL UPDATE
> -
>
> Key: IGNITE-4340
> URL: https://issues.apache.org/jira/browse/IGNITE-4340
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> When the following query is run,
> {code:sql}
> update AllTypes set longCol = 1 where _key = ?
> {code}
> it fails with exception
> {noformat}
> Suppressed: java.lang.ClassCastException: java.lang.Integer cannot be cast to 
> java.lang.Long
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.wrap(IgniteH2Indexing.java:2960)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:316)
>   at 
> org.h2.index.BaseIndex.compareRows(BaseIndex.java:294)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:103)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:95)
>   at 
> java.util.concurrent.ConcurrentSkipListMap$ComparableUsingComparator.compareTo(ConcurrentSkipListMap.java:647)
>   at 
> java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:727)
>   at 
> java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:850)
>   at 
> java.util.concurrent.ConcurrentSkipListMap.put(ConcurrentSkipListMap.java:1645)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.put(GridH2TreeIndex.java:362)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:566)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:495)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:603)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:737)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:431)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4019)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2458)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2385)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1787)
> {noformat}
> It's due to that UPDATE's SELECT part selects 1 as int, and that's what we're 
> setting to field. Problem can be solved by casting SELECTed values to the 
> types that columns expect.



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

[jira] [Commented] (IGNITE-4340) Implicitly cast new column values to expected types on SQL UPDATE

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4340:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-4340 Convert results of sub SELECTs to expected column types



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

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

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

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


commit 2991fb45e8d6c06de216c0fa9dcd98f843b43bf8
Author: Alexander Paschenko 
Date:   2016-11-30T15:05:06Z

IGNITE-4340 Convert results of sub SELECTs to expected column types inside 
INSERT, DELETE, and MERGE




> Implicitly cast new column values to expected types on SQL UPDATE
> -
>
> Key: IGNITE-4340
> URL: https://issues.apache.org/jira/browse/IGNITE-4340
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> When the following query is run,
> {code:sql}
> update AllTypes set longCol = 1 where _key = ?
> {code}
> it fails with exception
> {noformat}
> Suppressed: java.lang.ClassCastException: java.lang.Integer cannot be cast to 
> java.lang.Long
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.wrap(IgniteH2Indexing.java:2960)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:316)
>   at 
> org.h2.index.BaseIndex.compareRows(BaseIndex.java:294)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:103)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:95)
>   at 
> java.util.concurrent.ConcurrentSkipListMap$ComparableUsingComparator.compareTo(ConcurrentSkipListMap.java:647)
>   at 
> java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:727)
>   at 
> java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:850)
>   at 
> java.util.concurrent.ConcurrentSkipListMap.put(ConcurrentSkipListMap.java:1645)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.put(GridH2TreeIndex.java:362)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:566)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:495)
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:603)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:737)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:431)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4019)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2458)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2385)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1787)
> {noformat}
> It's due to that UPDATE's SELECT part selects 1 as int, and that's what we're 
> setting to field. Problem can be solved by casting SELECTed values to the 
> types that columns expect.



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

[jira] [Comment Edited] (IGNITE-3964) SQL: implement support for table alias

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov edited comment on IGNITE-3964 at 11/30/16 3:07 PM:


H2 does not support table aliases and it seems we can't overcome this.

[~kuaw26], did you mean a table alias support (that mean table is accessible by 
more than one name) or it would be enough to have a possibility to set custom 
table name? 
For now table name is generated automatically depending on entity instance type 
name and can not be customized. But it could be added easily.


was (Author: amashenkov):
H2 does not support table aliases and it seems we can't overcome this.

[~kuaw26], did you mean a table alias support (that mean table is accessible by 
more than one name) or it would be enough to have a possibility to set custom 
table name? 
For now table name is generated automatically depending on entity instance type 
name and can not be customized.

> SQL: implement support for table alias
> --
>
> Key: IGNITE-3964
> URL: https://issues.apache.org/jira/browse/IGNITE-3964
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> We have ability to specify aliases for columns via 
> org.apache.ignite.cache.QueryEntity#getAliases.
> But how about alias for table name? This could be useful in case of moving 
> legacy application to Ignite with a lot of SQL statements.



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

[jira] [Commented] (IGNITE-3964) SQL: implement support for table alias

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-3964:
--

H2 does not support table aliases and it seems we can't overcome this.

[~kuaw26], did you mean a table alias support (that mean table is accessible by 
more than one name) or it would be enough to have a possibility to set custom 
table name? 
For now table name is generated automatically depending on entity instance type 
name and can not be customized.

> SQL: implement support for table alias
> --
>
> Key: IGNITE-3964
> URL: https://issues.apache.org/jira/browse/IGNITE-3964
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> We have ability to specify aliases for columns via 
> org.apache.ignite.cache.QueryEntity#getAliases.
> But how about alias for table name? This could be useful in case of moving 
> legacy application to Ignite with a lot of SQL statements.



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

[jira] [Updated] (IGNITE-4342) DML: clear() on atomic cache causes the exception from previous failed DML statement

[Sergey Kozlov (JIRA)]

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

Sergey Kozlov updated IGNITE-4342:
--
Attachment: IGNITE-4342.zip

> DML: clear() on atomic cache causes the exception from previous failed DML 
> statement
> 
>
> Key: IGNITE-4342
> URL: https://issues.apache.org/jira/browse/IGNITE-4342
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.8
>Reporter: Sergey Kozlov
> Fix For: 1.8
>
> Attachments: IGNITE-4342.zip
>
>
> 0. Extact the attachment into {{examples}} directory
> 1. Start {{ExtSqlExampleNodeStartup}}
> 2. Start {{ExtSqlAtomicExample}}. It fails:
> {noformat}
> [17:22:23,763][INFO ][main][GridDiscoveryManager] Topology snapshot [ver=6, 
> servers=1, clients=1, CPUs=8, heap=2.0GB]
> The cache size atomic-part-full-sync: 0
> Preloading ... 
> The cache size atomic-part-full-sync: 1000
> Update failed
> Clear cache atomic-part-full-sync
> [17:22:25,207][ERROR][mgmt-#60%null%][GridTaskWorker] Failed to obtain remote 
> job result policy for result from ComputeTask.result(..) method (will fail 
> the whole task): GridJobResultImpl 
> [job=o.a.i.i.processors.cache.GridCacheAdapter$GlobalClearAllJob@5dca5ddf, 
> sib=GridJobSiblingImpl 
> [sesId=3fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, 
> jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, 
> nodeId=87311db5-3911-41f6-ac47-e739031a91dd, isJobDone=false], 
> jobCtx=GridJobContextImpl 
> [jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, timeoutObj=null, 
> attrs={}], node=TcpDiscoveryNode [id=87311db5-3911-41f6-ac47-e739031a91dd, 
> addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 172.22.222.137, 172.25.4.107], 
> sockAddrs=[/172.22.222.137:47500, /172.25.4.107:47500, /127.0.0.1:47500, 
> /0:0:0:0:0:0:0:1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1480515743167, loc=false, ver=1.8.0#20161128-sha1:a53fd38c, 
> isClient=false], ex=class o.a.i.compute.ComputeUserUndeclaredException: 
> Failed to execute job due to unexpected runtime exception 
> [jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, 
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl 
> [taskName=o.a.i.i.processors.cache.GridCacheAdapter$ClearTask, 
> dep=LocalDeployment [super=GridDeployment [ts=1480515673415, depMode=SHARED, 
> clsLdr=sun.misc.Launcher$AppClassLoader@2e5f8245, 
> clsLdrId=ef34c95b851-87311db5-3911-41f6-ac47-e739031a91dd, userVer=0, 
> loc=true, sampleClsName=java.lang.String, pendingUndeploy=false, 
> undeployed=false, usage=0]], 
> taskClsName=o.a.i.i.processors.cache.GridCacheAdapter$ClearTask, 
> sesId=3fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, 
> startTime=1480515745181, endTime=9223372036854775807, 
> taskNodeId=3bc6c31d-7339-434a-b0cd-2edda611fc19, 
> clsLdr=sun.misc.Launcher$AppClassLoader@2e5f8245, closed=false, cpSpi=null, 
> failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=true, 
> subjId=3bc6c31d-7339-434a-b0cd-2edda611fc19, mapFut=IgniteFuture 
> [orig=GridFutureAdapter [resFlag=0, res=null, startTime=1480515745181, 
> endTime=0, ignoreInterrupts=false, state=INIT]]], 
> jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19]], hasRes=true, 
> isCancelled=false, isOccupied=true]
> class org.apache.ignite.IgniteException: Remote job threw exception.
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$ClearTask.result(GridCacheAdapter.java:6800)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1030)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1023)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6596)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1023)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:841)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:996)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1221)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> 

[jira] [Created] (IGNITE-4342) DML: clear() on atomic cache causes the exception from previous failed DML statement

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-4342:
-

 Summary: DML: clear() on atomic cache causes the exception from 
previous failed DML statement
 Key: IGNITE-4342
 URL: https://issues.apache.org/jira/browse/IGNITE-4342
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.8
Reporter: Sergey Kozlov
 Fix For: 1.8


0. Extact the attachment into {{examples}} directory
1. Start {{ExtSqlExampleNodeStartup}}
2. Start {{ExtSqlAtomicExample}}. It fails:
{noformat}
[17:22:23,763][INFO ][main][GridDiscoveryManager] Topology snapshot [ver=6, 
servers=1, clients=1, CPUs=8, heap=2.0GB]
The cache size atomic-part-full-sync: 0
Preloading ... 
The cache size atomic-part-full-sync: 1000
Update failed
Clear cache atomic-part-full-sync
[17:22:25,207][ERROR][mgmt-#60%null%][GridTaskWorker] Failed to obtain remote 
job result policy for result from ComputeTask.result(..) method (will fail the 
whole task): GridJobResultImpl 
[job=o.a.i.i.processors.cache.GridCacheAdapter$GlobalClearAllJob@5dca5ddf, 
sib=GridJobSiblingImpl [sesId=3fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, 
jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, 
nodeId=87311db5-3911-41f6-ac47-e739031a91dd, isJobDone=false], 
jobCtx=GridJobContextImpl 
[jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, timeoutObj=null, 
attrs={}], node=TcpDiscoveryNode [id=87311db5-3911-41f6-ac47-e739031a91dd, 
addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 172.22.222.137, 172.25.4.107], 
sockAddrs=[/172.22.222.137:47500, /172.25.4.107:47500, /127.0.0.1:47500, 
/0:0:0:0:0:0:0:1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1480515743167, loc=false, ver=1.8.0#20161128-sha1:a53fd38c, 
isClient=false], ex=class o.a.i.compute.ComputeUserUndeclaredException: Failed 
to execute job due to unexpected runtime exception 
[jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, ses=GridJobSessionImpl 
[ses=GridTaskSessionImpl 
[taskName=o.a.i.i.processors.cache.GridCacheAdapter$ClearTask, 
dep=LocalDeployment [super=GridDeployment [ts=1480515673415, depMode=SHARED, 
clsLdr=sun.misc.Launcher$AppClassLoader@2e5f8245, 
clsLdrId=ef34c95b851-87311db5-3911-41f6-ac47-e739031a91dd, userVer=0, loc=true, 
sampleClsName=java.lang.String, pendingUndeploy=false, undeployed=false, 
usage=0]], taskClsName=o.a.i.i.processors.cache.GridCacheAdapter$ClearTask, 
sesId=3fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, 
startTime=1480515745181, endTime=9223372036854775807, 
taskNodeId=3bc6c31d-7339-434a-b0cd-2edda611fc19, 
clsLdr=sun.misc.Launcher$AppClassLoader@2e5f8245, closed=false, cpSpi=null, 
failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=true, 
subjId=3bc6c31d-7339-434a-b0cd-2edda611fc19, mapFut=IgniteFuture 
[orig=GridFutureAdapter [resFlag=0, res=null, startTime=1480515745181, 
endTime=0, ignoreInterrupts=false, state=INIT]]], 
jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19]], hasRes=true, 
isCancelled=false, isOccupied=true]
class org.apache.ignite.IgniteException: Remote job threw exception.
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$ClearTask.result(GridCacheAdapter.java:6800)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1030)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1023)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6596)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1023)
at 
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:841)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:996)
at 
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1221)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException: 
Failed to execute job due to unexpected runtime exception 
[jobId=4fe2d95b851-3bc6c31d-7339-434a-b0cd-2edda611fc19, ses=GridJobSessionImpl 
[ses=GridTaskSessionImpl 

[jira] [Comment Edited] (IGNITE-4045) .NET: Support DML API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-4045 at 11/30/16 2:21 PM:
--

* The only API change is QueryEntity.keyFields. Everything else goes through 
SqlFieldsQuery.
* See CacheQueryDmlExample


was (Author: ptupitsyn):
The only API change is QueryEntity.keyFields. Everything else goes through 
SqlFieldsQuery.

> .NET: Support DML API
> -
>
> Key: IGNITE-4045
> URL: https://issues.apache.org/jira/browse/IGNITE-4045
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
>  Labels: roadmap
> Fix For: 2.0
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.NET 
> by doing the following:
> - Implement DML API;
> - Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.NET readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready 
> (https://apacheignite.readme.io/docs/distributed-dml).



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

[jira] [Commented] (IGNITE-4206) .NET: ADO.NET Data Provider

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4206:


Is this the same as IGNITE-1975? Looks like EF can operate on any ADO.NET 
provider.

> .NET: ADO.NET Data Provider
> ---
>
> Key: IGNITE-4206
> URL: https://issues.apache.org/jira/browse/IGNITE-4206
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET, roadmap
> Fix For: 2.0
>
>
> Implement ADO.NET Data Provider that works with Ignite cache



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

[jira] [Updated] (IGNITE-4206) .NET: ADO.NET Data Provider

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4206:

Labels: .NET roadmap  (was: .NET)

> .NET: ADO.NET Data Provider
> ---
>
> Key: IGNITE-4206
> URL: https://issues.apache.org/jira/browse/IGNITE-4206
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET, roadmap
> Fix For: 2.0
>
>
> Implement ADO.NET Data Provider that works with Ignite cache



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

[jira] [Created] (IGNITE-4341) Add TeraSort example as a unit test to Ignite

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-4341:
---

 Summary: Add TeraSort example as a unit test to Ignite
 Key: IGNITE-4341
 URL: https://issues.apache.org/jira/browse/IGNITE-4341
 Project: Ignite
  Issue Type: Test
  Components: hadoop
Affects Versions: 1.7
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
 Fix For: 1.8


Add canonical TeraSort example as a unit test. 



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

[jira] [Commented] (IGNITE-4045) .NET: Support DML API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4045:


The only API change is QueryEntity.keyFields. Everything else goes through 
SqlFieldsQuery.

> .NET: Support DML API
> -
>
> Key: IGNITE-4045
> URL: https://issues.apache.org/jira/browse/IGNITE-4045
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
>  Labels: roadmap
> Fix For: 2.0
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.NET 
> by doing the following:
> - Implement DML API;
> - Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.NET readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready 
> (https://apacheignite.readme.io/docs/distributed-dml).



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

[jira] [Updated] (IGNITE-4045) .NET: Support DML API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4045:
---
Description: 
Ignite's Java component will provide support for DML soon (IGNITE-2294). At she 
same time DML will be supported at the level of ODBC and JDBC drivers.

As the next step we should include the similar functionality into Ignite.NET by 
doing the following:
- Implement DML API;
- Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and adding 
UPDATE and DELETE operation examples.
- Add documentation to Ignite.NET readme.io covering the feature. Most like 
most of the content can be take from the general documentation when this ticket 
IGNITE-4018 is ready (https://apacheignite.readme.io/docs/distributed-dml).

  was:
Ignite's Java component will provide support for DML soon (IGNITE-2294). At she 
same time DML will be supported at the level of ODBC and JDBC drivers.

As the next step we should include the similar functionality into Ignite.NET by 
doing the following:
- Implement DML API;
- Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and adding 
UPDATE and DELETE operation examples.
- Add documentation to Ignite.NET readme.io covering the feature. Most like 
most of the content can be take from the general documentation when this ticket 
IGNITE-4018 is ready.


> .NET: Support DML API
> -
>
> Key: IGNITE-4045
> URL: https://issues.apache.org/jira/browse/IGNITE-4045
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
>  Labels: roadmap
> Fix For: 2.0
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.NET 
> by doing the following:
> - Implement DML API;
> - Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.NET readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready 
> (https://apacheignite.readme.io/docs/distributed-dml).



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

[jira] [Updated] (IGNITE-1969) .NET: Optimize PlatformCache "loadCache" and "readScanQuery" methods

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1969:
---
Summary: .NET: Optimize PlatformCache "loadCache" and "readScanQuery" 
methods  (was: .NET: Optimize PlatformCache "loadCache" and "readScanQuery" 
methods.)

> .NET: Optimize PlatformCache "loadCache" and "readScanQuery" methods
> 
>
> Key: IGNITE-1969
> URL: https://issues.apache.org/jira/browse/IGNITE-1969
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Earlier we have an optimization when we passed pointer to .Net object along 
> with its serialized form to avoid deserialization for node-local scenarios. 
> But then we revealed leaks in implementation and disabled this opto.
> As as result we always pass 0 to corresponding native methods (see loadCache0 
> and readScanQuery). 
> We need either re-apply this opto correctly, or refactor native methods and 
> forget about.



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

[jira] [Updated] (IGNITE-1969) .NET: Optimize PlatformCache "loadCache" and "readScanQuery" methods

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1969:
---
Issue Type: Improvement  (was: Task)

> .NET: Optimize PlatformCache "loadCache" and "readScanQuery" methods
> 
>
> Key: IGNITE-1969
> URL: https://issues.apache.org/jira/browse/IGNITE-1969
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Earlier we have an optimization when we passed pointer to .Net object along 
> with its serialized form to avoid deserialization for node-local scenarios. 
> But then we revealed leaks in implementation and disabled this opto.
> As as result we always pass 0 to corresponding native methods (see loadCache0 
> and readScanQuery). 
> We need either re-apply this opto correctly, or refactor native methods and 
> forget about.



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

[jira] [Updated] (IGNITE-1427) .NET: Services - add support for non-deserializable AffinityKey

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1427:
---
Summary: .NET: Services - add support for non-deserializable AffinityKey  
(was: .Net: Services - add support for non-deserializable AffinityKey.)

> .NET: Services - add support for non-deserializable AffinityKey
> ---
>
> Key: IGNITE-1427
> URL: https://issues.apache.org/jira/browse/IGNITE-1427
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Currently if affinity key cannot be marshalled for some reason, it will break 
> not only affected service descriptor, but all services API.
> We should catch marshalling exceptions and pass it to .Net in a wrapped form. 
> These exception must be thrown only if user is trying to access problematic 
> key explicitly.



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

[jira] [Updated] (IGNITE-1421) .NET: Optimize writes of ultra-dense structures

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1421:
---
Issue Type: Improvement  (was: Task)

> .NET: Optimize writes of ultra-dense structures
> ---
>
> Key: IGNITE-1421
> URL: https://issues.apache.org/jira/browse/IGNITE-1421
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
> Fix For: 2.0
>
>
> There is a case when we can dramatically increase marshal/unmarshal 
> performance:
> 1) Type is a structure;
> 2) It contains only integer/float/double primitive types with well-defined;
> memory layout which is consistent with our serialization protocol;
> 3) We are sure that there are no gaps in it's memory layout.
> 4) User writes it as "marshal-aware" and fields write order is consistent 
> with memory layout.
> In this case we can copy the whole structure into our stream with a single 
> memcpy() operation. And we can read it from the stream as easy as [pointer 
> dereference + position shift] (provided that target is on the stack).
> We should also disable handles for structs, since it does not make sense.



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

[jira] [Updated] (IGNITE-1427) .NET: Services - add support for non-deserializable AffinityKey

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1427:
---
Issue Type: Improvement  (was: Task)

> .NET: Services - add support for non-deserializable AffinityKey
> ---
>
> Key: IGNITE-1427
> URL: https://issues.apache.org/jira/browse/IGNITE-1427
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Currently if affinity key cannot be marshalled for some reason, it will break 
> not only affected service descriptor, but all services API.
> We should catch marshalling exceptions and pass it to .Net in a wrapped form. 
> These exception must be thrown only if user is trying to access problematic 
> key explicitly.



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

[jira] [Updated] (IGNITE-2977) .NET: Implement generic ability to invoke Java code from non-Java platforms

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2977:
---
Issue Type: New Feature  (was: Task)

> .NET: Implement generic ability to invoke Java code from non-Java platforms
> ---
>
> Key: IGNITE-2977
> URL: https://issues.apache.org/jira/browse/IGNITE-2977
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>
> *Problem*
> Sometimes user could have mixed cluster when some nodes are running Java and 
> some nodes running in platform mode. Obviously, in such deployments it is 
> impossible to invoke non-Java code on Java nodes.
> It appears to be a serious limitation for users. For example, if cache nodes 
> are Java-only, it is impossible to set remote filter from .NET.
> Known problematic places:
> - Remote filter in continuous query
> - Compute API
> - Scan Queries
> - Cache.invokes
> - "load cache" with non-null predicate
> - services
> - messaging remote listener
> - events remote query
> *Proposed solution*
> 1) Define two new types:
> {{JavaObject}} - encoded Java object; identified by a fully-qualified class 
> name and a map of properties.
> {{JavaObjectFactory}} - factory object for more complex cases when some 
> additional logic on Java side is required. Factory must support injections.
> 2) Implement corresponding wrappers in .NET and ensure they are unwrapped 
> correctly.
> 3) Support individual features from the list above.



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

[jira] [Updated] (IGNITE-1429) .NET: Optimize stream receiver so that it is created only once on remote node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1429:
---
Summary: .NET: Optimize stream receiver so that it is created only once on 
remote node  (was: .Net: Optimize stream receiver so that it is created only 
once on remote node.)

> .NET: Optimize stream receiver so that it is created only once on remote node
> -
>
> Key: IGNITE-1429
> URL: https://issues.apache.org/jira/browse/IGNITE-1429
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> Looks like we can employ PhantomReference in Java for this.



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

[jira] [Updated] (IGNITE-1421) .NET: Optimize writes of ultra-dense structures

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1421:
---
Summary: .NET: Optimize writes of ultra-dense structures  (was: .Net: 
Optimize writes of ultra-dense structures.)

> .NET: Optimize writes of ultra-dense structures
> ---
>
> Key: IGNITE-1421
> URL: https://issues.apache.org/jira/browse/IGNITE-1421
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
> Fix For: 2.0
>
>
> There is a case when we can dramatically increase marshal/unmarshal 
> performance:
> 1) Type is a structure;
> 2) It contains only integer/float/double primitive types with well-defined;
> memory layout which is consistent with our serialization protocol;
> 3) We are sure that there are no gaps in it's memory layout.
> 4) User writes it as "marshal-aware" and fields write order is consistent 
> with memory layout.
> In this case we can copy the whole structure into our stream with a single 
> memcpy() operation. And we can read it from the stream as easy as [pointer 
> dereference + position shift] (provided that target is on the stack).
> We should also disable handles for structs, since it does not make sense.



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

[jira] [Updated] (IGNITE-2122) .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2122:
---
Issue Type: Improvement  (was: Task)

> .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods
> ---
>
> Key: IGNITE-2122
> URL: https://issues.apache.org/jira/browse/IGNITE-2122
> Project: Ignite
>  Issue Type: Improvement
>  Components: general, platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>




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

[jira] [Updated] (IGNITE-1432) .Net: Fix InteropCacheEntryProcessor performance on remote nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1432:
---
Issue Type: Improvement  (was: Task)

> .Net: Fix InteropCacheEntryProcessor performance on remote nodes
> 
>
> Key: IGNITE-1432
> URL: https://issues.apache.org/jira/browse/IGNITE-1432
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> Considerations:
> 1) Invoke with single key is expected to be called only once, so no changes 
> is needed here - deploy and execute in a single JNI call.
> 2) If there are several keys, there is a high chance (but still not 100% due 
> to partitioning) that processor will be called multiple times.
> Proposed solution:
> 1) Check amout of keys.
> 2) If cnt == 1, no changes to current logic.
> 3) If cnt > 1, first deploy (JNI call), then execute (JNI call). Processor 
> entry must be put into weak-map located somewhere inside the interop 
> processor. Interop processor must constantly listen for corresponding 
> reference queue and release .Net entries as soon as processor is weakly 
> reacheable.



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

[jira] [Updated] (IGNITE-1429) .NET: Optimize stream receiver so that it is created only once on remote node

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1429:
---
Issue Type: Improvement  (was: Task)

> .NET: Optimize stream receiver so that it is created only once on remote node
> -
>
> Key: IGNITE-1429
> URL: https://issues.apache.org/jira/browse/IGNITE-1429
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> Looks like we can employ PhantomReference in Java for this.



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

[jira] [Updated] (IGNITE-2122) .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2122:
---
Summary: .NET: Add generic Read/WriteCollection and Read/WriteDictionary 
methods  (was: .NET: Add generic Read/WriteCollection and Read/WriteDictionary 
methods.)

> .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods
> ---
>
> Key: IGNITE-2122
> URL: https://issues.apache.org/jira/browse/IGNITE-2122
> Project: Ignite
>  Issue Type: Task
>  Components: general, platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>




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

[jira] [Updated] (IGNITE-1432) .NET: Fix InteropCacheEntryProcessor performance on remote nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1432:
---
Summary: .NET: Fix InteropCacheEntryProcessor performance on remote nodes  
(was: .Net: Fix InteropCacheEntryProcessor performance on remote nodes)

> .NET: Fix InteropCacheEntryProcessor performance on remote nodes
> 
>
> Key: IGNITE-1432
> URL: https://issues.apache.org/jira/browse/IGNITE-1432
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> Considerations:
> 1) Invoke with single key is expected to be called only once, so no changes 
> is needed here - deploy and execute in a single JNI call.
> 2) If there are several keys, there is a high chance (but still not 100% due 
> to partitioning) that processor will be called multiple times.
> Proposed solution:
> 1) Check amout of keys.
> 2) If cnt == 1, no changes to current logic.
> 3) If cnt > 1, first deploy (JNI call), then execute (JNI call). Processor 
> entry must be put into weak-map located somewhere inside the interop 
> processor. Interop processor must constantly listen for corresponding 
> reference queue and release .Net entries as soon as processor is weakly 
> reacheable.



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

[jira] [Updated] (IGNITE-1422) .NET: Marshalling can be optimized for fixed-length objects

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1422:
---
Summary: .NET: Marshalling can be optimized for fixed-length objects  (was: 
.Net: Marshalling can be optimized for fixed-length objects.)

> .NET: Marshalling can be optimized for fixed-length objects
> ---
>
> Key: IGNITE-1422
> URL: https://issues.apache.org/jira/browse/IGNITE-1422
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Sometimes we can guess user object length in advance:
> 1) Strict rule: it is "reflective" and contains only fixed-length fields.
> 2) Speculative rule: It is "marshal aware", contains only fixed-length fields 
> and there is only one metadata "path".
> In these cases we can do the following:
> 1) No tracking of length and raw offset.
> 2) Header can be written as one memcpy() rather than as multiple 
> int/byte/bool writes.
> We need to have a fallback strategy for a cases when new metadata path 
> appears or user write raw data. It is very easy: if expected and actual 
> lengths differ at the end, set proper values.



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

[jira] [Updated] (IGNITE-1422) .Net: Marshalling can be optimized for fixed-length objects.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1422:
---
Issue Type: Improvement  (was: Task)

> .Net: Marshalling can be optimized for fixed-length objects.
> 
>
> Key: IGNITE-1422
> URL: https://issues.apache.org/jira/browse/IGNITE-1422
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Sometimes we can guess user object length in advance:
> 1) Strict rule: it is "reflective" and contains only fixed-length fields.
> 2) Speculative rule: It is "marshal aware", contains only fixed-length fields 
> and there is only one metadata "path".
> In these cases we can do the following:
> 1) No tracking of length and raw offset.
> 2) Header can be written as one memcpy() rather than as multiple 
> int/byte/bool writes.
> We need to have a fallback strategy for a cases when new metadata path 
> appears or user write raw data. It is very easy: if expected and actual 
> lengths differ at the end, set proper values.



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

[jira] [Updated] (IGNITE-1412) .NET: Pass local entry processor pointer to Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1412:
---
Issue Type: Improvement  (was: Task)

> .NET: Pass local entry processor pointer to Java
> 
>
> Key: IGNITE-1412
> URL: https://issues.apache.org/jira/browse/IGNITE-1412
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>
> Currently we always serialize .Net entry processor and pass only serialized 
> bytes to Java. 
> If processor is to be executed locally, then we pass the same bytes back and 
> deserialize them again. 
> Instead, we can do the following:
> 1) Serialize entry processor.
> 2) Allocate handle for it.
> 3) Pass bytes and handle to Java.
> 4) In case of local execution, just return back the handle.
> 5) Once execution is finished, handle can be safely released in "finally" 
> block.
> This can be easily implemented only for synchronous entry processing. 
> For async mode there is no try/finally. We could release the handle during 
> feature completion, but the problem is that there is no guarantee tha user 
> will ever request this feature.



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

[jira] [Updated] (IGNITE-1975) .NET: Ignite Entity Framework Data Provider

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1975:
---
Issue Type: New Feature  (was: Task)

> .NET: Ignite Entity Framework Data Provider
> ---
>
> Key: IGNITE-1975
> URL: https://issues.apache.org/jira/browse/IGNITE-1975
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Implement Entity Framework Data Provider for Ignite:
> https://msdn.microsoft.com/en-us/library/ee789835(v=vs.100).aspx



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

[jira] [Updated] (IGNITE-1654) .NET: Ensure consistent "keepBinary" behavior.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1654:
---
Summary: .NET: Ensure consistent "keepBinary" behavior.  (was: .Net: Ensure 
consistent "keepBinary" behavior.)

> .NET: Ensure consistent "keepBinary" behavior.
> --
>
> Key: IGNITE-1654
> URL: https://issues.apache.org/jira/browse/IGNITE-1654
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> We need to ensure that "keep portable" concept is
> a) Consistent;
> b) Exists for all logical units where it is necessary.
> Lets split "keep portable" behavior in two scenarios:
> 1) Client mode. This is when client (caller) operates on portable objects. 
> Example: ICache.Get(...);
> 2) Server mode. This is when some server side object (caller) operates on 
> portable objects. Example: a remote service which should not deserialize 
> passed arguments and operate on portables instead.
> Looks like both cases can be handled using the same "keep portable" flag on 
> related logical unit.
> Logical units affected:
> 1) Compute - at the very least closures can be executed in this mode;
> 2) Cache;
> 3) Data streamer;
> 4) Data structures: atomic stamped, atmoc reference;
> 5) Cache events;
> 6) Messages;
> 7) Services.
> Probably we should introduce a kind of "IKeepPortableEnabled" (or so) 
> interface, which will have a method "T WithKeepPortable()". This way users 
> will be able to easily understand that "keep portable" semantics is 
> applicable.
> Lets split it into several children tickets if necessary.



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

[jira] [Updated] (IGNITE-1654) .Net: Ensure consistent "keepBinary" behavior.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1654:
---
Summary: .Net: Ensure consistent "keepBinary" behavior.  (was: .Net: Ensure 
consistent "keepPortable" behavior.)

> .Net: Ensure consistent "keepBinary" behavior.
> --
>
> Key: IGNITE-1654
> URL: https://issues.apache.org/jira/browse/IGNITE-1654
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> We need to ensure that "keep portable" concept is
> a) Consistent;
> b) Exists for all logical units where it is necessary.
> Lets split "keep portable" behavior in two scenarios:
> 1) Client mode. This is when client (caller) operates on portable objects. 
> Example: ICache.Get(...);
> 2) Server mode. This is when some server side object (caller) operates on 
> portable objects. Example: a remote service which should not deserialize 
> passed arguments and operate on portables instead.
> Looks like both cases can be handled using the same "keep portable" flag on 
> related logical unit.
> Logical units affected:
> 1) Compute - at the very least closures can be executed in this mode;
> 2) Cache;
> 3) Data streamer;
> 4) Data structures: atomic stamped, atmoc reference;
> 5) Cache events;
> 6) Messages;
> 7) Services.
> Probably we should introduce a kind of "IKeepPortableEnabled" (or so) 
> interface, which will have a method "T WithKeepPortable()". This way users 
> will be able to easily understand that "keep portable" semantics is 
> applicable.
> Lets split it into several children tickets if necessary.



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

[jira] [Updated] (IGNITE-1654) .NET: Ensure consistent "keepBinary" behavior

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1654:
---
Summary: .NET: Ensure consistent "keepBinary" behavior  (was: .NET: Ensure 
consistent "keepBinary" behavior.)

> .NET: Ensure consistent "keepBinary" behavior
> -
>
> Key: IGNITE-1654
> URL: https://issues.apache.org/jira/browse/IGNITE-1654
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> We need to ensure that "keep portable" concept is
> a) Consistent;
> b) Exists for all logical units where it is necessary.
> Lets split "keep portable" behavior in two scenarios:
> 1) Client mode. This is when client (caller) operates on portable objects. 
> Example: ICache.Get(...);
> 2) Server mode. This is when some server side object (caller) operates on 
> portable objects. Example: a remote service which should not deserialize 
> passed arguments and operate on portables instead.
> Looks like both cases can be handled using the same "keep portable" flag on 
> related logical unit.
> Logical units affected:
> 1) Compute - at the very least closures can be executed in this mode;
> 2) Cache;
> 3) Data streamer;
> 4) Data structures: atomic stamped, atmoc reference;
> 5) Cache events;
> 6) Messages;
> 7) Services.
> Probably we should introduce a kind of "IKeepPortableEnabled" (or so) 
> interface, which will have a method "T WithKeepPortable()". This way users 
> will be able to easily understand that "keep portable" semantics is 
> applicable.
> Lets split it into several children tickets if necessary.



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

[jira] [Updated] (IGNITE-1654) .Net: Ensure consistent "keepBinary" behavior.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1654:
---
Issue Type: Improvement  (was: Task)

> .Net: Ensure consistent "keepBinary" behavior.
> --
>
> Key: IGNITE-1654
> URL: https://issues.apache.org/jira/browse/IGNITE-1654
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> We need to ensure that "keep portable" concept is
> a) Consistent;
> b) Exists for all logical units where it is necessary.
> Lets split "keep portable" behavior in two scenarios:
> 1) Client mode. This is when client (caller) operates on portable objects. 
> Example: ICache.Get(...);
> 2) Server mode. This is when some server side object (caller) operates on 
> portable objects. Example: a remote service which should not deserialize 
> passed arguments and operate on portables instead.
> Looks like both cases can be handled using the same "keep portable" flag on 
> related logical unit.
> Logical units affected:
> 1) Compute - at the very least closures can be executed in this mode;
> 2) Cache;
> 3) Data streamer;
> 4) Data structures: atomic stamped, atmoc reference;
> 5) Cache events;
> 6) Messages;
> 7) Services.
> Probably we should introduce a kind of "IKeepPortableEnabled" (or so) 
> interface, which will have a method "T WithKeepPortable()". This way users 
> will be able to easily understand that "keep portable" semantics is 
> applicable.
> Lets split it into several children tickets if necessary.



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

[jira] [Updated] (IGNITE-2826) .NET: Write DataContract types as binary

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2826:
---
Issue Type: New Feature  (was: Task)

> .NET: Write DataContract types as binary
> 
>
> Key: IGNITE-2826
> URL: https://issues.apache.org/jira/browse/IGNITE-2826
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Types marked with [DataContract] attribute should be written in binary 
> format, respecting [DataMember] and other related attributes, so that 
> existing user types can be used in Ignite without any changes.



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

[jira] [Updated] (IGNITE-2827) .NET: Write XmlSerializer types as binary

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2827:
---
Issue Type: Improvement  (was: Task)

> .NET: Write XmlSerializer types as binary
> -
>
> Key: IGNITE-2827
> URL: https://issues.apache.org/jira/browse/IGNITE-2827
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Types intended to be serialized with XmlSerializer can be identified by 
> [XmlRoot] attribute, or one of the [XmlElement], [XmlAttribute], etc 
> attributes on type members.
> We should write such types using Ignite binary format, and respect attributes 
> where applicable.



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

[jira] [Updated] (IGNITE-3576) .NET: Implement distributed data structures.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3576:
---
Issue Type: New Feature  (was: Task)

> .NET: Implement distributed data structures.
> 
>
> Key: IGNITE-3576
> URL: https://issues.apache.org/jira/browse/IGNITE-3576
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>
> Umbrella ticket to host data structures efforts.



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

[jira] [Updated] (IGNITE-3576) .NET: Implement distributed data structures

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3576:
---
Summary: .NET: Implement distributed data structures  (was: .NET: Implement 
distributed data structures.)

> .NET: Implement distributed data structures
> ---
>
> Key: IGNITE-3576
> URL: https://issues.apache.org/jira/browse/IGNITE-3576
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>
> Umbrella ticket to host data structures efforts.



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

[jira] [Updated] (IGNITE-1410) .NET: Implement IEvents.RecordLocal

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1410:
---
Issue Type: Improvement  (was: Task)

> .NET: Implement IEvents.RecordLocal
> ---
>
> Key: IGNITE-1410
> URL: https://issues.apache.org/jira/browse/IGNITE-1410
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>




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

[jira] [Updated] (IGNITE-1415) .NET: Optimize handle registry

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1415:
---
Summary: .NET: Optimize handle registry  (was: .Net: Optimize handle 
registry.)

> .NET: Optimize handle registry
> --
>
> Key: IGNITE-1415
> URL: https://issues.apache.org/jira/browse/IGNITE-1415
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> The main problem with handle registry is CAS on a single shared variable. 
> This could result in a very bad performance under contention. 
> Several techniques can be applied here:
> 1) Stripes. Assign some ID to a thread and then use it to pick correct stripe 
> for the thread. Be careful with false-sharing effects as stripes can be 
> located very close to each other.
> 2) Cleanup with relaxed membars. When we are to remove the handle, no need 
> for full HB semantics. We are ok if subsequent calls to the same handle will 
> see not-killed object for a while.



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

[jira] [Created] (IGNITE-4340) Implicitly cast new column values to expected types on SQL UPDATE

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4340:
---

 Summary: Implicitly cast new column values to expected types on 
SQL UPDATE
 Key: IGNITE-4340
 URL: https://issues.apache.org/jira/browse/IGNITE-4340
 Project: Ignite
  Issue Type: Improvement
  Components: SQL
Affects Versions: 1.8
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.8


When the following query is run,

{code:sql}
update AllTypes set longCol = 1 where _key = ?
{code}

it fails with exception

{noformat}
Suppressed: java.lang.ClassCastException: java.lang.Integer cannot be cast to 
java.lang.Long
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$RowDescriptor.wrap(IgniteH2Indexing.java:2960)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2AbstractKeyValueRow.getValue(GridH2AbstractKeyValueRow.java:316)
at 
org.h2.index.BaseIndex.compareRows(BaseIndex.java:294)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:103)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex$2.compare(GridH2TreeIndex.java:95)
at 
java.util.concurrent.ConcurrentSkipListMap$ComparableUsingComparator.compareTo(ConcurrentSkipListMap.java:647)
at 
java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:727)
at 
java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:850)
at 
java.util.concurrent.ConcurrentSkipListMap.put(ConcurrentSkipListMap.java:1645)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2TreeIndex.put(GridH2TreeIndex.java:362)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:566)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:495)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:603)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:737)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:431)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:4019)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2458)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2385)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1787)
{noformat}

It's due to that UPDATE's SELECT part selects 1 as int, and that's what we're 
setting to field. Problem can be solved by casting SELECTed values to the types 
that columns expect.



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

[jira] [Updated] (IGNITE-2977) .NET: Implement generic ability to invoke Java code from non-Java platforms

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2977:
---
Summary: .NET: Implement generic ability to invoke Java code from non-Java 
platforms  (was: .NET: Implement generic ability to invoke Java code from 
non-Java platforms.)

> .NET: Implement generic ability to invoke Java code from non-Java platforms
> ---
>
> Key: IGNITE-2977
> URL: https://issues.apache.org/jira/browse/IGNITE-2977
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>
> *Problem*
> Sometimes user could have mixed cluster when some nodes are running Java and 
> some nodes running in platform mode. Obviously, in such deployments it is 
> impossible to invoke non-Java code on Java nodes.
> It appears to be a serious limitation for users. For example, if cache nodes 
> are Java-only, it is impossible to set remote filter from .NET.
> Known problematic places:
> - Remote filter in continuous query
> - Compute API
> - Scan Queries
> - Cache.invokes
> - "load cache" with non-null predicate
> - services
> - messaging remote listener
> - events remote query
> *Proposed solution*
> 1) Define two new types:
> {{JavaObject}} - encoded Java object; identified by a fully-qualified class 
> name and a map of properties.
> {{JavaObjectFactory}} - factory object for more complex cases when some 
> additional logic on Java side is required. Factory must support injections.
> 2) Implement corresponding wrappers in .NET and ensure they are unwrapped 
> correctly.
> 3) Support individual features from the list above.



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

[jira] [Created] (IGNITE-4339) .NET: Execute .NET code on Java-only nodes

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4339:
--

 Summary: .NET: Execute .NET code on Java-only nodes
 Key: IGNITE-4339
 URL: https://issues.apache.org/jira/browse/IGNITE-4339
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn


The idea is to encode simple predicates (query filters, event filters, etc) in 
some format which will be decoded and executed on Java nodes without the need 
for any classes and so on.

Examples of such predicates are "Compare certain field to a value and another 
field to another value".

User-facing API can operate on Expression Trees or provide some kind of a 
predicate builder with fluent syntax.



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

[jira] [Updated] (IGNITE-3430) .NET: Run Ignite transactions via standard TransactionScope API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3430:
---
Labels: .net roadmap  (was: .net)

> .NET: Run Ignite transactions via standard TransactionScope API
> ---
>
> Key: IGNITE-3430
> URL: https://issues.apache.org/jira/browse/IGNITE-3430
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 2.0
>
>
> Automatically enlist Ignite operations in current transaction scope when 
> applicable (when cache is transactional).
> https://msdn.microsoft.com/en-us/library/system.transactions.transactionscope(v=vs.110).aspx



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

[jira] [Resolved] (IGNITE-1352) Platforms: move cpp and .Net examples to Ignite

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-1352.

Resolution: Fixed
  Assignee: Denis Magda

> Platforms: move cpp and .Net examples to Ignite
> ---
>
> Key: IGNITE-1352
> URL: https://issues.apache.org/jira/browse/IGNITE-1352
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>
> Move the platform examples to Ignite.
> Portable API examples have already been moved and the changes should be 
> committed to the master soon. Track IGNITE-1351 status for that.
> When the platform examples are moved make sure that 
> {{CacheClientPortableCrossPlatformExample}} works as expected.



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

[jira] [Updated] (IGNITE-3568) .NET: Start JVM externally

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3568:
---
Issue Type: New Feature  (was: Task)

> .NET: Start JVM externally
> --
>
> Key: IGNITE-3568
> URL: https://issues.apache.org/jira/browse/IGNITE-3568
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net
>
> Currently we start JVM inside .NET process. This is not good for several 
> reasons:
> 1) Broken isolation - only one JVM can exist per process. This way it is 
> impossible to start two Ignite instances with different JVM options.
> 2) JVM startup is expensive, cluster connection is expensive, and process 
> must host both Java and .NET heaps. Should we have external JVM to connect 
> to, we would allow for truly thin clients, when dozens thin processes will be 
> able to work with the same client. We already see growing demand for this 
> feature,



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

[jira] [Updated] (IGNITE-2581) .NET: AtomicReference binary mode

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2581:
---
Issue Type: Improvement  (was: Task)

> .NET: AtomicReference binary mode
> -
>
> Key: IGNITE-2581
> URL: https://issues.apache.org/jira/browse/IGNITE-2581
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Work with AtomicReference in binary mode, see comments in IGNITE-1563



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

[jira] [Updated] (IGNITE-2825) .NET: Write Serializable as binary

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2825:
---
Issue Type: Improvement  (was: Task)

> .NET: Write Serializable as binary
> --
>
> Key: IGNITE-2825
> URL: https://issues.apache.org/jira/browse/IGNITE-2825
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Write [Serializable] classes in Ignite binary format. Employ the same logic 
> as .NET does with NonSerializedAttribute and ISerializable interface.



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

[jira] [Updated] (IGNITE-3255) .NET: Script execution

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3255:
---
Issue Type: New Feature  (was: Task)

> .NET: Script execution
> --
>
> Key: IGNITE-3255
> URL: https://issues.apache.org/jira/browse/IGNITE-3255
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
> Fix For: 2.0
>
>
> Introduce an ability to execute C# scripts on remote nodes.
> This may be useful for:
> * Diagnostics and debugging on live cluster
> * Quick try-out for computations
> * Demo purposes
> This is a light-weight alternative to IGNITE-2492: we don't have to deal with 
> automatically detecting whether assembly needs to be loaded remotely, with 
> it's dependencies and AppDomain lifecycle. 
> Instead, we send a string, compile it remotely, execute in a separate 
> AppDomain and unload it.



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

[jira] [Updated] (IGNITE-3269) Benchmark driver stops working when one of servers left grid and backupcount 0

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-3269:

Priority: Critical  (was: Minor)

> Benchmark driver stops working when one of servers left grid and backupcount 0
> --
>
> Key: IGNITE-3269
> URL: https://issues.apache.org/jira/browse/IGNITE-3269
> Project: Ignite
>  Issue Type: Bug
>  Components: yardstick
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Priority: Critical
> Attachments: failed_client_log.zip
>
>
> Test config: 4 hosts with 4 clients and 1 server each, backup count = 0.
> During the test one of the servers was killed. After that one of the clients
> stopped working:
> {noformat}
> [15:31:45,248][WARN ][sys-#27%null%][TcpCommunicationSpi] Connect timed out 
> (consider increasing 'failureDetectionTimeout' configuration property) 
> [addr=fosters-216/10.20.0.216:47100, failureDetectionTimeout=1]
> [15:31:45,256][WARN ][sys-#27%null%][TcpCommunicationSpi] Failed to connect 
> to a remote node (make sure that destination node is alive and operating 
> system firewall is disabled on local and remote hosts) 
> [addrs=[fosters-216/10.20.0.216:4
> [15:31:45,276][WARN ][disco-event-worker-#52%null%][GridDiscoveryManager] 
> Node FAILED: TcpDiscoveryNode [id=f5bcc4d3-aa56-4e51-8672-e799a42990a6, 
> addrs=[10.20.0.216, 127.0.0.1], sockAddrs=[fosters-216/10.20.0.216:47500, 
> /10.20.0.216:4750
> [15:31:45,324][INFO ][disco-event-worker-#52%null%][GridDiscoveryManager] 
> Topology snapshot [ver=22, servers=3, clients=16, CPUs=64, heap=150.0GB]
> ERROR: The benchmark of random operation failed.
> Type '--help' for usage.
> Finishing main test [ts=1465252305413, date=Mon Jun 06 15:31:45 PDT 2016]
> [15:31:45] (err) Failed to execute compound future reducer: 
> GridNearTxFinishFuture 
> [futId=9c7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal 
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> Type '--help' for usage.
> [15:31:45] (err) Failed to execute compound future reducer: 
> GridNearTxFinishFuture 
> [futId=6f7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal 
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:700)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:644)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:607)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:135)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:133)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> [15:31:45] (err) Failed to execute compound future reducer: 
> GridNearTxFinishFuture 
> [futId=ff7413d2551-758034b3-0248-4d62-b901-be86d119183c, tx=GridNearTxLocal 
> [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, colocatedLocallyMa
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:700)
> at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:644)
> at 
> 

[jira] [Updated] (IGNITE-3567) .NET: AppFabric integration.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3567:
---
Issue Type: New Feature  (was: Task)

> .NET: AppFabric integration.
> 
>
> Key: IGNITE-3567
> URL: https://issues.apache.org/jira/browse/IGNITE-3567
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>




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

[jira] [Updated] (IGNITE-2295) .NET: Provide performance counters

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2295:
---
Summary: .NET: Provide performance counters  (was: .Net: Provide 
performance counters)

> .NET: Provide performance counters
> --
>
> Key: IGNITE-2295
> URL: https://issues.apache.org/jira/browse/IGNITE-2295
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Ignite.NET should be instrumented with Performance Monitor (perfmon) counters 
> for diagnostic purposes. We can use existing metrics (cluster, cache, etc) to 
> provide custom counters.



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

[jira] [Updated] (IGNITE-3566) .NET: Memcached integration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3566:
---
Summary: .NET: Memcached integration  (was: .NET: Memcached integration.)

> .NET: Memcached integration
> ---
>
> Key: IGNITE-3566
> URL: https://issues.apache.org/jira/browse/IGNITE-3566
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>




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

[jira] [Updated] (IGNITE-3566) .NET: Memcached integration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3566:
---
Issue Type: New Feature  (was: Task)

> .NET: Memcached integration
> ---
>
> Key: IGNITE-3566
> URL: https://issues.apache.org/jira/browse/IGNITE-3566
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>




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

[jira] [Updated] (IGNITE-2295) .Net: Provide performance counters

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2295:
---
Issue Type: New Feature  (was: Task)

> .Net: Provide performance counters
> --
>
> Key: IGNITE-2295
> URL: https://issues.apache.org/jira/browse/IGNITE-2295
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Ignite.NET should be instrumented with Performance Monitor (perfmon) counters 
> for diagnostic purposes. We can use existing metrics (cluster, cache, etc) to 
> provide custom counters.



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

[jira] [Updated] (IGNITE-2578) .NET: Native object comparison

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2578:
---
Issue Type: Improvement  (was: Task)

> .NET: Native object comparison
> --
>
> Key: IGNITE-2578
> URL: https://issues.apache.org/jira/browse/IGNITE-2578
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Currently all comparisons (cache key comparisons, atomic operations, etc) are 
> performed in binary form on Java side. This may not work as intended when 
> user has overridden Equals/GetHashCode. Need to investigate whether we can or 
> should do anything about this. 
> * Is it really an issue?
> * Is there a workaround?
> * Are there any user requests about this?



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

[jira] [Updated] (IGNITE-3567) .NET: AppFabric integration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3567:
---
Summary: .NET: AppFabric integration  (was: .NET: AppFabric integration.)

> .NET: AppFabric integration
> ---
>
> Key: IGNITE-3567
> URL: https://issues.apache.org/jira/browse/IGNITE-3567
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>  Labels: .net, roadmap
>




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

[jira] [Commented] (IGNITE-3269) Benchmark driver stops working when one of servers left grid and backupcount 0

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova commented on IGNITE-3269:
-

Similar case:
ignite-1.8, 80 clients and 20 servers, backup count=1:
{noformat}
[15:23:36,733][INFO ][grid-timeout-worker-#7%null%][IgniteKernal]
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=215e4b73, name=null, uptime=00:19:16:915]
^-- H/N/C [hosts=8, nodes=100, CPUs=128]
^-- CPU [cur=1.53%, avg=2%, GC=0%]
^-- Heap [used=437MB, free=57.23%, comm=1024MB]
^-- Non heap [used=44MB, free=65.29%, comm=47MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=32, qSize=0]
^-- Outbound messages queue [size=0]
[15:23:37,029][WARN ][grid-nio-worker-1-#10%null%][TcpCommunicationSpi] Failed 
to process selector key (will close): GridSelectorNioSessionImpl 
[selectorIdx=1, queueSize=0, writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 
cap=32768], r
eadBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768], 
recovery=GridNioRecoveryDescriptor [acked=46848, resendCnt=0, rcvCnt=46758, 
sentCnt=46860, reserved=true, lastAck=46752, nodeLeft=false, 
node=TcpDiscoveryNode [id=d4069148-449b
-41ee-b772-d5586265f23f, addrs=[127.0.0.1, 172.25.1.38], 
sockAddrs=[/172.25.1.38:47500, /127.0.0.1:47500], discPort=47500, order=102, 
intOrder=101, lastExchangeTime=1480508020664, loc=false, 
ver=1.8.0#20161129-sha1:d0e0eaac, isClient=fal
se], connected=true, connectCnt=1, queueLimit=5120, reserveCnt=1], 
super=GridNioSessionImpl [locAddr=/172.25.1.35:37134, 
rmtAddr=/172.25.1.38:47100, createTime=1480508073194, closeTime=0, 
bytesSent=52124554, bytesRcvd=24331807, sndSchedT
ime=1480508617009, lastSndTime=1480508617019, lastRcvTime=1480508616898, 
readsPaused=false, filterChain=FilterChain[filters=[GridNioCodecFilter 
[parser=o.a.i.i.util.nio.GridDirectParser@76ae88f4, directMode=true], 
GridConnectionBytesVeri
fyFilter], accepted=false]]
[15:23:37,030][WARN ][grid-nio-worker-1-#10%null%][TcpCommunicationSpi] Closing 
NIO session because of unhandled exception [cls=class 
o.a.i.i.util.nio.GridNioException, msg=Connection reset by peer]
[15:23:37,089][WARN ][tcp-comm-worker-#1%null%][TcpCommunicationSpi] Connect 
timed out (consider increasing 'failureDetectionTimeout' configuration 
property) [addr=/172.25.1.38:47100, failureDetectionTimeout=3]
[15:23:37,090][WARN ][tcp-comm-worker-#1%null%][TcpCommunicationSpi] Failed to 
connect to a remote node (make sure that destination node is alive and 
operating system firewall is disabled on local and remote hosts) 
[addrs=[/172.25.1.38:4
7100, /127.0.0.1:47100]]
[15:23:37] (err) Failed to execute compound future reducer: 
GridNearTxFinishFuture [futId=3204e25b851-d7870206-d4cd-4c35-a749-d1d9b5b628bc, 
tx=GridNearTxLocal [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false, 
colocatedLocallyMa
pped=false, needCheckBackup=null, hasRemoteLocks=true, thread=, mappings=IgniteTxMappingsImpl [], 
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], 
dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false, 
depEnabled=false, txState=IgniteTxStateImpl [activeCacheIds=GridLongList 
[idx=3, arr=[3716,107944136,-535738254]], txMap={IgniteTxKey 
[key=o.a.i.yardstick.cache.lo
ad.model.key.Identifier [idHash=454392180, hash=-1688540165, id=1663029, 
code=id 1663029], cacheId=3716]=IgniteTxEntry 
[key=o.a.i.yardstick.cache.load.model.key.Identifier [idHash=454392180, 
hash=-1688540165, id=1663029, code=id 1663029]
, cacheId=3716, partId=5, txKey=IgniteTxKey 
[key=o.a.i.yardstick.cache.load.model.key.Identifier [idHash=454392180, 
hash=-1688540165, id=1663029, code=id 1663029], cacheId=3716], val=[op=CREATE, 
val=o.a.i.yardstick.cache.model.Account [i
dHash=517520528, hash=216730851, balance=1663029]], prevVal=[op=CREATE, 
val=o.a.i.yardstick.cache.model.Account [idHash=517520528, hash=216730851, 
balance=1663029]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1, 
conflictEx
pireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null, filters=[], 
filtersPassed=false, filtersSet=true, entry=GridDhtDetachedCacheEntry 
[super=GridDistributedCacheEntry [super=GridCacheMapEntry 
[key=o.a.i.yardstick.cache.load.mod
el.key.Identifier [idHash=454392180, hash=-1688540165, id=1663029, code=id 
1663029], val=null, startVer=1480614477546, ver=GridCacheVersion 
[topVer=91987517, time=1480508616519, order=1480614477371, nodeOrder=1], 
hash=-1688540165, extras
=null, flags=0]]], prepared=0, locked=true, 
nodeId=5650c65d-918a-4a27-af67-14d995de536b, locMapped=false, expiryPlc=null, 
transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null, 
xidVer=GridCacheVersion [topVer=91987517, time
=1480508616520, order=1480614477545, nodeOrder=72]], IgniteTxKey 
[key=KeyCacheObjectImpl 

[jira] [Updated] (IGNITE-1683) .Net: IEvents.RemoteListen

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1683:
---
Issue Type: Improvement  (was: Task)

> .Net: IEvents.RemoteListen
> --
>
> Key: IGNITE-1683
> URL: https://issues.apache.org/jira/browse/IGNITE-1683
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.6
>Reporter: Pavel Tupitsyn
>  Labels: .net
>
> Bring back IEvents.RemoteListen as soon as it is fixed in Java.
> Currently rmtFilter is not actually a filter and semantics are unclear.



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

[jira] [Commented] (IGNITE-3964) SQL: implement support for table alias

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3964:


GitHub user AMashenkov opened a pull request:

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

IGNITE-3964: SQL: implement support for table alias

Custom table name can be set for QueryEntity.

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

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

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

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


commit 1d03c30f6254076a6fafb280678119cdd3940ced
Author: Andrey V. Mashenkov 
Date:   2016-11-29T16:44:26Z

Added table alias




> SQL: implement support for table alias
> --
>
> Key: IGNITE-3964
> URL: https://issues.apache.org/jira/browse/IGNITE-3964
> Project: Ignite
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Andrew Mashenkov
> Fix For: 2.0
>
>
> We have ability to specify aliases for columns via 
> org.apache.ignite.cache.QueryEntity#getAliases.
> But how about alias for table name? This could be useful in case of moving 
> legacy application to Ignite with a lot of SQL statements.



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

[jira] [Assigned] (IGNITE-4045) .NET: Support DML API

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4045:
--

Assignee: Pavel Tupitsyn

> .NET: Support DML API
> -
>
> Key: IGNITE-4045
> URL: https://issues.apache.org/jira/browse/IGNITE-4045
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
>  Labels: roadmap
> Fix For: 2.0
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At 
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.NET 
> by doing the following:
> - Implement DML API;
> - Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and 
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.NET readme.io covering the feature. Most like 
> most of the content can be take from the general documentation when this 
> ticket IGNITE-4018 is ready.



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

[jira] [Updated] (IGNITE-1410) .NET: Implement IEvents.RecordLocal.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1410:
---
Summary: .NET: Implement IEvents.RecordLocal.  (was: .Net: Implement 
IEvents.RecordLocal.)

> .NET: Implement IEvents.RecordLocal.
> 
>
> Key: IGNITE-1410
> URL: https://issues.apache.org/jira/browse/IGNITE-1410
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>




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

[jira] [Updated] (IGNITE-1410) .NET: Implement IEvents.RecordLocal

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-1410:
---
Summary: .NET: Implement IEvents.RecordLocal  (was: .NET: Implement 
IEvents.RecordLocal.)

> .NET: Implement IEvents.RecordLocal
> ---
>
> Key: IGNITE-1410
> URL: https://issues.apache.org/jira/browse/IGNITE-1410
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>  Labels: .net
>




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

[jira] [Updated] (IGNITE-3456) Make sure EntryProcessor is always running on a OWNING partition

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-3456:
-
Priority: Minor  (was: Major)

> Make sure EntryProcessor is always running on a OWNING partition
> 
>
> Key: IGNITE-3456
> URL: https://issues.apache.org/jira/browse/IGNITE-3456
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Anton Vinogradov
>Priority: Minor
>
> Let's say I need to maintain some sort of an aggregate function over a 
> partition. This aggregate is maintained using an entry processor, and before 
> an update this entry processor queries this local aggregate.
> If an entry processor is applied on a partition with a MOVING state, the 
> state of the local aggregate is not valid because not all data has been 
> preloaded. If entry processor is applied on an OWNING partition, the result 
> is guaranteed to be correct.
> Given that we have implemented late affinity assignment when a new node is 
> assigned primary only when rebalancing is finished, this should be already 
> maintained. We just need to add tests verifying the partition state in 
> EntryProcessor.



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

[jira] [Resolved] (IGNITE-4329) .NET: Document web deployment specifics on readme.io

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4329.

Resolution: Fixed
  Assignee: (was: Pavel Tupitsyn)

> .NET: Document web deployment specifics on readme.io 
> -
>
> Key: IGNITE-4329
> URL: https://issues.apache.org/jira/browse/IGNITE-4329
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.8
>
>
> Deploying Ignite.NET requires additional steps in regards to Libs folder. We 
> have some details on 
> https://apacheignite-net.readme.io/docs/aspnet-output-caching page, but this 
> should be documented in a more general way with better visibility.



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

[jira] [Commented] (IGNITE-4329) .NET: Document web deployment specifics on readme.io

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4329:


There is already a section in 
https://apacheignite-net.readme.io/docs/deployment#aspnet-deployment, links 
added in Troubleshooting and ASP.NET sections.

> .NET: Document web deployment specifics on readme.io 
> -
>
> Key: IGNITE-4329
> URL: https://issues.apache.org/jira/browse/IGNITE-4329
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.8
>
>
> Deploying Ignite.NET requires additional steps in regards to Libs folder. We 
> have some details on 
> https://apacheignite-net.readme.io/docs/aspnet-output-caching page, but this 
> should be documented in a more general way with better visibility.



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

[jira] [Commented] (IGNITE-4263) Hadoop: abstract out offheap/heap memory management.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4263:
--

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

> Hadoop: abstract out offheap/heap memory management.
> 
>
> Key: IGNITE-4263
> URL: https://issues.apache.org/jira/browse/IGNITE-4263
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>




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

[jira] [Resolved] (IGNITE-4328) .NET: Create readme.md

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-4328.

Resolution: Done
  Assignee: (was: Pavel Tupitsyn)

Done: https://github.com/apache/ignite/tree/master/modules/platforms/dotnet

> .NET: Create readme.md
> --
>
> Key: IGNITE-4328
> URL: https://issues.apache.org/jira/browse/IGNITE-4328
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 1.9
>
>
> Java part has both readme.txt (for local viewing) and readme.md (for nice 
> github appearance).
> .NET should have the same:
> https://github.com/apache/ignite/tree/master/modules/platforms/dotnet
> * We can also include a build status icon: 
> http://ci.ignite.apache.org/app/rest/builds/buildType:(id:IgniteTests_IgnitePlatformNet)/statusIcon
> * Other links like there: https://github.com/cake-build/cake
> * Link github sources on readme.io
> * Link .NET & C++ folders from main readme.md



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

[jira] [Updated] (IGNITE-4332) Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to remote operations

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-4332:
-
Assignee: (was: Semen Boikov)

> Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to 
> remote operations
> -
>
> Key: IGNITE-4332
> URL: https://issues.apache.org/jira/browse/IGNITE-4332
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Eduard Shangareev
> Fix For: 1.8
>
>
> Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to 
> remote operations.
> We must avoid remote operations if it is possible.



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

[jira] [Commented] (IGNITE-3945) Web console: Implement configuration of DeploymentSpi

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-3945:
---

Extended *Class deployment* section to configure of deploymentSpi.

> Web console: Implement configuration of DeploymentSpi
> -
>
> Key: IGNITE-3945
> URL: https://issues.apache.org/jira/browse/IGNITE-3945
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>




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