[jira] [Commented] (IGNITE-4036) Near cache is not expired together with corresponding server cache

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4036:
-

[~amashenkov], I think that expiration info must be sent to the reader along 
with the value, so that it's properly expired in the scenario you described. I 
believe we already do this for backup entries, right?

> Near cache is not expired together with corresponding server cache
> --
>
> Key: IGNITE-4036
> URL: https://issues.apache.org/jira/browse/IGNITE-4036
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Sergej Sidorov
>Assignee: Dmitry Karachentsev
> Fix For: 1.9
>
>
> Steps to reproduce:
> 1. Configure server cache with expiry time
> 2. Start server node
> 3. Configure client node with near cache
> 4. Start client node
> 5. Put elements to cache
> 6. Wait for the expiry of the cache
> 7. Check cache state (server/client)



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

[jira] [Commented] (IGNITE-1466) CPP: Implement binary objects support.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-1466:
-

I've added two more public methods - {{GetData}} and {{GetDataLength}}, to make 
possible implementation of the simple identity resolver. Need to add some tests 
and polish public API.

> CPP: Implement binary objects support.
> --
>
> Key: IGNITE-1466
> URL: https://issues.apache.org/jira/browse/IGNITE-1466
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, roadmap
>
> We need to support portable objects in the same way as it is done in .Net and 
> Java: if some flag ({{keepBinary}}) is set, then we should return not real 
> object, but rather a wrapper around it.



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

[jira] [Commented] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2422:
-

[~vozerov], I tend to agree that the use case is a kind of artificial.

However, I was confused with {{BinaryObjectBuilder.setField(String name, 
@Nullable BinaryObjectBuilder builder)}} that suggest that the builder can be 
serialized or deserialized. What is the purpose of this method then?

> Unable to deserialize 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.
> After a brief investigation I see that this happens because neither 
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}} 
> presents in {{META-INF/classnames.properties}} file.
> If you try to update 
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by 
> building the project from scratch and copying-pasting generated content from 
> built {{classnames.properties}}, then you will still see that there are still 
> no entries for  {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes 
> by some reason.



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

[jira] [Commented] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-2422:
-

We didn't have this use case in mind. Why one would like to serialize builder? 

Instead, you can build complete binary object and then serialize it. To convert 
it back to builder you can call {{IgniteBinary.builder(BinaryObject)}} method.

> Unable to deserialize 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.
> After a brief investigation I see that this happens because neither 
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}} 
> presents in {{META-INF/classnames.properties}} file.
> If you try to update 
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by 
> building the project from scratch and copying-pasting generated content from 
> built {{classnames.properties}}, then you will still see that there are still 
> no entries for  {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes 
> by some reason.



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

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

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov commented on IGNITE-3207:
--

PR is ready for review.
Also, I've created ticket 
[IGNITE-4576|https://issues.apache.org/jira/browse/IGNITE-4576] for the same 
changes for .NET

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



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

[jira] [Updated] (IGNITE-4576) .NET: Rename IgniteConfiguration.gridName

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-4576:
-
Component/s: (was: general)
 platforms

> .NET: Rename IgniteConfiguration.gridName
> -
>
> Key: IGNITE-4576
> URL: https://issues.apache.org/jira/browse/IGNITE-4576
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Alexandr Fedotov
>  Labels: .net, important
> Fix For: 2.0
>
>
> The same as [IGNITE-3207|https://issues.apache.org/jira/browse/IGNITE-3207] 
> for .NET



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

[jira] [Updated] (IGNITE-4576) .NET: Rename IgniteConfiguration.gridName

[Alexandr Fedotov (JIRA)]

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

Alexandr Fedotov updated IGNITE-4576:
-
Labels: .net important  (was: important)

> .NET: Rename IgniteConfiguration.gridName
> -
>
> Key: IGNITE-4576
> URL: https://issues.apache.org/jira/browse/IGNITE-4576
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Alexandr Fedotov
>  Labels: .net, important
> Fix For: 2.0
>
>
> The same as [IGNITE-3207|https://issues.apache.org/jira/browse/IGNITE-3207] 
> for .NET



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

[jira] [Created] (IGNITE-4576) .NET: Rename IgniteConfiguration.gridName

[Alexandr Fedotov (JIRA)]

Alexandr Fedotov created IGNITE-4576:


 Summary: .NET: Rename IgniteConfiguration.gridName
 Key: IGNITE-4576
 URL: https://issues.apache.org/jira/browse/IGNITE-4576
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 1.1.4
Reporter: Alexandr Fedotov
 Fix For: 2.0


The same as [IGNITE-3207|https://issues.apache.org/jira/browse/IGNITE-3207] for 
.NET



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

[jira] [Closed] (IGNITE-1543) SqlQuery returns empty result set when custom PortableIdMapper

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-1543.
---

> SqlQuery returns empty result set when custom PortableIdMapper
> --
>
> Key: IGNITE-1543
> URL: https://issues.apache.org/jira/browse/IGNITE-1543
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Minor
> Fix For: 1.9
>
> Attachments: ClientTest.java
>
>
> Set custom {{PortableIdMapper}} for a type. Let this mapper to return some 
> predefined id for this type (like 12345).
> Then execute SQL to get all the entries of this type. The query will return 
> an empty result set. 
> Seems that at some point of execution SQL engine or some other part of the 
> platform uses default type to id mapping ignoring given {{PotableIdMapper}}.
> To reproduce:
> - Start a server node with portable marshaller enabled;
> - run the code attached (ClientTest.java).
> Add a test to our test suites.



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

[jira] [Commented] (IGNITE-1543) SqlQuery returns empty result set when custom PortableIdMapper

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-1543:
-

[~skalashnikov], there is no need to ask me if the ticket may be closed. If you 
see that the issue no longer exists then leave a message here and close the 
ticket.

> SqlQuery returns empty result set when custom PortableIdMapper
> --
>
> Key: IGNITE-1543
> URL: https://issues.apache.org/jira/browse/IGNITE-1543
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Minor
> Fix For: 1.9
>
> Attachments: ClientTest.java
>
>
> Set custom {{PortableIdMapper}} for a type. Let this mapper to return some 
> predefined id for this type (like 12345).
> Then execute SQL to get all the entries of this type. The query will return 
> an empty result set. 
> Seems that at some point of execution SQL engine or some other part of the 
> platform uses default type to id mapping ignoring given {{PotableIdMapper}}.
> To reproduce:
> - Start a server node with portable marshaller enabled;
> - run the code attached (ClientTest.java).
> Add a test to our test suites.



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

[jira] [Commented] (IGNITE-912) GridQueryProcessor adds type description by value name

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-912:


[~skalashnikov], sure go ahead and close if the issue is no longer exists.

> GridQueryProcessor adds type description by value name
> --
>
> Key: IGNITE-912
> URL: https://issues.apache.org/jira/browse/IGNITE-912
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: sprint-4
>Reporter: Denis Magda
> Fix For: 1.9
>
>
> Caught this issue while was working on IGNITE-471.
> Affected tests (GridPortableCacheTestSuite):
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedExplicitTx
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedPut
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedPutAll  
> In those tests type cache type configurations are taken from a xml 
> configuration. In the xml there are two different cache type configuration 
> with the same value type Person. This is absolutely ok.
> When portables are used GridQueryProcessor stores cache type configurations 
> in its internal table. As a key the processor uses "value_type_name" + 
> "space_name". This is an issue cause there two cache type configurations with 
> value type Person.
> org.apache.ignite.IgniteCheckedException: Type with name 'Person' already 
> indexed in cache 'null'.
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.addTypeByName(GridQueryProcessor.java:186)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:149)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:242)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:868)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:727)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:826)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1599)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1467)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:993)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:481)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:663)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:648)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:510)
> at 
> org.apache.ignite.cache.store.jdbc.CacheJdbcStoreAbstractMultithreadedSelfTest.beforeTest(CacheJdbcStoreAbstractMultithreadedSelfTest.java:98)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:489)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:321)
> at junit.framework.TestCase.runBare(TestCase.java:139)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:155)
> at 
> 

