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

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur edited comment on IGNITE-4374 at 1/10/17 7:55 AM:
-

x64 - not optimized
[^x64_not_optimized.png]

x64 - optimized
!x64_optimized.png|thumbnail!

x32 - not optimized
!x32_not_optimized.png|thumbnail!

x32 - optimized
!x32_optimized.png|thumbnail!

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


was (Author: daradurvs):
x64 - not optimized
!x64_not_optimized.png|thumbnail!

x64 - optimized
!x64_optimized.png|thumbnail!

x32 - not optimized
!x32_not_optimized.png|thumbnail!

x32 - optimized
!x32_optimized.png|thumbnail!

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

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



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

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

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-4374:
---
Attachment: x64_optimized.png
x64_not_optimized.png
x32_optimazed.png
x32_not_optimazed.png

x64 - not optimized
!x64_not_optimized.png|thumbnail!

x64 - optimized
!x64_optimized.png|thumbnail!

x32 - not optimized
!x32_not_optimized.png|thumbnail!

x32 - optimized
!x32_optimized.png|thumbnail!

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

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



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

[jira] [Comment Edited] (IGNITE-2422) Prevent serialization of BinaryObjectBuilder

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-2422 at 1/10/17 12:53 AM:
---

Maksim, I was wrong initially. We do support serialization and deserialization 
of {{BinaryObjectBuilder}}. Having a more deep look I found our that the test 
fails due to deserialization related issue. In general, if we add the following 
two lines

{code}
org.apache.ignite.binary.BinaryObjectBuilder
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl
{code}

to {{META-INF/classnames.properties}} file then the attached tests will pass 
without issue.

The issue is that I can't update this file to the latest state automatically.
[~avinogradov], [~vozerov], I've tried to build the project from scratch but 
both {{BinaryObjectBuilder}} and {{BinaryObjectBuilderImpl}} were not added to 
the classnames.properties. Even more I've downloaded 1.8 versions and there is 
no {{META-INF/classnames.properties}} file at all. Did we break something or 
the logic has changed?


was (Author: dmagda):
Maksim, I was wrong initially. We do support serialization and deserialization 
of {{BinaryObjectBuilder}}. Having a more deep look I found our that the test 
fails due to deserialization related issue. In general, if we add the following 
two lines

{code}
org.apache.ignite.binary.BinaryObjectBuilder
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl
{code}

to {{META-INF/classnames.properties}} file than the attached tests will pass 
without issue.

The issue is that this file has to be updated to the latest state. However, 
also I see that this file no longer delivered in Ignite releases which looks 
like a broken functionality.

[~avinogradov], [~vozerov], I've tried to build the project from scratch but 
both {{BinaryObjectBuilder}} and {{BinaryObjectBuilderImpl}} were not added to 
the classnames.properties. Even more I've downloaded 1.8 versions and there is 
no {{META-INF/classnames.properties}} file at all. Did we break something or 
the logic has changed?

> Prevent serialization of BinaryObjectBuilder
> 
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
>  Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> We have to prevent serialization of the builder throwing a meaningful 
> exception.
> Run an example from attach and you will see an exception that is caused by 
> the serialization/deserialization of the builder.



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

[jira] [Commented] (IGNITE-2422) Prevent serialization of BinaryObjectBuilder

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2422:
-

Initiated a corresponding discussion on the dev list
http://apache-ignite-developers.2346864.n4.nabble.com/classnames-properties-file-is-not-updated-and-missed-in-1-8-release-td13576.html

> Prevent serialization of BinaryObjectBuilder
> 
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
>  Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> We have to prevent serialization of the builder throwing a meaningful 
> exception.
> Run an example from attach and you will see an exception that is caused by 
> the serialization/deserialization of the builder.



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

[jira] [Commented] (IGNITE-2422) Prevent serialization of BinaryObjectBuilder

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2422:
-

Maksim, I was wrong initially. We do support serialization and deserialization 
of {{BinaryObjectBuilder}}. Having a more deep look I found our that the test 
fails due to deserialization related issue. In general, if we add the following 
two lines

{code}
org.apache.ignite.binary.BinaryObjectBuilder
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl
{code}

to {{META-INF/classnames.properties}} file than the attached tests will pass 
without issue.

The issue is that this file has to be updated to the latest state. However, 
also I see that this file no longer delivered in Ignite releases which looks 
like a broken functionality.

[~avinogradov], [~vozerov], I've tried to build the project from scratch but 
both {{BinaryObjectBuilder}} and {{BinaryObjectBuilderImpl}} were not added to 
the classnames.properties. Even more I've downloaded 1.8 versions and there is 
no {{META-INF/classnames.properties}} file at all. Did we break something or 
the logic has changed?