[jira] [Closed] (IGNITE-912) GridQueryProcessor adds type description by value name

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-912.
--

> GridQueryProcessor adds type description by value name
> --
>
> Key: IGNITE-912
> URL: https://issues.apache.org/jira/browse/IGNITE-912
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: sprint-4
>Reporter: Denis Magda
> Fix For: 1.9
>
>
> Caught this issue while was working on IGNITE-471.
> Affected tests (GridPortableCacheTestSuite):
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedExplicitTx
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedPut
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedPutAll  
> In those tests type cache type configurations are taken from a xml 
> configuration. In the xml there are two different cache type configuration 
> with the same value type Person. This is absolutely ok.
> When portables are used GridQueryProcessor stores cache type configurations 
> in its internal table. As a key the processor uses "value_type_name" + 
> "space_name". This is an issue cause there two cache type configurations with 
> value type Person.
> org.apache.ignite.IgniteCheckedException: Type with name 'Person' already 
> indexed in cache 'null'.
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.addTypeByName(GridQueryProcessor.java:186)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:149)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:242)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:868)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:727)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:826)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1599)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1467)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:993)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:481)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:663)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:648)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:510)
> at 
> org.apache.ignite.cache.store.jdbc.CacheJdbcStoreAbstractMultithreadedSelfTest.beforeTest(CacheJdbcStoreAbstractMultithreadedSelfTest.java:98)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:489)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:321)
> at junit.framework.TestCase.runBare(TestCase.java:139)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:155)
> at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:81)
> at 
> 

[jira] [Commented] (IGNITE-1794) Ignite should support Hibernate 5

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-1794:
-

[~mpereyma], I think this is the most straightforward approach. Feel free to 
propose your own though, I don't know the details of difference between 
version, so there can be easily a better solution. But we definitely should 
continue support for Hibernate 4, too early to drop it.

> Ignite should support Hibernate 5
> -
>
> Key: IGNITE-1794
> URL: https://issues.apache.org/jira/browse/IGNITE-1794
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Mykola Pereyma
>  Labels: newbie
> Attachments: HibernateCollectionRegionForIgnite.java, 
> HibernateEntityRegionForIgnite.java, HibernateRegionFactoryForIgnite.java, 
> HibernateTimestampsRegionForIgnite.java
>
>
> Currently Ignite supports Hibernate 4. 
> In Hibernate 5 org.hibernate.cache.spi.RegionFactory.start() method signature 
> has been changed from
> {{void start(Settings var1, Properties var2) throws CacheException;}}
> on
> {{void start(SessionFactoryOptions settings, Properties properties) throws 
> CacheException;}}
> Original user list: 
> http://apache-ignite-users.70518.x6.nabble.com/Hibernate-5-L2-Cache-Compatibility-td1656.html



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

[jira] [Commented] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-2422:
-

[~dreamx], thanks for the clarification. Now I see. 

In general, yes, we need to keep {{BinaryObjectBuilderImpl}} serializable. 

[~vozerov], looks like {{BinaryObjectBuilderImpl}} was not labeled with 
{{Serializable}} intentionally. When you were creating this implementation how 
it was planned to serialize {{BinaryObjectBuilderImpl}} content? 

> Unable to deserialize 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.
> After a brief investigation I see that this happens because neither 
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}} 
> presents in {{META-INF/classnames.properties}} file.
> If you try to update 
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by 
> building the project from scratch and copying-pasting generated content from 
> built {{classnames.properties}}, then you will still see that there are still 
> no entries for  {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes 
> by some reason.



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

[jira] [Updated] (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:all-tabpanel
 ]

Denis Magda updated IGNITE-4526:

Attachment: profiles.png

> 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
>
> Attachments: profiles.png, SuiteSnapShot.png
>
>
> 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-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=15830233#comment-15830233
 ] 

Denis Magda commented on IGNITE-4526:
-

[~manish__mishra], don't we need to add "netty" dependency to scala-2.10 
profile? I would recommend you to check that the example works with scala-2.10. 
Just do this locally. The profile can be switched using IntellijIdea "Maven 
Project"->"Profiles" tab (see attached screenshot).

The rest looks good to me.

> 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
>
> Attachments: SuiteSnapShot.png
>
>
> 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-4573) Optimize H2 comparisons w/constant

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-4573:
-

Investigated H2 code and discovered redundant constant conversions. Working on 
a fix to contribute to H2.

> Optimize H2 comparisons w/constant
> --
>
> Key: IGNITE-4573
> URL: https://issues.apache.org/jira/browse/IGNITE-4573
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Currently H2 performs constant conversions for each row - say, for {{WHERE 
> person.id = '1'}} the {{'1'}} will be converted to {{int}} for each row which 
> is clearly redundant.



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

[jira] [Updated] (IGNITE-3595) Improve Enum fields handling in SQL.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-3595:

Component/s: SQL

> Improve Enum fields handling in SQL.
> 
>
> Key: IGNITE-3595
> URL: https://issues.apache.org/jira/browse/IGNITE-3595
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 1.9
>
>
> Currently queries like this do not work in Ignite if we use enum field on the 
> left side and enum constant name or ordinal on the right side:
> select * from A where my_enum = 'ENUM_CONST';
> select * from A where my_enum = 3;
> This is a huge usability issue.
> We can try to solve it by contributing `User defined Value types` in H2 and 
> implementing the special value type for Enums to handle comparison with 
> String (convert to enum by name) and with int (convert to enum by ordinal).



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

[jira] [Updated] (IGNITE-4573) Optimize H2 comparisons w/constant

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-4573:

Fix Version/s: (was: 2.0)
   1.9

> Optimize H2 comparisons w/constant
> --
>
> Key: IGNITE-4573
> URL: https://issues.apache.org/jira/browse/IGNITE-4573
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>
> Currently H2 performs constant conversions for each row - say, for {{WHERE 
> person.id = '1'}} the {{'1'}} will be converted to {{int}} for each row which 
> is clearly redundant.



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

[jira] [Updated] (IGNITE-3595) Improve Enum fields handling in SQL.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-3595:

Fix Version/s: (was: 2.0)
   1.9

> Improve Enum fields handling in SQL.
> 
>
> Key: IGNITE-3595
> URL: https://issues.apache.org/jira/browse/IGNITE-3595
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.7
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 1.9
>
>
> Currently queries like this do not work in Ignite if we use enum field on the 
> left side and enum constant name or ordinal on the right side:
> select * from A where my_enum = 'ENUM_CONST';
> select * from A where my_enum = 3;
> This is a huge usability issue.
> We can try to solve it by contributing `User defined Value types` in H2 and 
> implementing the special value type for Enums to handle comparison with 
> String (convert to enum by name) and with int (convert to enum by ordinal).



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