> Prevent serialization of BinaryObjectBuilder
> 
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
>  Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> We have to prevent serialization of the builder throwing a meaningful 
> exception.
> Run an example from attach and you will see an exception that is caused by 
> the serialization/deserialization of the builder.



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4374:
-

[~daradurvs], good start, thanks! Could you paste the output results for every 
parameters that you've supported?

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



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4531:
-

[~al.psc], please take a look at this. In the meanwhile, David what do you use 
as a debug console? Do you have any ready to run test?

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



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

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

[Denis Magda (JIRA)]

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

Denis Magda edited comment on IGNITE-4530 at 1/10/17 12:21 AM:
---

[~akazlou], thanks a lot. In general, everything looks good so far. I left a 
minor note in the pull request on GitHub. Please address it.

BTW, did you use your personal AWS account for the updated API testing?

Finally, please move the ticket into "patch available" state if it's truly 
ready for a review.



was (Author: dmagda):
[~akazlou], thanks a lot. In general, everything looks good so far. I left a 
minor note in the pull request on GitHub. Please address it.

BTW, did you use your personal AWS account for the updated API testing?



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



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4530:
-

[~akazlou], thanks a lot. In general, everything looks good so far. I left a 
minor note in the pull request on GitHub. Please address it.

BTW, did you use your personal AWS account for the updated API testing?



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



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

[jira] [Commented] (IGNITE-2422) Prevent serialization of BinaryObjectBuilder

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-2422:


GitHub user dream-x opened a pull request:

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

IGNITE-2422: Prevent serialization of BinaryObjectBuilder



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

$ git pull https://github.com/dream-x/ignite ignite-2422

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

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


commit 48059532376a625421b6a2b8e0359f06f1d0d81c
Author: Max Kozlov 
Date:   2017-01-09T23:58:55Z

Add method testSerializeBinaryObjectBuilder() in 
BinaryObjectBuilderAdditionalSelfTest class.

commit 9eb4b4420b5e0fd90f8a923bb096c6ee99b9e9da
Author: Max Kozlov 
Date:   2017-01-10T00:02:56Z

Change method setField(String name, Object val0) for prevent serialization 
BinaryObjectBuilder

commit 9154c568bd2eb478998186a43298e5979fdeb78f
Author: Max Kozlov 
Date:   2017-01-10T00:05:55Z

Delete unused import.




> Prevent serialization of BinaryObjectBuilder
> 
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
>  Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> We have to prevent serialization of the builder throwing a meaningful 
> exception.
> Run an example from attach and you will see an exception that is caused by 
> the serialization/deserialization of the builder.



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

[jira] [Commented] (IGNITE-2422) Prevent serialization of BinaryObjectBuilder

[Maksim Kozlov (JIRA)]

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

Maksim Kozlov commented on IGNITE-2422:
---

[~dmagda] Implemented a little differently, please see pull request.

> Prevent serialization of BinaryObjectBuilder
> 
>
> Key: IGNITE-2422
> URL: https://issues.apache.org/jira/browse/IGNITE-2422
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
>  Labels: important
> Fix For: 2.0
>
> Attachments: ExampleNodeStartup.java
>
>
> Presently it's possible to serialize {{BinaryObjectBuilder}} but it will lead 
> to the errors at deserialization stage.
> We have to prevent serialization of the builder throwing a meaningful 
> exception.
> Run an example from attach and you will see an exception that is caused by 
> the serialization/deserialization of the builder.



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

[jira] [Commented] (IGNITE-4526) Add Spark Shared RDD examples

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-4526:
-

Manish, good start! I've left review notes and suggestion in the pull-request 
on GitHub. Let's finalize this simple example and move to more advanced covered 
in the task's description.

> Add Spark Shared RDD examples
> -
>
> Key: IGNITE-4526
> URL: https://issues.apache.org/jira/browse/IGNITE-4526
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Manish Mishra
> Fix For: 2.0
>
>
> Spark Shared RDD functionality doesn't have its own examples. We need to add 
> an example that will do the following:
> - First Spark Worker: creation of a shared RDD and filling it in with data.
> - First Spark Worker: performing some native spark transformation with the 
> RDD.
> - Second Spark Worker: connecting to the same shared RDD.
> - Second Spark Worker: execution of SQL query using Spark API and Ignite API. 
> Show that Ignite's query executes faster.
> The reason why the example should consist of two workers is to showcase one 
> of the main benefits of Ignite's RDDs - ability to share the state (RDD) amid 
> different Spark workers and processes.



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

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

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-4523:
---

I think this is a very questionable feature. We already plan support for 
sending a query to a right partition in IGNITE-4510, which should be enough. 
Don't think we need anything beyond that.

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



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

[jira] [Closed] (IGNITE-4412) .NET: NLogLoggerTest is not thread safe

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-4412.
---

> .NET: NLogLoggerTest is not thread safe
> ---
>
> Key: IGNITE-4412
> URL: https://issues.apache.org/jira/browse/IGNITE-4412
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET, newbie
> Fix For: 2.0
>
>
> NLog.Targets.MemoryTarget is not thread safe, the test can sometimes fail. 
> Replace this target with our own synchronized implementation.



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

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

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-4523:
---

Added test for quering over partition subset per primary node.

Fixing it to not fail.

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



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

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

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-4493:

Assignee: Pavel Tupitsyn  (was: Igor Sapego)

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



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

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

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4470:
-

Pavel, please merge this PR.

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



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

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

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4493:
-

Pavel, please merge this PR.


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



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

[jira] [Assigned] (IGNITE-3837) ODBC: Escape sequences: Support CONVERT function.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-3837:
--

Assignee: Sergey Kalashnikov

> ODBC: Escape sequences: Support CONVERT function.
> -
>
> Key: IGNITE-3837
> URL: https://issues.apache.org/jira/browse/IGNITE-3837
> Project: Ignite
>  Issue Type: Sub-task
>  Components: odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Sergey Kalashnikov
>  Labels: odbc
> Fix For: 2.0
>
>
> Need to implement parsing of the CONVERT function: 
> https://msdn.microsoft.com/en-us/library/ms715381(v=vs.85).aspx.
> Note the type conversion (e.g. {{SQL_VARCHAR}} -> {{VARCHAR}})



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

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

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur edited comment on IGNITE-4374 at 1/9/17 5:09 PM:


Check of "Basic JVM Configuration" added.
Options are checked:
{code}
-server
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC 
-XX:+UseTLAB 
-XX:NewSize=128m 
-XX:MaxNewSize=128m 
-XX:MaxTenuringThreshold=0 
-XX:SurvivorRatio=1024 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=60
-XX:+DisableExplicitGC
{code}
Link to the tuning article added to output.
!https://issues.apache.org/jira/secure/attachment/12846372/check-output.png|thumbnail!

If the community approves this approach I will develop checks for ON_HEAP and 
OFF_HEAP "Advanced JVM Configuration"


was (Author: daradurvs):
Check of "Basic JVM Configuration" added.
Options are checked:
{code}
-server
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC 
-XX:+UseTLAB 
-XX:NewSize=128m 
-XX:MaxNewSize=128m 
-XX:MaxTenuringThreshold=0 
-XX:SurvivorRatio=1024 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=60
-XX:+DisableExplicitGC
{code}
Link to the tuning article added to output.
!check-output.png|thumbnail!

If the community approves this approach I will develop checks for ON_HEAP and 
OFF_HEAP "Advanced JVM Configuration"

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



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

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

[Vyacheslav Daradur (JIRA)]

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

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

Check of "Basic JVM Configuration" added.
Options are checked:
{code}
-server
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC 
-XX:+UseTLAB 
-XX:NewSize=128m 
-XX:MaxNewSize=128m 
-XX:MaxTenuringThreshold=0 
-XX:SurvivorRatio=1024 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=60
-XX:+DisableExplicitGC
{code}
Link to the tuning article added to output.
!check-output.png|thumbnail!

If the community approves this approach I will develop checks for ON_HEAP and 
OFF_HEAP "Advanced JVM Configuration"

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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4374:


GitHub user daradurvs opened a pull request:

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

IGNITE-4374

Check of "Basic JVM Configuration" added.
Link to the tuning article added.
https://apacheignite.readme.io/docs/jvm-and-system-tuning

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

$ git pull https://github.com/daradurvs/ignite ignite-4374

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

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


commit 9cbce4fff70b7ac6a0b23bd8884e6c1f4bfb0f9c
Author: daradurvs 
Date:   2016-12-28T09:02:27Z

ignite-4374: add link to article about performance tuning

commit 2387f3fec5c3b82c82f1bd686704c778e0e4535d
Author: daradurvs 
Date:   2017-01-09T15:26:30Z

ignite-4374: check of Basic JVM Configuration added

commit bc193741acd368bdfcd1221e3506c347eb9739c4
Author: daradurvs 
Date:   2017-01-09T15:55:32Z

ignite-4374: rename GridPerformanceSuggestions to ConfigurationSuggestions

commit b22aa1c4e2ffc374e4bb084217c549aba7e4eb7f
Author: daradurvs 
Date:   2017-01-09T16:33:15Z

ignite-4374: JvmPerformanceSuggestions simplified




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



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4367:


MessagingTest.TestRemoteListen is also flaky.

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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3430:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-3430 .NET: Run Ignite transactions via standard TransactionScope API



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

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

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

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