[jira] [Created] (IGNITE-4575) Implement in Ignite wrapper for enums based on H2 user value type

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4575:
---

 Summary: Implement in Ignite wrapper for enums based on H2 user 
value type
 Key: IGNITE-4575
 URL: https://issues.apache.org/jira/browse/IGNITE-4575
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.9






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

[jira] [Updated] (IGNITE-4574) Introduce user value types to H2 w/custom conversion logic

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-4574:

 Assignee: Alexander Paschenko
Fix Version/s: (was: 2.0)
   1.9
  Component/s: SQL

> Introduce user value types to H2 w/custom conversion logic
> --
>
> Key: IGNITE-4574
> URL: https://issues.apache.org/jira/browse/IGNITE-4574
> Project: Ignite
>  Issue Type: Sub-task
>  Components: SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Created] (IGNITE-4574) Introduce user value types to H2 w/custom conversion logic

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4574:
---

 Summary: Introduce user value types to H2 w/custom conversion logic
 Key: IGNITE-4574
 URL: https://issues.apache.org/jira/browse/IGNITE-4574
 Project: Ignite
  Issue Type: Sub-task
Reporter: Alexander Paschenko






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

[jira] [Created] (IGNITE-4573) Optimize H2 comparisons w/constant

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4573:
---

 Summary: Optimize H2 comparisons w/constant
 Key: IGNITE-4573
 URL: https://issues.apache.org/jira/browse/IGNITE-4573
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko


Currently H2 performs constant conversions for each row - say, for {{WHERE 
person.id = '1'}} the {{'1'}} will be converted to {{int}} for each row which 
is clearly redundant.



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

[jira] [Commented] (IGNITE-4481) Creating the scripts

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-4481:
--

I've fixed yardstick scripts to run benchmarks on local machine


> Creating the scripts
> 
>
> Key: IGNITE-4481
> URL: https://issues.apache.org/jira/browse/IGNITE-4481
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Oleg Ostanin
>Assignee: Oleg Ostanin
> Fix For: 2.0
>
>
> The goal of this subtask is to resolve this part of original task:
> 1. Every deliverable must contain an executable (bat or sh file) with a clear 
> instruction on how to start a specific benchmark from the console.
> 2. For local runs (drivers and servers point out on localhost) ssh connection 
> must not be used



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

[jira] [Created] (IGNITE-4572) Develop distributed algebra support for dense and sparse data sets.

[Nikita Ivanov (JIRA)]

Nikita Ivanov created IGNITE-4572:
-

 Summary: Develop distributed algebra support for dense and sparse 
data sets.
 Key: IGNITE-4572
 URL: https://issues.apache.org/jira/browse/IGNITE-4572
 Project: Ignite
  Issue Type: Task
  Components: general
Reporter: Nikita Ivanov
Assignee: Nikita Ivanov


This is the base functionality for adding support for future ML capabilities.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4106:


GitHub user AMashenkov opened a pull request:

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

IGNITE-4106: SQL: parallelize sql queries over cache local partitions

Implemented

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

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

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

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


commit 6fffa4afb6699fdb54fc5e3ca02797547c4d09ea
Author: Andrey V. Mashenkov 
Date:   2017-01-19T15:24:03Z

Implemented




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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4106:


Github user AMashenkov closed the pull request at:

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


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



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

[jira] [Assigned] (IGNITE-3595) Improve Enum fields handling in SQL.

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-3595:
---

Assignee: Alexander Paschenko

> Improve Enum fields handling in SQL.
> 
>
> Key: IGNITE-3595
> URL: https://issues.apache.org/jira/browse/IGNITE-3595
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Sergi Vladykin
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 2.0
>
>
> Currently queries like this do not work in Ignite if we use enum field on the 
> left side and enum constant name or ordinal on the right side:
> select * from A where my_enum = 'ENUM_CONST';
> select * from A where my_enum = 3;
> This is a huge usability issue.
> We can try to solve it by contributing `User defined Value types` in H2 and 
> implementing the special value type for Enums to handle comparison with 
> String (convert to enum by name) and with int (convert to enum by ordinal).



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

[jira] [Commented] (IGNITE-4441) Define plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4441:


Merged to ignite-2.0

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{IPluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

[jira] [Commented] (IGNITE-1794) Ignite should support Hibernate 5

[Mykola Pereyma (JIRA)]

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

Mykola Pereyma commented on IGNITE-1794:


[~vkulichenko]Yes, your statement is correct - idea was to upgrade Hibernate 
5.X version and backward compatibility with Hibernate 4.X is out of scope in 
this case. Would you suggest to one module like 'hibernate5' and apply those 
changes there?

> Ignite should support Hibernate 5
> -
>
> Key: IGNITE-1794
> URL: https://issues.apache.org/jira/browse/IGNITE-1794
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Mykola Pereyma
>  Labels: newbie
> Attachments: HibernateCollectionRegionForIgnite.java, 
> HibernateEntityRegionForIgnite.java, HibernateRegionFactoryForIgnite.java, 
> HibernateTimestampsRegionForIgnite.java
>
>
> Currently Ignite supports Hibernate 4. 
> In Hibernate 5 org.hibernate.cache.spi.RegionFactory.start() method signature 
> has been changed from
> {{void start(Settings var1, Properties var2) throws CacheException;}}
> on
> {{void start(SessionFactoryOptions settings, Properties properties) throws 
> CacheException;}}
> Original user list: 
> http://apache-ignite-users.70518.x6.nabble.com/Hibernate-5-L2-Cache-Compatibility-td1656.html



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

[jira] [Comment Edited] (IGNITE-4475) Simplify async API

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4475 at 1/19/17 1:48 PM:
---

I've changed {{IgniteCompute}}: public API, implementation, examples and add 
simple tests to Full API suite 
({{IgniteComputeBasicConfigVariationsFullApiTestSuite}}). 

The primary review is required to ensure the way of refactoring .


was (Author: tledkov-gridgain):
I've changed {{IgniteCompute}} public API, implementation, examples and add 
simple tests to Full API suite 
({{IgniteComputeBasicConfigVariationsFullApiTestSuite}}). 

The primary review is required to ensure the way of refactoring .

> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.



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

[jira] [Comment Edited] (IGNITE-4475) Simplify async API

[Taras Ledkov (JIRA)]

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

Taras Ledkov edited comment on IGNITE-4475 at 1/19/17 1:48 PM:
---

I've changed *IgniteCompute*: public API, implementation, examples and add 
simple tests to Full API suite 
({{IgniteComputeBasicConfigVariationsFullApiTestSuite}}). 

The primary review is required to ensure the way of refactoring .


was (Author: tledkov-gridgain):
I've changed {{IgniteCompute}}: public API, implementation, examples and add 
simple tests to Full API suite 
({{IgniteComputeBasicConfigVariationsFullApiTestSuite}}). 

The primary review is required to ensure the way of refactoring .

> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.



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

[jira] [Commented] (IGNITE-4475) Simplify async API

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4475:
--

I've changed {{IgniteCompute}} public API, implementation, examples and add 
simple tests to Full API suite 
({{IgniteComputeBasicConfigVariationsFullApiTestSuite}}). 

The primary review is required to ensure the way of refactoring .

> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.



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

[jira] [Commented] (IGNITE-4475) Simplify async API

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4475:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4475 Simplify async API



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

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

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

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


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

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

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

Merge branch 'master' into ignite-2.0

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

Merge branch 'master' into ignite-2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

Merge branch 'master' into ignite-2.0

commit 77ca2e636c73e464f833f227c4894df0785ae9e2
Author: devozerov 
Date:   2017-01-16T13:07:49Z

Merge branch 'master' into ignite-2.0

commit d14e0727b3dd61ab5ec2957133d77dbc25e9ba68
Author: tledkov-gridgain 
Date:   2017-01-16T13:36:25Z

IGNITE-4428: Hadoop: moved HadoopMapReducePlanner and dependent classes to 
public space. This closes #1389. This closes #1394.

commit f1365421c299b754a10edf8b6f156aeeb5ff0ce1
Author: tledkov-gridgain 
Date:   2017-01-16T13:57:27Z

IGNITE-4503: Hadoop: added boundary checks to HadoopDirectDataInput. This 
closes # 1416.

commit e2ef47553c8b351722c92ce62d6ca9b0b70b96d1
Author: tledkov-gridgain 
Date:   2017-01-19T13:42:38Z

IGNITE-4475: change async API at the IgniteCompute, change examples, add 
tests




> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.



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

[jira] [Commented] (IGNITE-4571) Optimize futVer generations

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4571:
-

[~kdudkov], [~yzhdanov]
Why are we going to use Random? Looks unreliable to me. {{AtomicLong}} striped 
between thread-locals with {{incrementAndGet(1000L)}} gives very high 
throughput on multi-cores (many millions ops/sec). You will have the same 
performance, and it will be reliable at the same time.

> Optimize futVer generations
> ---
>
> Key: IGNITE-4571
> URL: https://issues.apache.org/jira/browse/IGNITE-4571
> Project: Ignite
>  Issue Type: Task
>Reporter: Konstantin Dudkov
>Assignee: Konstantin Dudkov
>
> 1. Optimize futVer generations - need to get rid of using CacheVersion in 
> favor of long value.
> Example
> org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateFuture.java:633
> org.apache.ignite.internal.processors.cache.version.GridCacheVersionManager#next(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion)
> Result:
> Need to replace cache version with random long (int), check compatibility and 
> messages sizes before & after and benchmark.
> How:
> Use thread local random. Generate ID on atomic future store and switch it to 
> putIfAbsent().



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

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

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4564:
-
Labels: trivial  (was: )

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



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

[jira] [Commented] (IGNITE-4550) Move service deployment to certain test

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4550:
--

Review and TC tests has been passed.

> Move service deployment to certain test
> ---
>
> Key: IGNITE-4550
> URL: https://issues.apache.org/jira/browse/IGNITE-4550
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
> Fix For: 1.9
>
>
> GridCacheAbstractFullApiSelfTest has service deployment in beforeTest() 
> method.
> It look like there is no need to do this for all tests and service deployment 
> should be moved to testTransformResourceInjection().



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

[jira] [Created] (IGNITE-4571) Optimize futVer generations

[Konstantin Dudkov (JIRA)]

Konstantin Dudkov created IGNITE-4571:
-

 Summary: Optimize futVer generations
 Key: IGNITE-4571
 URL: https://issues.apache.org/jira/browse/IGNITE-4571
 Project: Ignite
  Issue Type: Task
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov


1. Optimize futVer generations - need to get rid of using CacheVersion in favor 
of long value.

Example
org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateFuture.java:633
org.apache.ignite.internal.processors.cache.version.GridCacheVersionManager#next(org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion)

Result:
Need to replace cache version with random long (int), check compatibility and 
messages sizes before & after and benchmark.

How:
Use thread local random. Generate ID on atomic future store and switch it to 
putIfAbsent().



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2703:


IGNITE-4157 has been merged to ignite-2.0.

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



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

[jira] [Updated] (IGNITE-2398) .NET: Change default mapper behavior

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-2398:
---
Summary: .NET: Change default mapper behavior  (was: .NET: Change default 
mapper behavior.)

> .NET: Change default mapper behavior
> 
>
> Key: IGNITE-2398
> URL: https://issues.apache.org/jira/browse/IGNITE-2398
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Priority: Minor
>  Labels: .net, important
> Fix For: 2.0
>
>
> We need to mirror changes implemented in IGNITE-2191:
> 1) Default mapper must use full class name (i.e. with package)
> 2) Provide additional mapper implementation which will use simple names.



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

[jira] [Deleted] (IGNITE-4560) .NET: Use BinaryArrayIdentityResolver by default

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn deleted IGNITE-4560:
---


> .NET: Use BinaryArrayIdentityResolver by default
> 
>
> Key: IGNITE-4560
> URL: https://issues.apache.org/jira/browse/IGNITE-4560
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>  Labels: .NET
>
> Same as IGNITE-4558 for .NET



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-2578:


Not sure this is an issue anymore with presence of 
{{BinaryTypeConfiguration.EqualityComparer}}

> .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-4566) Introduce IgniteCacheEx.createQueryIndex

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-4566:

Component/s: (was: SQL)

> Introduce IgniteCacheEx.createQueryIndex
> 
>
> Key: IGNITE-4566
> URL: https://issues.apache.org/jira/browse/IGNITE-4566
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Updated] (IGNITE-4565) Support CREATE INDEX DDL statements

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko updated IGNITE-4565:

Component/s: messaging
 cache

> Support CREATE INDEX DDL statements
> ---
>
> Key: IGNITE-4565
> URL: https://issues.apache.org/jira/browse/IGNITE-4565
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache, messaging, SQL
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 1.9
>
>




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

[jira] [Created] (IGNITE-4570) Handle CREATE INDEX statements

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4570:
---

 Summary: Handle CREATE INDEX statements
 Key: IGNITE-4570
 URL: https://issues.apache.org/jira/browse/IGNITE-4570
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.9


Parse and execute CREATE INDEX boiling down to IgniteCacheEx.createQueryIndex 
introduced by IGNITE-4566



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

[jira] [Updated] (IGNITE-3718) .NET: SetItemExpireCallback support in IgniteSessionStateStoreProvider

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3718:
---
Fix Version/s: (was: 2.0)

> .NET: SetItemExpireCallback support in IgniteSessionStateStoreProvider
> --
>
> Key: IGNITE-3718
> URL: https://issues.apache.org/jira/browse/IGNITE-3718
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net
>
> See {code}IgniteSessionStateStoreProvider.SetItemExpireCallback{code}. 
> Currently we return false, indicating that this callback is not supported.
> It is possible to implement expiry events with EventType.CacheObjectExpired.



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

[jira] [Created] (IGNITE-4569) Create local portion of index w/table locking

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4569:
---

 Summary: Create local portion of index w/table locking
 Key: IGNITE-4569
 URL: https://issues.apache.org/jira/browse/IGNITE-4569
 Project: Ignite
  Issue Type: Sub-task
  Components: cache, SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.9