commit 813092c9c000ba97c233de3c887d0aacd68de953
Author: Pavel Tupitsyn 
Date:   2017-01-09T15:22:23Z

IGNITE-3430 .NET: Run Ignite transactions via standard TransactionScope API




> .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
>Assignee: 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
> https://msdn.microsoft.com/en-us/library/ee818754(v=vs.110).aspx
> This boils down to implementing {{IEnlistmentNotification}} and calling 
> {{Transaction.Current.Enlist}} when doing transactional operations.
> Later we may want to implement {{ISinglePhaseNotification}} which is an 
> optimization.



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

[jira] [Commented] (IGNITE-4372) Set up code coverage reports

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova commented on IGNITE-4372:
-

- Aggregated report was setup using experimental test suite. Solution to 
enable/disable code coverage in Run-All was found.

> Set up code coverage reports
> 
>
> Key: IGNITE-4372
> URL: https://issues.apache.org/jira/browse/IGNITE-4372
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ksenia Rybakova
>Assignee: Ksenia Rybakova
>




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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4532:
---
Labels: newbie platforms  (was: platforms)

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



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

[jira] [Comment Edited] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-3625 at 1/9/17 2:25 PM:
--

- *1-5* - fixed;
- *6, 7* - You are right. Caches configuration is removed from 
{{default-config.xml}} and {{JettyRestProcessorAbstractSelfTest}} but I thing 
we should leave caches configurations at the {{example-igfs.xml}} to provide 
example of configuration.
- *8* - The patch doesn't contain changes at the 
{{VisorCacheQueryDetailMetricsCollectorTask}} and 
{{VisorNodeDataCollectorJob}}. Sorry, I forgot to merge the branch with last 
changes on ignite-2.0. Re-merged.
- *9, 10, 11* - fixed.

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


was (Author: tledkov-gridgain):
- *1-5* - fixed;
- *6, 7* - You are right. Caches configuration is removed from 
{{default-config.xml}} and {{JettyRestProcessorAbstractSelfTest}} but I thing 
we should leave caches configurations at the {{example-igfs.xml}} to provide 
example of configuration.
- *8* - The patch doesn't contain changes at the 
{{VisorCacheQueryDetailMetricsCollectorTask}} and 
{{VisorNodeDataCollectorJob}}. Sorry, I forgot to merge the branch with last 
changes on ignite-2.0. Re-merged.
- *9, 10, 11* - fixed.

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



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

[jira] [Commented] (IGNITE-3867) ScanQuery ignores pageSize propertry

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3867:


GitHub user AMashenkov opened a pull request:

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

IGNITE-3867: ScanQuery ignores pageSize property

Fixed.
Test added.

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

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

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

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


commit b6d6e30d73ef9d9950da0448412d3b02ba96d224
Author: Andrey V. Mashenkov 
Date:   2017-01-09T14:13:07Z

Fixed




> ScanQuery ignores pageSize propertry
> 
>
> Key: IGNITE-3867
> URL: https://issues.apache.org/jira/browse/IGNITE-3867
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Andrew Mashenkov
>
> See 
> {{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
>  IgniteClosure, ClusterGroup)}} method. 
> In this place we loose page size which set by user and use default value:
> {{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(), 
> isKeepBinary)}}



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

[jira] [Commented] (IGNITE-3867) ScanQuery ignores pageSize propertry

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3867:


Github user AMashenkov closed the pull request at:

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


> ScanQuery ignores pageSize propertry
> 
>
> Key: IGNITE-3867
> URL: https://issues.apache.org/jira/browse/IGNITE-3867
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Andrew Mashenkov
>
> See 
> {{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery,
>  IgniteClosure, ClusterGroup)}} method. 
> In this place we loose page size which set by user and use default value:
> {{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(), 
> isKeepBinary)}}



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

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

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Description: 
After putting a java class Operation with

{code}
@QuerySqlField(name = "operationNumber", index = true)
private String mOperationNumber;

@QuerySqlField(index = true)
private String mUuid;
{code}

in the cache. Via debug console I can see the following fields:

_val:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, ...]

and a column named: OPERATIONNUMBER with value 0010.

The query
{code}
String updateQueryString = "UPDATE Operation set operationNumber =  ? WHERE 
mUuid =  ?";
SqlFieldsQuery updateQuery = new SqlFieldsQuery(updateQueryString 
).setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
cache.query(updateQuery);
{code}

results in:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, operationNumber=SCHEDULED, ...]

and a column named: OPERATIONNUMBER with value 0010.

The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



  was:
After putting a java class Operation with

{code}
@QuerySqlField(name = "operationNumber", index = true)
private String mOperationNumber;

@QuerySqlField(index = true)
private String mUuid;
{code}

in the cache. Via debug console I can see the following fields:

_val:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, ...]

and a column named: OPERATIONNUMBER with value 0010.

The query
{code}
SqlFieldsQuery updateQuery = new SqlFieldsQuery("UPDATE Operation set 
operationNumber =  ? WHERE mUuid =  
?").setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
cache.query(updateQuery);
{code}

results in:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, operationNumber=SCHEDULED, ...]

and a column named: OPERATIONNUMBER with value 0010.

The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!




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



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

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

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Description: 
After putting a java class Operation with

{code}
@QuerySqlField(name = "operationNumber", index = true)
private String mOperationNumber;

@QuerySqlField(index = true)
private String mUuid;
{code}

in the cache. Via debug console I can see the following fields:

_val:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, ...]

and a column named: OPERATIONNUMBER with value 0010.

The query
{code}
SqlFieldsQuery updateQuery = new SqlFieldsQuery("UPDATE Operation set 
operationNumber =  ? WHERE mUuid =  
?").setArgs("SCHEDULED","FF42930B6D3242B5A0B9D631E017027E");
cache.query(updateQuery);
{code}

results in:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, operationNumber=SCHEDULED, ...]

and a column named: OPERATIONNUMBER with value 0010.

The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



  was:
After putting a java class Operation with

{code}
@QuerySqlField(name = "operationNumber", index = true)
private String mOperationNumber;

@QuerySqlField(index = true)
private String mUuid;
{code}

in the cache. Via debug console I can see the following fields:

_val:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, ...]

and a column named: OPERATIONNUMBER with value 0010.

When I use 
{code}
UPDATE Operation set operationNumber =  ? WHERE mUuid =  ? 
{code}

with the arguments

[SCHEDULED, FF42930B6D3242B5A0B9D631E017027E]

I can see the following values:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, operationNumber=SCHEDULED, ...]

and a column named: OPERATIONNUMBER with value 0010.

The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!




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



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

[jira] [Assigned] (IGNITE-4499) TcpDiscoverySpi is not reliable in some network split scenarios.

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-4499:
---

Assignee: Andrey Gura

> TcpDiscoverySpi is not reliable in some network split scenarios.
> 
>
> Key: IGNITE-4499
> URL: https://issues.apache.org/jira/browse/IGNITE-4499
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Andrey Gura
> Fix For: 2.0
>
>
> Where is a possible caveat in current discovery implementation using ring of 
> nodes.
> Imagine grid consisting of nodes A B C D
> Let them form the ring:
> A-B-C-D-A
> If network connectivity issues will arise between nodes A-C and B-D
> discovery spi will never know it and will continue to assume the topology is 
> valid. 
> On other side, TcpCommunicationSpi will try to run transaction on this 
> topology and never will succeed.
> We must drop nodes from topology on communication spi errors.



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

[jira] [Commented] (IGNITE-3625) IGFS: Use common naming for IGFS meta and data caches.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3625:
--

- *1-5* - fixed;
- *6, 7* - You are right. Caches configuration is removed from 
{{default-config.xml}} and {{JettyRestProcessorAbstractSelfTest}} but I thing 
we should leave caches configurations at the {{example-igfs.xml}} to provide 
example of configuration.
- *8* - The patch doesn't contain changes at the 
{{VisorCacheQueryDetailMetricsCollectorTask}} and 
{{VisorNodeDataCollectorJob}}. Sorry, I forgot to merge the branch with last 
changes on ignite-2.0. Re-merged.
- *9, 10, 11* - fixed.

> IGFS: Use common naming for IGFS meta and data caches.
> --
>
> Key: IGNITE-3625
> URL: https://issues.apache.org/jira/browse/IGNITE-3625
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> Currently IGFS is configured by passing names of two caches: meta and data. 
> See {{FileSystemConfiguration.metaCacheName}} and 
> {{FileSystemConfiguration.dataCacheName}}.
> These two caches are considered internal then and are not accessible for the 
> user.
> We need to do the following during node startup:
> 1) If certain cache is configured as meta or data cache for multiple IGFS-es, 
> or if it is configured as both meta and data cache for a single IGFS, then 
> throw an exception.
> Relevant code pieces:
> {{IgfsProcessor.validateLocalIgfsConfigurations}}
> {{IgfsProcessorSelfTest}}.
> 2) During node startup change the name of this cache to 
> {{igfs-IGFS_NAME-meta}} or {{igfs-IGFS_NAME-data}}. Change must be performed 
> both inside IGFS config and cache config.
> Relevant code pieces:
> {{CacheConfiguration.name}}
> {{FileSystemConfiguration.metaCacheName}}
> {{FileSystemConfiguration.dataCacheName}}
> {{IgfsUtils.prepareCacheConfiguration}} - where change will be done.
> 3) If any of new names caches with any other cache name, an exception should 
> be thrown. The most simple way: throw an exception if user-configured cache 
> name starts with {{igfs-}} and ends with {{-meta}} or {{-data}}.
> Relevant code pieces:
> {{IgniteNamedInstance.initializeDefaultCacheConfiguration}}.



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