Actual index data modification - initially will render whole SQL table 
inaccessible during initial index buildup



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

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

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov edited comment on IGNITE-4106 at 1/19/17 12:48 PM:


[~sergi.vladykin], thanks for review, I'll fix PR shortly.


was (Author: amashenkov):
[~sergi.vladykin] thanks for review, I'll fix PR shortly.

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



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

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

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4106:
--

[~sergi.vladykin] thanks for review, I'll fix PR shortly.

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



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

[jira] [Created] (IGNITE-4568) Dynamically create distributed index

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4568:
---

 Summary: Dynamically create distributed index
 Key: IGNITE-4568
 URL: https://issues.apache.org/jira/browse/IGNITE-4568
 Project: Ignite
  Issue Type: Sub-task
  Components: messaging, SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.9


Handle index creation messaging using means introduced by IGNITE-4567



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

[jira] [Created] (IGNITE-4567) Design and implement means for distributed DDL statements

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4567:
---

 Summary: Design and implement means for distributed DDL statements
 Key: IGNITE-4567
 URL: https://issues.apache.org/jira/browse/IGNITE-4567
 Project: Ignite
  Issue Type: Sub-task
  Components: messaging, SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko


We need some kind of common way to handle stuff like CREATE INDEX/CREATE TABLE 
statements - in other words, run potentially long-running (and possibly cache 
locking) DDL operations on cluster nodes that would allow using new 
tables/indexes only when all nodes have performed requested operations and data 
modifications.



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

[jira] [Created] (IGNITE-4566) Introduce IgniteCacheEx.createQueryIndex

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4566:
---

 Summary: Introduce IgniteCacheEx.createQueryIndex
 Key: IGNITE-4566
 URL: https://issues.apache.org/jira/browse/IGNITE-4566
 Project: Ignite
  Issue Type: Sub-task
  Components: cache, SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.9






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

[jira] [Assigned] (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:all-tabpanel
 ]

Taras Ledkov reassigned IGNITE-3625:


Assignee: Alexey Kuznetsov  (was: Taras Ledkov)

Please review the changes too

> 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: Alexey Kuznetsov
> 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-3625) IGFS: Use common naming for IGFS meta and data caches.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3625:
-

Taras,

Looks good to me. I made several minor corrections and merged with 
{{ignite-2.0}} branch. The only thing I am concerned about is changes to Visor 
classes. Could you please ask Visor experts, e.g. [~kuaw26] to review them? 

Also I would perform another IGFS/Hadoop tests run since lots of changes were 
merged from {{ignite-2.0}}.

> 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] [Created] (IGNITE-4565) Support CREATE INDEX DDL statements

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-4565:
---

 Summary: Support CREATE INDEX DDL statements
 Key: IGNITE-4565
 URL: https://issues.apache.org/jira/browse/IGNITE-4565
 Project: Ignite
  Issue Type: New Feature
  Components: SQL
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko
 Fix For: 1.9






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

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

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4564:
---

 Summary: Ensure that builder approach is used for all setters in 
public API
 Key: IGNITE-4564
 URL: https://issues.apache.org/jira/browse/IGNITE-4564
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.8
Reporter: Vladimir Ozerov
 Fix For: 2.0


*Problem*
We employed "builder" approach for some configuration classes:
{code}
class Configuration {
Configuration setSomething(Something);
}
{code}

This is very convenient for users. However, only part of our configs employ 
this approach.

*Task*
Let's make sure that all other parts of our API follow this rule.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-3543:
---

Assignee: Ivan Veselovsky  (was: Vladimir Ozerov)

Ivan,

If there methods are not identical semantically, then I propose to simply close 
the ticket as "Won't fix".

> 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: 1.9
>
>
> 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] [Comment Edited] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-3542 at 1/19/17 11:52 AM:
---

Ivan,

Fix looks fine, but I cannot find test results? I need {{1421/head}} for IGFS 
and Hadoop suites.


was (Author: vozerov):
Ivan,

Fix looks fine, but I cannot find test results? I need "1421/head" for IGFS and 
Hadoop suites.

> 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: 1.9
>
>
> 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] [Updated] (IGNITE-4219) Hive job submission failed with exception ”java.io.UTFDataFormatException“

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4219:

Fix Version/s: (was: 1.9)
   2.0

> 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: Vladimir Ozerov
>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-4548) Invalid mapping of enum to varchar on load/store operation.

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-4548:


Revert public API changes in JdbcTypesTransformer, create separated ticket: 
IGNITE-4561

> Invalid mapping of enum to varchar on load/store operation.
> ---
>
> Key: IGNITE-4548
> URL: https://issues.apache.org/jira/browse/IGNITE-4548
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.9
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>
> http://stackoverflow.com/questions/41609207/ignite-cachejdbcpojostorefactory-using-enum-fields
> On load of data when type contain enum field that mapped in varchar in 
> database sometimes kind of type is incorrectly detected as binary. 
> Pojo contain string transformer methods.
> {code}
> private OrderSide side; // OrderSide is an enum
> public String getSideAsString() {
> return this.side.name();
> }
> public void setSideAsString(String s) {
> this.side = OrderSide.valueOf(s);
> }
> {code}
> and enum column described as:
> {code}
> new JdbcTypeField(Types.VARCHAR, "side", String.class, "sideAsString")
> {code}



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

[jira] [Updated] (IGNITE-305) Inconsistent TTL update.

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-305:
--
Fix Version/s: 2.0

> Inconsistent TTL update.
> 
>
> Key: IGNITE-305
> URL: https://issues.apache.org/jira/browse/IGNITE-305
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-2
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Govorukhin
>Priority: Minor
> Fix For: 2.0
>
>
> TTL update messages must be sent in ordered mode and must contain expected 
> version. 
> If version do not match, ignore. If match - update TTL.



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

[jira] [Updated] (IGNITE-305) Inconsistent TTL update.

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-305:
--
Assignee: (was: Dmitriy Govorukhin)

> Inconsistent TTL update.
> 
>
> Key: IGNITE-305
> URL: https://issues.apache.org/jira/browse/IGNITE-305
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-2
>Reporter: Vladimir Ozerov
>Priority: Minor
> Fix For: 2.0
>
>
> TTL update messages must be sent in ordered mode and must contain expected 
> version. 
> If version do not match, ignore. If match - update TTL.



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

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

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-2079:
---
Assignee: (was: Dmitriy Govorukhin)

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



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

[jira] [Commented] (IGNITE-4457) Define cache plugin API in .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4457:


Let's make CachePluginContext generic to be consistent with IGNITE-4441

> Define cache plugin API in .NET
> ---
>
> Key: IGNITE-4457
> URL: https://issues.apache.org/jira/browse/IGNITE-4457
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Vladimir Ozerov
>  Labels: .NET
> Fix For: 2.0
>
>
> Define cache plugin API in .NET similar to Java API:
> * {{CacheConfiguration.PluginConfigurations}}
> * {{ICachePluginProvider}}
> * {{ICachePluginContext}}
> Fundamental difference to Ignite plugins (IGNITE-4441), which are local, is 
> that {{CachePluginConfiguration}} is sent to remote nodes and providers are 
> created there. So we'll need {{PlatformCachePluginConfiguration}} and 
> {{PlatformCachePluginProvider}} on Java side.



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