[jira] [Commented] (IGNITE-4412) .NET: NLogLoggerTest is not thread safe

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4412:


Github user asfgit closed the pull request at:

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


> .NET: NLogLoggerTest is not thread safe
> ---
>
> Key: IGNITE-4412
> URL: https://issues.apache.org/jira/browse/IGNITE-4412
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET, newbie
> Fix For: 2.0
>
>
> NLog.Targets.MemoryTarget is not thread safe, the test can sometimes fail. 
> Replace this target with our own synchronized implementation.



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

[jira] [Commented] (IGNITE-4412) .NET: NLogLoggerTest is not thread safe

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4412:


Looks good to me, merged to master.

> .NET: NLogLoggerTest is not thread safe
> ---
>
> Key: IGNITE-4412
> URL: https://issues.apache.org/jira/browse/IGNITE-4412
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET, newbie
> Fix For: 2.0
>
>
> NLog.Targets.MemoryTarget is not thread safe, the test can sometimes fail. 
> Replace this target with our own synchronized implementation.



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

[jira] [Assigned] (IGNITE-4412) .NET: NLogLoggerTest is not thread safe

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4412:
--

Assignee: Pavel Tupitsyn  (was: Sergey Stronchinskiy)

> .NET: NLogLoggerTest is not thread safe
> ---
>
> Key: IGNITE-4412
> URL: https://issues.apache.org/jira/browse/IGNITE-4412
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>  Labels: .NET, newbie
> Fix For: 2.0
>
>
> NLog.Targets.MemoryTarget is not thread safe, the test can sometimes fail. 
> Replace this target with our own synchronized implementation.



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

[jira] [Assigned] (IGNITE-4525) Near reader is not created when value is loaded from store

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-4525:
---

Assignee: Dmitry Karachentsev

> Near reader is not created when value is loaded from store
> --
>
> Key: IGNITE-4525
> URL: https://issues.apache.org/jira/browse/IGNITE-4525
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
> Attachments: NearCacheTest.java
>
>
> When client with a near cache get value that is not in cache yet, it's loaded 
> from store and the value is saved in near cache. However reader on primary 
> node is not created, and when it's updated on server side, near cache is not 
> synchronized.
> Test attached.



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

[jira] [Comment Edited] (IGNITE-4219) Hive job submission failed with exception ”java.io.UTFDataFormatException“

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-4219 at 1/9/17 11:23 AM:
--

java.io.DataOutput#writeUTF exactly specifies this behavior in javadoc: 
{code}
 *If this number is larger than
 * 65535, then a UTFDataFormatException
 * is thrown. Otherwise, this length is written
 * to the output stream in exactly the manner
 * of the writeShort method;
 * after this, the one-, two-, or three-byte
 * representation of each character in the
 * string s is written.
{code}


was (Author: iveselovskiy):
ObjectOutputStream#writeUTF() exactly specifies this behavior in javadoc: 
{code}
 *If this number is larger than
 * 65535, then a UTFDataFormatException
 * is thrown. Otherwise, this length is written
 * to the output stream in exactly the manner
 * of the writeShort method;
 * after this, the one-, two-, or three-byte
 * representation of each character in the
 * string s is written.
{code}

> Hive job submission failed with exception ”java.io.UTFDataFormatException“
> --
>
> Key: IGNITE-4219
> URL: https://issues.apache.org/jira/browse/IGNITE-4219
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Reporter: Andrew Mashenkov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> Long property passing to Hadoop causes an exception:
> {code}
> Caused by: java.io.UTFDataFormatException 
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:2144)
>  
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:1987)
>  
>at java.io.ObjectOutputStream.writeUTF(ObjectOutputStream.java:865) 
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeUTFStringNullable(IgniteUtils.java:5029)
>  
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeStringMap(IgniteUtils.java:4989)
>  
>at 
> org.apache.ignite.internal.processors.hadoop.HadoopDefaultJobInfo.writeExternal(HadoopDefaultJobInfo.java:137)
> {code}



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

[jira] [Commented] (IGNITE-3920) Hadoop: remove PayloadAware interface.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3920:
--