[jira] [Assigned] (IGNITE-4441) Define plugin API in .NET

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4441:
---

Assignee: Pavel Tupitsyn  (was: Vladimir Ozerov)

LGTM

> Define plugin API in .NET
> -
>
> Key: IGNITE-4441
> URL: https://issues.apache.org/jira/browse/IGNITE-4441
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Define plugin API in .NET similar to Java API:
> * {{IgniteConfiguration.PluginConfigurations}}
> * {{IPluginProvider}}
> * {{IPluginContext}}
> Should work like this:
> * Plugin author implements {{IPluginProvider}}
> * We discover plugins on Ignite start by examining all DLL files in the 
> folder, load DLLs where {{IPluginProvider}} implementations are present, 
> instantiate these implementations, and call 
> {{IPluginProvider.Start(IPluginContext)}} method.
> * Plugin user can retrieve plugin via {{IIgnite.GetPlugin(string name)}}, 
> or via helper extension method provided by plugin author.
> This task does not include the possibility to interact with Java from the 
> plugin code.



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

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

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3837:


Looks good to me, merged to master.

> 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: Pavel Tupitsyn
>  Labels: odbc
> Fix For: 1.9
>
>
> 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] [Commented] (IGNITE-3837) ODBC: Escape sequences: Support CONVERT function.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3837:


Github user asfgit closed the pull request at:

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


> 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: Pavel Tupitsyn
>  Labels: odbc
> Fix For: 1.9
>
>
> 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] [Commented] (IGNITE-3376) IGFS: Allow direct PROXY mode invocations.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3376:


Github user tledkov-gridgain closed the pull request at:

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


> IGFS: Allow direct PROXY mode invocations.
> --
>
> Key: IGNITE-3376
> URL: https://issues.apache.org/jira/browse/IGNITE-3376
> Project: Ignite
>  Issue Type: Task
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: roadmap
> Fix For: 2.0
>
>
> Currently we do not have special handling for PROXY mode. So we will either 
> hit AssertionError during dev, or will go to incorrect code path in 
> productions systems.
> We need to fix that - PROXY mode should be handled correctly.



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

[jira] [Commented] (IGNITE-4405) Hadoop: support "readLine" method in HadoopDataInStream and HadoopDirectDataInput classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4405:


Github user tledkov-gridgain closed the pull request at:

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


> Hadoop: support "readLine" method in HadoopDataInStream and 
> HadoopDirectDataInput classes
> -
>
> Key: IGNITE-4405
> URL: https://issues.apache.org/jira/browse/IGNITE-4405
> Project: Ignite
>  Issue Type: Task
>  Components: hadoop
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> They are simply not implemented now.



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

[jira] [Updated] (IGNITE-1338) SQL engine doesn't convert query fields name in upper case before using

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-1338:
-
Labels: 1  (was: )

> SQL engine doesn't convert query fields name in upper case before using
> ---
>
> Key: IGNITE-1338
> URL: https://issues.apache.org/jira/browse/IGNITE-1338
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Assignee: Sergey Kalashnikov
>Priority: Trivial
> Fix For: 1.9
>
> Attachments: test-cluster-2.xml
>
>
> Node can not be started if query fields name written in *lower case* and key 
> fields with the *same* fields in *upper case* in cache type metadata.
> Please use attached configuration file for reproducing.
> {code}
> [14:30:28,526][SEVERE][main][IgniteKernal] Got exception while starting (will 
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to register query 
> type: TypeDescriptor [name=org.apache.ignite.Comalgorithm, 
> fields={APCSBJCODE=class java.math.BigDecimal, APCID=class 
> java.math.BigDecimal, AGRSBJCODE=class java.math.BigDecimal, AGRID=class 
> java.math.BigDecimal, DAOSBJCODE=class java.math.BigDecimal, DAOID=class 
> java.math.BigDecimal, CTPSBJCODE=class java.math.BigDecimal, CTPID=class 
> java.math.BigDecimal, apcsbjcode=class java.math.BigDecimal, apcid=class 
> java.math.BigDecimal, algcode=class java.math.BigDecimal, 
> algisversioned=class java.lang.Short, algtype=class java.lang.Integer, 
> algcalcobjecttype=class java.lang.Integer, algclasspath=class 
> java.lang.String, algcomment=class java.lang.String, algopendate=class 
> java.sql.Date, algclosedate=class java.sql.Date, algentstatus=class 
> java.lang.Integer, agrsbjcode=class java.math.BigDecimal, agrid=class 
> java.math.BigDecimal, daosbjcode=class java.math.BigDecimal, daoid=class 
> java.math.BigDecimal, ctpsbjcode=class java.math.BigDecimal, ctpid=class 
> java.math.BigDecimal, algusefields=class java.lang.String}, 
> indexes={FK1COMALGORITHM=IndexDescriptor [type=SORTED], 
> FK3COMALGORITHM=IndexDescriptor [type=SORTED], 
> FK4COMALGORITHM=IndexDescriptor [type=SORTED], 
> SQL050208183448780=IndexDescriptor [type=SORTED]}, fullTextIdx=null, 
> keyCls=class java.lang.Object, valCls=class java.lang.Object, 
> valTextIdx=false, registered=false]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerType(IgniteH2Indexing.java:1058)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:194)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:292)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1048)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:820)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:963)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
>   at org.apache.ignite.Ignition.start(Ignition.java:346)
>   at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: org.h2.jdbc.JdbcSQLException: Повтор имени столбца "APCSBJCODE"
> Duplicate column name "APCSBJCODE"; SQL statement:
> CREATE TABLE "cache2".org_apache_ignite_Comalgorithm (_key OTHER NOT 
> NULL,_val OTHER,APCSBJCODE DECIMAL,APCID DECIMAL,AGRSBJCODE DECIMAL,AGRID 
> DECIMAL,DAOSBJCODE DECIMAL,DAOID DECIMAL,CTPSBJCODE DECIMAL,CTPID 
> DECIMAL,apcsbjcode DECIMAL,apcid DECIMAL,algcode DECIMAL,algisversioned 
> SMALLINT,algtype INT,algcalcobjecttype INT,algclasspath VARCHAR,algcomment 
> VARCHAR,algopendate DATE,algclosedate DATE,algentstatus INT,agrsbjcode 
> DECIMAL,agrid DECIMAL,daosbjcode DECIMAL,daoid DECIMAL,ctpsbjcode 
> DECIMAL,ctpid DECIMAL,algusefields VARCHAR) engine 
> "org.apache.ignite.internal.processors.query.h2.opt.GridH2Table$Engine" 
> [42121-175]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:332)
>   at 

[jira] [Updated] (IGNITE-1338) SQL engine doesn't convert query fields name in upper case before using

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-1338:
-
Labels:   (was: 1)

> SQL engine doesn't convert query fields name in upper case before using
> ---
>
> Key: IGNITE-1338
> URL: https://issues.apache.org/jira/browse/IGNITE-1338
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Assignee: Sergey Kalashnikov
>Priority: Trivial
> Fix For: 1.9
>
> Attachments: test-cluster-2.xml
>
>
> Node can not be started if query fields name written in *lower case* and key 
> fields with the *same* fields in *upper case* in cache type metadata.
> Please use attached configuration file for reproducing.
> {code}
> [14:30:28,526][SEVERE][main][IgniteKernal] Got exception while starting (will 
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to register query 
> type: TypeDescriptor [name=org.apache.ignite.Comalgorithm, 
> fields={APCSBJCODE=class java.math.BigDecimal, APCID=class 
> java.math.BigDecimal, AGRSBJCODE=class java.math.BigDecimal, AGRID=class 
> java.math.BigDecimal, DAOSBJCODE=class java.math.BigDecimal, DAOID=class 
> java.math.BigDecimal, CTPSBJCODE=class java.math.BigDecimal, CTPID=class 
> java.math.BigDecimal, apcsbjcode=class java.math.BigDecimal, apcid=class 
> java.math.BigDecimal, algcode=class java.math.BigDecimal, 
> algisversioned=class java.lang.Short, algtype=class java.lang.Integer, 
> algcalcobjecttype=class java.lang.Integer, algclasspath=class 
> java.lang.String, algcomment=class java.lang.String, algopendate=class 
> java.sql.Date, algclosedate=class java.sql.Date, algentstatus=class 
> java.lang.Integer, agrsbjcode=class java.math.BigDecimal, agrid=class 
> java.math.BigDecimal, daosbjcode=class java.math.BigDecimal, daoid=class 
> java.math.BigDecimal, ctpsbjcode=class java.math.BigDecimal, ctpid=class 
> java.math.BigDecimal, algusefields=class java.lang.String}, 
> indexes={FK1COMALGORITHM=IndexDescriptor [type=SORTED], 
> FK3COMALGORITHM=IndexDescriptor [type=SORTED], 
> FK4COMALGORITHM=IndexDescriptor [type=SORTED], 
> SQL050208183448780=IndexDescriptor [type=SORTED]}, fullTextIdx=null, 
> keyCls=class java.lang.Object, valCls=class java.lang.Object, 
> valTextIdx=false, registered=false]
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerType(IgniteH2Indexing.java:1058)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:194)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:292)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1048)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:820)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:963)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
>   at org.apache.ignite.Ignition.start(Ignition.java:346)
>   at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: org.h2.jdbc.JdbcSQLException: Повтор имени столбца "APCSBJCODE"
> Duplicate column name "APCSBJCODE"; SQL statement:
> CREATE TABLE "cache2".org_apache_ignite_Comalgorithm (_key OTHER NOT 
> NULL,_val OTHER,APCSBJCODE DECIMAL,APCID DECIMAL,AGRSBJCODE DECIMAL,AGRID 
> DECIMAL,DAOSBJCODE DECIMAL,DAOID DECIMAL,CTPSBJCODE DECIMAL,CTPID 
> DECIMAL,apcsbjcode DECIMAL,apcid DECIMAL,algcode DECIMAL,algisversioned 
> SMALLINT,algtype INT,algcalcobjecttype INT,algclasspath VARCHAR,algcomment 
> VARCHAR,algopendate DATE,algclosedate DATE,algentstatus INT,agrsbjcode 
> DECIMAL,agrid DECIMAL,daosbjcode DECIMAL,daoid DECIMAL,ctpsbjcode 
> DECIMAL,ctpid DECIMAL,algusefields VARCHAR) engine 
> "org.apache.ignite.internal.processors.query.h2.opt.GridH2Table$Engine" 
> [42121-175]
>   at org.h2.message.DbException.getJdbcSQLException(DbException.java:332)
>   at 

[jira] [Assigned] (IGNITE-4181) The several runs of ServicesExample causes NPE

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-4181:
---

Assignee: Alexander Menshikov

> The several runs of ServicesExample causes NPE
> --
>
> Key: IGNITE-4181
> URL: https://issues.apache.org/jira/browse/IGNITE-4181
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6, 1.7
> Environment: Windows 10, Oracle JDK 7
>Reporter: Sergey Kozlov
>Assignee: Alexander Menshikov
> Fix For: 2.0
>
>
> 0. Open example project in IDEA
> 1. Start 2-3 {{ExampleNodeStartup}}
> 2. Run {{ServicesExample}} several times.
> Sometimes it causes NullPointerException:
> {noformat}
> Executing closure [mapSize=10]
> Service was cancelled: myNodeSingletonService
> [15:37:20,020][INFO ][srvc-deploy-#24%null%][GridServiceProcessor] Cancelled 
> service instance [name=myNodeSingletonService, 
> execId=88a92a4d-c1cb-4a9b-8930-c67ac7f42bf3]
> [15:37:20,032][INFO ][sys-#33%null%][GridCacheProcessor] Stopped cache: 
> myNodeSingletonService
> [15:37:20,033][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=4], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,045][INFO ][sys-#39%null%][GridCacheProcessor] Stopped cache: 
> myClusterSingletonService
> [15:37:20,046][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=5], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,062][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Node left topology: TcpDiscoveryNode 
> [id=4f9cbc67-d756-4c25-9ee4-aee6528da024, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.107, 2001:0:9d38:6ab8:34b2:9f3e:3c6f:269], 
> sockAddrs=[/2001:0:9d38:6ab8:34b2:9f3e:3c6f:269:0, /127.0.0.1:0, 
> /0:0:0:0:0:0:0:1:0, work-pc/172.25.4.107:0], discPort=0, order=10, 
> intOrder=7, lastExchangeTime=1478522239236, loc=false, 
> ver=1.7.3#20161107-sha1:5132ac87, isClient=true]
> [15:37:20,063][INFO ][disco-event-worker-#20%null%][GridDiscoveryManager] 
> Topology snapshot [ver=11, servers=3, clients=0, CPUs=8, heap=11.0GB]
> [15:37:20,064][INFO ][sys-#44%null%][GridCacheProcessor] Stopped cache: 
> myMultiService
> [15:37:20,066][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=6], evt=DISCOVERY_CUSTOM_EVT, 
> node=5faac72a-72ab-4277-9643-0e962973b3f4]
> [15:37:20,076][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myClusterSingletonService, mode=PARTITIONED]
> [15:37:20,115][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=10, 
> minorTopVer=7], evt=DISCOVERY_CUSTOM_EVT, 
> node=478f1752-fdce-42c6-aef6-55a5f4c08d90]
> [15:37:20,121][INFO 
> ][exchange-worker-#23%null%][GridCachePartitionExchangeManager] Skipping 
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], evt=NODE_LEFT, node=4f9cbc67-d756-4c25-9ee4-aee6528da024]
> [15:37:20,133][INFO ][exchange-worker-#23%null%][GridCacheProcessor] Started 
> cache [name=myMultiService, mode=PARTITIONED]
> [15:37:20,135][ERROR][exchange-worker-#23%null%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=11, 
> minorTopVer=1], nodeId=5faac72a, evt=DISCOVERY_CUSTOM_EVT]
> java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.initStartedCacheOnCoordinator(CacheAffinitySharedManager.java:743)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:413)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:565)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:448)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1447)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> 

[jira] [Assigned] (IGNITE-4475) Simplify async API

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-4475:


Assignee: Taras Ledkov