Fixed.
[Tests|http://195.239.208.174/project.html?projectId=IgniteTests_IgniteTests=pull%2F1107%2Fhead]
 are re-run.

> Hadoop: remove PayloadAware interface.
> --
>
> Key: IGNITE-3920
> URL: https://issues.apache.org/jira/browse/IGNITE-3920
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop, IGFS
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> When IGNITE-3376 is ready, we will be able to execute {{PROXY}} operations 
> directly from {{IgfsImpl}}. It means that we no longer need 
> {{HadoopPayloadAware}} interface, and we no longer need to pass {{IgfsPaths}} 
> to the client. 
> Let's remove them all together.



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

[jira] [Commented] (IGNITE-4219) Hive job submission failed with exception ”java.io.UTFDataFormatException“

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-4219:
-

ObjectOutputStream#writeUTF() exactly specifies this behavior in javadoc: 
{code}
 *If this number is larger than
 * 65535, then a UTFDataFormatException
 * is thrown. Otherwise, this length is written
 * to the output stream in exactly the manner
 * of the writeShort method;
 * after this, the one-, two-, or three-byte
 * representation of each character in the
 * string s is written.
{code}

> Hive job submission failed with exception ”java.io.UTFDataFormatException“
> --
>
> Key: IGNITE-4219
> URL: https://issues.apache.org/jira/browse/IGNITE-4219
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Reporter: Andrew Mashenkov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> Long property passing to Hadoop causes an exception:
> {code}
> Caused by: java.io.UTFDataFormatException 
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:2144)
>  
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:1987)
>  
>at java.io.ObjectOutputStream.writeUTF(ObjectOutputStream.java:865) 
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeUTFStringNullable(IgniteUtils.java:5029)
>  
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeStringMap(IgniteUtils.java:4989)
>  
>at 
> org.apache.ignite.internal.processors.hadoop.HadoopDefaultJobInfo.writeExternal(HadoopDefaultJobInfo.java:137)
> {code}



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

[jira] [Commented] (IGNITE-4520) Web console: allow agent to connect through proxy

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-4520:


Investigating.

More detailed description 
http://docs.oracle.com/javase/7/docs/api/java/net/doc-files/net-properties.html 
about system properties.

[1] Working under windows, may be linux.

[2] For authentication under http, https proxy we can we can use following 
pattern for http.proxyHost or https.proxyHost: :@

> Web console: allow agent to connect through proxy
> -
>
> Key: IGNITE-4520
> URL: https://issues.apache.org/jira/browse/IGNITE-4520
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Andrey Novikov
>Priority: Critical
> Fix For: 2.0
>
>
> We currently assume that web agent will have direct access to console server. 
> Sometimes this is not true and any external Internet access is done through 
> SOCKS or HTTP proxy, potentially with authentication.
> We should add settings required for proxy (type, address, login, password) 
> and implement the support. {{java.net.Proxy}} class can be used for this.



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

[jira] [Updated] (IGNITE-4219) Hive job submission failed with exception ”java.io.UTFDataFormatException“

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky updated IGNITE-4219:

Summary: Hive job submission failed with exception 
”java.io.UTFDataFormatException“  (was: Hive job submsiion failed with 
exception ”java.io.UTFDataFormatException“)

> Hive job submission failed with exception ”java.io.UTFDataFormatException“
> --
>
> Key: IGNITE-4219
> URL: https://issues.apache.org/jira/browse/IGNITE-4219
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Reporter: Andrew Mashenkov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> Long property passing to Hadoop causes an exception:
> {code}
> Caused by: java.io.UTFDataFormatException 
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:2144)
>  
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:1987)
>  
>at java.io.ObjectOutputStream.writeUTF(ObjectOutputStream.java:865) 
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeUTFStringNullable(IgniteUtils.java:5029)
>  
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeStringMap(IgniteUtils.java:4989)
>  
>at 
> org.apache.ignite.internal.processors.hadoop.HadoopDefaultJobInfo.writeExternal(HadoopDefaultJobInfo.java:137)
> {code}



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

[jira] [Assigned] (IGNITE-3543) IGFS: Merge isRetryForSecondary() and verifyIntegrity() methods.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky reassigned IGNITE-3543:
---

Assignee: Ivan Veselovsky

> IGFS: Merge isRetryForSecondary() and verifyIntegrity() methods.
> 
>
> Key: IGNITE-3543
> URL: https://issues.apache.org/jira/browse/IGNITE-3543
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
> Fix For: 2.0
>
>
> There are two methods with very similar semantics:
> 1) {{IgfsPathIds.verifyIntegrity}}
> 2) {{IgfsMetaManager.isRetryForSecondary}}
> The latter method ensures that if path is incomplete, then the last existing 
> item do not have reference to child with expected name, but unexpected ID. 
> Semantically this situation means that concurrent update occurred. 
> Instead of heaving two identical methods, we should merge these checks in a 
> single method {{IgfsPathIds.verifyIntegrity}}.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4531:

Component/s: SQL

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



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

[jira] [Assigned] (IGNITE-4219) Hive job submsiion failed with exception ”java.io.UTFDataFormatException“

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky reassigned IGNITE-4219:
---

Assignee: Ivan Veselovsky

> Hive job submsiion failed with exception ”java.io.UTFDataFormatException“
> -
>
> Key: IGNITE-4219
> URL: https://issues.apache.org/jira/browse/IGNITE-4219
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Reporter: Andrew Mashenkov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> Long property passing to Hadoop causes an exception:
> {code}
> Caused by: java.io.UTFDataFormatException 
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:2144)
>  
>at 
> java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(ObjectOutputStream.java:1987)
>  
>at java.io.ObjectOutputStream.writeUTF(ObjectOutputStream.java:865) 
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeUTFStringNullable(IgniteUtils.java:5029)
>  
>at 
> org.apache.ignite.internal.util.IgniteUtils.writeStringMap(IgniteUtils.java:4989)
>  
>at 
> org.apache.ignite.internal.processors.hadoop.HadoopDefaultJobInfo.writeExternal(HadoopDefaultJobInfo.java:137)
> {code}



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

[jira] [Assigned] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky reassigned IGNITE-3542:
---

Assignee: Ivan Veselovsky

> IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
> -
>
> Key: IGNITE-3542
> URL: https://issues.apache.org/jira/browse/IGNITE-3542
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> If integrity check failed, it means that some concurrent file system update 
> occurred. We should always perform re-try in this case.



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

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

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky reassigned IGNITE-4503:
---

Assignee: Ivan Veselovsky

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



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4532:
--

Assignee: Pavel Tupitsyn

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



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

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

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4532:
--

 Summary: .NET: Fix build warnings
 Key: IGNITE-4532
 URL: https://issues.apache.org/jira/browse/IGNITE-4532
 Project: Ignite
  Issue Type: Task
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.0


There are ~70 warnings in VS 2015 after build.



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

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

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Summary: Update DML operation not working for @QuerySqlField with name  
(was: Update DML operation not working for QuerySQLField with name)

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



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

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

[David Albrecht (JIRA)]

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

David Albrecht updated IGNITE-4531:
---
Description: 
After putting a java class Operation with

{code}
@QuerySqlField(name = "operationNumber", index = true)
private String mOperationNumber;

@QuerySqlField(index = true)
private String mUuid;
{code}

in the cache. Via debug console I can see the following fields:

_val:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, ...]

and a column named: OPERATIONNUMBER with value 0010.

When I use 
{code}
UPDATE Operation set operationNumber =  ? WHERE mUuid =  ? 
{code}

with the arguments

[SCHEDULED, FF42930B6D3242B5A0B9D631E017027E]

I can see the following values:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, operationNumber=SCHEDULED, ...]

and a column named: OPERATIONNUMBER with value 0010.

The column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated!



  was:
After putting a java class Operation with

@QuerySqlField(name = "operationNumber", index = true)
private String mOperationNumber;

in the cache. Via debug console I can see the following fields:

_val:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, ...]

and a column named: OPERATIONNUMBER with value 0010.

When I use 
{code}
UPDATE Operation set operationNumber =  ? WHERE mUuid =  ? 
{code}

with the arguments

[SCHEDULED, FF42930B6D3242B5A0B9D631E017027E]

I can see the following values:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, operationNumber=SCHEDULED, ...]

and a column named: OPERATIONNUMBER with value 0010.

So the column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated.




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



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

[jira] [Created] (IGNITE-4531) Update DML operation not working for QuerySQLField with name

[David Albrecht (JIRA)]

David Albrecht created IGNITE-4531:
--

 Summary: Update DML operation not working for QuerySQLField with 
name
 Key: IGNITE-4531
 URL: https://issues.apache.org/jira/browse/IGNITE-4531
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.8
Reporter: David Albrecht
Priority: Critical


After putting a java class Operation with

@QuerySqlField(name = "operationNumber", index = true)
private String mOperationNumber;

in the cache. Via debug console I can see the following fields:

_val:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, ...]

and a column named: OPERATIONNUMBER with value 0010.

When I use 
{code}
UPDATE Operation set operationNumber =  ? WHERE mUuid =  ? 
{code}

with the arguments

[SCHEDULED, FF42930B6D3242B5A0B9D631E017027E]

I can see the following values:

Operation [... ,mUuid=FF42930B6D3242B5A0B9D631E017027E, mOperationNumber = 
0010, operationNumber=SCHEDULED, ...]

and a column named: OPERATIONNUMBER with value 0010.

So the column 'OPERATIONNUMBER' and the field 'mOperationNumber' is not updated.





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