> Simplify async API
> --
>
> Key: IGNITE-4475
> URL: https://issues.apache.org/jira/browse/IGNITE-4475
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> *Problem*
> We need to simplify our async API. It is to complex and verbose at the moment:
> {code}
> IgniteCache asyncCache = cache.withAsync();
> asyncCache.get(key);
> IgniteFuture fut = asyncCache.future();
> {code}
> *Proposed solution*
> 1) Deprecate {{IgniteAsyncSupport}} interface.
> 2) Make async operations more straightforward:
> {code}
> IgniteFuture fut = cache.getAsync(key);
> {code}
> *Scope*
> ~80 async methods in all public interfaces.



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

[jira] [Commented] (IGNITE-1543) SqlQuery returns empty result set when custom PortableIdMapper

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-1543:


[~dmagda], I have checked the sample code and managed to run it after some 
refactoring (due to its age). It is passing now. So I guess we can close the 
issue. Can you please take a look? 

> SqlQuery returns empty result set when custom PortableIdMapper
> --
>
> Key: IGNITE-1543
> URL: https://issues.apache.org/jira/browse/IGNITE-1543
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Minor
> Fix For: 1.9
>
> Attachments: ClientTest.java
>
>
> Set custom {{PortableIdMapper}} for a type. Let this mapper to return some 
> predefined id for this type (like 12345).
> Then execute SQL to get all the entries of this type. The query will return 
> an empty result set. 
> Seems that at some point of execution SQL engine or some other part of the 
> platform uses default type to id mapping ignoring given {{PotableIdMapper}}.
> To reproduce:
> - Start a server node with portable marshaller enabled;
> - run the code attached (ClientTest.java).
> Add a test to our test suites.



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

[jira] [Commented] (IGNITE-912) GridQueryProcessor adds type description by value name

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-912:
---

[~dmagda], I think this ticket can be closed now since tests are pass with 
current code. Do you agree?

> GridQueryProcessor adds type description by value name
> --
>
> Key: IGNITE-912
> URL: https://issues.apache.org/jira/browse/IGNITE-912
> Project: Ignite
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: sprint-4
>Reporter: Denis Magda
> Fix For: 1.9
>
>
> Caught this issue while was working on IGNITE-471.
> Affected tests (GridPortableCacheTestSuite):
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedExplicitTx
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedPut
> - CacheJdbcPojoStoreMultitreadedSelfTest.testMultithreadedPutAll  
> In those tests type cache type configurations are taken from a xml 
> configuration. In the xml there are two different cache type configuration 
> with the same value type Person. This is absolutely ok.
> When portables are used GridQueryProcessor stores cache type configurations 
> in its internal table. As a key the processor uses "value_type_name" + 
> "space_name". This is an issue cause there two cache type configurations with 
> value type Person.
> org.apache.ignite.IgniteCheckedException: Type with name 'Person' already 
> indexed in cache 'null'.
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.addTypeByName(GridQueryProcessor.java:186)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:149)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:242)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:868)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:727)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:826)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1599)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1467)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:993)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:481)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:663)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:648)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:510)
> at 
> org.apache.ignite.cache.store.jdbc.CacheJdbcStoreAbstractMultithreadedSelfTest.beforeTest(CacheJdbcStoreAbstractMultithreadedSelfTest.java:98)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:489)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:321)
> at junit.framework.TestCase.runBare(TestCase.java:139)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at 
> 

[jira] [Created] (IGNITE-4563) .NET: ICache.LoadCache fails on non-primitive arguments

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4563:
--

 Summary: .NET: ICache.LoadCache fails on non-primitive arguments
 Key: IGNITE-4563
 URL: https://issues.apache.org/jira/browse/IGNITE-4563
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.8, 1.7, 1.6, 1.5.0.final
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Critical
 Fix For: 1.9


{{ICache.LoadCache}} arguments are unnecessarily deserialized on Java side (see 
{{readObjectArray}} call in {{PlatformCache.loadCache0}}). So any arguments 
that are not primitives or primitive collections cause an exception.



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

[jira] [Created] (IGNITE-4562) .NET: Add BinaryObjectException

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4562:
--

 Summary: .NET: Add BinaryObjectException
 Key: IGNITE-4562
 URL: https://issues.apache.org/jira/browse/IGNITE-4562
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Trivial
 Fix For: 2.1


Add mapping for Java BinaryObjectException in .NET. This exception can occur 
due to misconfiguration or deployment issues, we should map it to a .NET class.



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

[jira] [Reopened] (IGNITE-4147) SSL misconfiguration is not handled properly

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reopened IGNITE-4147:
-

May fail on constant node restarting. Should be more durable.

> SSL misconfiguration is not handled properly
> 
>
> Key: IGNITE-4147
> URL: https://issues.apache.org/jira/browse/IGNITE-4147
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
> Fix For: 2.0
>
>
> Currently, if one tries to start a node with incorrect SSL configuration 
> (i.e. node with SSL disabled tries to connect to secured cluster or other way 
> around), this new node does not show any exceptions or warnings. Instead user 
> may end up having two topologies - one secured and another non-secured.
> This is counterintuitive. We should try to detect this and throw an exception 
> in this case.
> Here are possible scenarios that we should consider:
> * Unsecured server tries to join secured cluster.
> * Secured server tries to join unsecured cluster.
> * Unsecured client tries to join secured cluster.
> * Secured client tries to join unsecured cluster.



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

[jira] [Commented] (IGNITE-2422) Unable to deserialize BinaryObjectBuilder

[Maksim Kozlov (JIRA)]

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

Maksim Kozlov commented on IGNITE-2422:
---

[~dmagda] I'm sorry, hurried to the test.
{{BinaryObjectBuilder}} and {{BinaryObjectBuilderImpl}} classes are not checked 
{{Serializable.class.isAssignableFrom(cls)}} (true if a class implements 
serializable and false otherwise), so I thought it would be better to add a 
serializable and clonable in {{BinaryObjectBuilder}}.
Then it turns out that it is necessary to remove the check from the 
{{ClassesGenerator}} (I think it is not good)?

> Unable to deserialize 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.
> After a brief investigation I see that this happens because neither 
> {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {{org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}} 
> presents in {{META-INF/classnames.properties}} file.
> If you try to update 
> {{ignite/modules/core/src/main/resources/META-INF/classnames.properties}} by 
> building the project from scratch and copying-pasting generated content from 
> built {{classnames.properties}}, then you will still see that there are still 
> no entries for  {{org.apache.ignite.binary.BinaryObjectBuilder}} nor 
> {org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl}}.
> Looks like that {{ClassesGenerator}} misses these and other possible classes 
> by some reason.



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

[jira] [Commented] (IGNITE-4472) Web Console: Implement usage tracing

[Andrey Novikov (JIRA)]

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

Andrey Novikov commented on IGNITE-4472:


Reviewed.

Notes:
* Under safari when category in table hided header and columns have different 
width
* I think we should store group id in Activities collection to simplify 
selecting by group.
* Period selector should be replaced on month datepicker
* Activities total -> Total activities, Activities configuration -> 
Configuration's Activities, ...

> Web Console: Implement usage tracing
> 
>
> Key: IGNITE-4472
> URL: https://issues.apache.org/jira/browse/IGNITE-4472
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
>
> We need to track some kind of "activity scores" for users.
> Activities:
> # Configuration
> # SQL
> # Demo
> And show that score on admin panel.
> May be this could be implemented by some library.



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