[jira] [Updated] (IGNITE-962) node.js: provide json cache object implementation
[ https://issues.apache.org/jira/browse/IGNITE-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-962: - Fix Version/s: 1.6 > node.js: provide json cache object implementation > - > > Key: IGNITE-962 > URL: https://issues.apache.org/jira/browse/IGNITE-962 > Project: Ignite > Issue Type: Sub-task > Components: interop >Reporter: Yakov Zhdanov > Fix For: 1.6 > > > * check if we can optimize strings store with storing byte arrays > * implement SQL indexing support for new object -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1915) .Net: Ignite as Entity Framework Second-Level Cache
Pavel Tupitsyn created IGNITE-1915: --- Summary: .Net: Ignite as Entity Framework Second-Level Cache Key: IGNITE-1915 URL: https://issues.apache.org/jira/browse/IGNITE-1915 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.6 Entity Framework is #1 ORM for .NET We should provide easy solution to boost Entity Framework performance with Ignite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-529) Implement IgniteFlumeStreamer to stream data from Apache Flume
[
https://issues.apache.org/jira/browse/IGNITE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004195#comment-15004195
]
Anton Vinogradov commented on IGNITE-529:
-
Roman looks great,
except creation of IgniteSink by passing Ignite as a constructor parameter.
Better case is to create Ignite using configuration xml. Same configuration
(except client mode) should be used to create Ignite instance at test's start.
Also please change event listening from remote to local.
I've made some minor fixes at own branch, hope you'll agree with them ;) :
https://github.com/avinogradovgg/ignite/commit/5113cf2600ffdbe702f289be2b3a470aa97b041b
> Implement IgniteFlumeStreamer to stream data from Apache Flume
> --
>
> Key: IGNITE-529
> URL: https://issues.apache.org/jira/browse/IGNITE-529
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Flume|http://flume.apache.org/] for more information.
> We should create {{IgniteFlumeStreamer}} which will consume messages from
> Apache Flume and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert Flume data to Ignite data using an optional pluggable converter.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1914) .Net: Get rid of boxing in DoOutInOpNullable
Pavel Tupitsyn created IGNITE-1914: --- Summary: .Net: Get rid of boxing in DoOutInOpNullable Key: IGNITE-1914 URL: https://issues.apache.org/jira/browse/IGNITE-1914 Project: Ignite Issue Type: Improvement Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Priority: Minor Fix For: 1.6 See CacheImpl.DoOutInOpNullable overloads. We read result as object and then check for null. Nulls are quite frequent in these scenarios. To get rid of boxing we need to introduce TryUnmarshal method which allows reading value types with null semantics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1912) .Net: Continuous query does not work for value types
[ https://issues.apache.org/jira/browse/IGNITE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004182#comment-15004182 ] ASF GitHub Bot commented on IGNITE-1912: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/233 IGNITE-1912 .Net: Continuous query does not work for value types You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1912 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/233.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 #233 commit ccfc3eabb730239eed2c5973fd6a271623f0c683 Author: Pavel Tupitsyn Date: 2015-11-13T14:40:33Z Failing test added commit 4ce90965153dcdba40cf59d394cd8e7ffec25d7b Author: Pavel Tupitsyn Date: 2015-11-13T14:44:42Z wip commit 54e41fb452d1eedb52aeb6c1cfb03017a4dcb4b8 Author: Pavel Tupitsyn Date: 2015-11-13T15:12:04Z wip commit 51a72ecc6a530dcee0e7b198f8ff6c7bbde48101 Author: Pavel Tupitsyn Date: 2015-11-13T15:12:58Z wip commit 54f2f9aeb6a67d8332dfbccbd5c63c34ae3368b4 Author: Pavel Tupitsyn Date: 2015-11-13T15:17:19Z wip commit 225ca15089d81a29bd5281b8634f5c29674b114c Author: Pavel Tupitsyn Date: 2015-11-13T15:35:49Z wip commit 9eb949908ad989e8d40d41be15274ce04c53ca0b Author: Pavel Tupitsyn Date: 2015-11-13T15:49:29Z Fix test commit b18710311ea5ea9b1b19a0214ae746da9f501d4d Author: Pavel Tupitsyn Date: 2015-11-13T16:06:53Z Get rid of boxing > .Net: Continuous query does not work for value types > > > Key: IGNITE-1912 > URL: https://issues.apache.org/jira/browse/IGNITE-1912 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: 1.5 > > > OldValue comes as Null from java, but we try to deserialize it as TK, which > fails for value types. > Need to employ the same approach as in cache with CacheResult. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1913) Assertion fail cause Grid hangs
[ https://issues.apache.org/jira/browse/IGNITE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004070#comment-15004070 ] Anton Vinogradov commented on IGNITE-1913: -- Happens in case partition map update generates before cache stop, but applies after cache restart. > Assertion fail cause Grid hangs > --- > > Key: IGNITE-1913 > URL: https://issues.apache.org/jira/browse/IGNITE-1913 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Critical > > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,762][INFO > ][async-runner-1][GridDiscoveryManager] Topology snapshot [ver=278, > servers=4, clients=0, CPUs=8, heap=2.8GB] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,763][INFO > ][ignite-#69277%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridDhtPartitionDemander] > Completed rebalancing [cache=null, > fromNode=0002a176-16e7-41e3-9b45-cce0a55a5000, > topology=AffinityTopologyVersion [topVer=278, minorTopVer=0], time=10 ms] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,767][INFO > ][ignite-#69279%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridDhtPartitionDemander] > Completed rebalancing [cache=null, > fromNode=102f9887-7fbd-4010-a93b-5c239c38d001, > topology=AffinityTopologyVersion [topVer=278, minorTopVer=0], time=20 ms] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,767][INFO > ][ignite-#69280%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridDhtPartitionDemander] > Completed (final) rebalancing [cache=null, > fromNode=204c4f10-06ca-4e70-9b67-13baf27f1002, > topology=AffinityTopologyVersion [topVer=278, minorTopVer=0], time=20 ms] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,768][INFO > ][main][root] >>> Stopping test: testPutInsideTransaction in 83897 ms <<< > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO > ][exchange-worker-#62068%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest1%][GridCachePartitionExchangeManager] > Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion > [topVer=278, minorTopVer=1]] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO > ][exchange-worker-#62066%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest0%][GridCachePartitionExchangeManager] > Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion > [topVer=278, minorTopVer=1]] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO > ][exchange-worker-#69294%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridCachePartitionExchangeManager] > Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion > [topVer=278, minorTopVer=1]] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO > ][exchange-worker-#62069%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest2%][GridCachePartitionExchangeManager] > Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion > [topVer=278, minorTopVer=1]] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,791][INFO > ][ignite-#61916%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest0%][GridCacheProcessor] > Stopped cache: null > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,791][INFO > ][main][root] >>> Starting test: testPutAsyncStoreEnabled <<< > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,794][INFO > ][exchange-worker-#62066%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest0%][GridCachePartitionExchangeManager] > Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion > [topVer=278, minorTopVer=2]] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,812][INFO > ][ignite-#69275%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridCacheProcessor] > Stopped cache: null > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,814][INFO > ][exchange-worker-#69294%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridCachePartitionExchangeManager] > Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion > [topVer=278, minorTopVer=2]] > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,815][INFO > ][ignite-#61990%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest2%][GridCacheProcessor] > Stopped cache: null > [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,818][INFO > ][exchange-worker-#62069%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest2%][GridCachePartitionExchangeManager] > Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion > [topVer=278,
[jira] [Created] (IGNITE-1913) Assertion fail cause Grid hangs
Anton Vinogradov created IGNITE-1913: Summary: Assertion fail cause Grid hangs Key: IGNITE-1913 URL: https://issues.apache.org/jira/browse/IGNITE-1913 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov Priority: Critical [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,762][INFO ][async-runner-1][GridDiscoveryManager] Topology snapshot [ver=278, servers=4, clients=0, CPUs=8, heap=2.8GB] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,763][INFO ][ignite-#69277%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridDhtPartitionDemander] Completed rebalancing [cache=null, fromNode=0002a176-16e7-41e3-9b45-cce0a55a5000, topology=AffinityTopologyVersion [topVer=278, minorTopVer=0], time=10 ms] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,767][INFO ][ignite-#69279%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridDhtPartitionDemander] Completed rebalancing [cache=null, fromNode=102f9887-7fbd-4010-a93b-5c239c38d001, topology=AffinityTopologyVersion [topVer=278, minorTopVer=0], time=20 ms] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,767][INFO ][ignite-#69280%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridDhtPartitionDemander] Completed (final) rebalancing [cache=null, fromNode=204c4f10-06ca-4e70-9b67-13baf27f1002, topology=AffinityTopologyVersion [topVer=278, minorTopVer=0], time=20 ms] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,768][INFO ][main][root] >>> Stopping test: testPutInsideTransaction in 83897 ms <<< [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO ][exchange-worker-#62068%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest1%][GridCachePartitionExchangeManager] Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion [topVer=278, minorTopVer=1]] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO ][exchange-worker-#62066%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest0%][GridCachePartitionExchangeManager] Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion [topVer=278, minorTopVer=1]] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO ][exchange-worker-#69294%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridCachePartitionExchangeManager] Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion [topVer=278, minorTopVer=1]] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,769][INFO ][exchange-worker-#62069%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest2%][GridCachePartitionExchangeManager] Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion [topVer=278, minorTopVer=1]] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,791][INFO ][ignite-#61916%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest0%][GridCacheProcessor] Stopped cache: null [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,791][INFO ][main][root] >>> Starting test: testPutAsyncStoreEnabled <<< [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,794][INFO ][exchange-worker-#62066%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest0%][GridCachePartitionExchangeManager] Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion [topVer=278, minorTopVer=2]] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,812][INFO ][ignite-#69275%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridCacheProcessor] Stopped cache: null [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,814][INFO ][exchange-worker-#69294%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest3%][GridCachePartitionExchangeManager] Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion [topVer=278, minorTopVer=2]] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,815][INFO ][ignite-#61990%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest2%][GridCacheProcessor] Stopped cache: null [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,818][INFO ][exchange-worker-#62069%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest2%][GridCachePartitionExchangeManager] Nothing scheduled, skipping rebalancing [top=AffinityTopologyVersion [topVer=278, minorTopVer=2]] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,824][INFO ][exchange-worker-#62066%atomic.IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest0%][GridCacheProcessor] Started cache [name=default, mode=PARTITIONED] [08:45:57] : [org.apache.ignite:ignite-core] [08:45:57,825][INFO ][ignite-#62003%sys-atomic.IgniteCachePutRetryAtomicPrimaryWriteOr
[jira] [Created] (IGNITE-1912) .Net: Continuous query does not work for value types
Pavel Tupitsyn created IGNITE-1912: --- Summary: .Net: Continuous query does not work for value types Key: IGNITE-1912 URL: https://issues.apache.org/jira/browse/IGNITE-1912 Project: Ignite Issue Type: Bug Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Priority: Blocker Fix For: 1.5 OldValue comes as Null from java, but we try to deserialize it as TK, which fails for value types. Need to employ the same approach as in cache with CacheResult. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1910) .Net: Possible handle leak in ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1910: Description: * See ScanQuery.cs, "writer.WriteObject(holder);" line. If it fails due to user filter being non-serializable, we leak a handle. * Same thing in Cache.LoadCache * Another leak is in Java. If the GridCloseableIteratorAdapter fails in ctor, it does not close keyValFilter. was: See ScanQuery.cs, "writer.WriteObject(holder);" line. If it fails due to user filter being non-serializable, we leak a handle. Another leak is in Java. If the GridCloseableIteratorAdapter fails in ctor, it does not close keyValFilter. > .Net: Possible handle leak in ScanQuery > --- > > Key: IGNITE-1910 > URL: https://issues.apache.org/jira/browse/IGNITE-1910 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.5 > > > * See ScanQuery.cs, "writer.WriteObject(holder);" line. If it fails due to > user filter being non-serializable, we leak a handle. > * Same thing in Cache.LoadCache > * Another leak is in Java. If the GridCloseableIteratorAdapter fails in ctor, > it does not close keyValFilter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1910) .Net: Possible handle leak in ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003984#comment-15003984 ] Pavel Tupitsyn commented on IGNITE-1910: - Leak check added to AfterTest. > .Net: Possible handle leak in ScanQuery > --- > > Key: IGNITE-1910 > URL: https://issues.apache.org/jira/browse/IGNITE-1910 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.5 > > > See ScanQuery.cs, "writer.WriteObject(holder);" line. > If it fails due to user filter being non-serializable, we leak a handle. > Another leak is in Java. If the GridCloseableIteratorAdapter fails in ctor, > it does not close keyValFilter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1910) .Net: Possible handle leak in ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003978#comment-15003978 ] ASF GitHub Bot commented on IGNITE-1910: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/232 IGNITE-1910 .Net: Possible handle leak in ScanQuery You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1910 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/232.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 #232 commit e167b30ca643ca57cfcc1bab2ff31b35ab2ce120 Author: Pavel Tupitsyn Date: 2015-11-13T12:52:05Z IGNITE-1910 .Net: Possible handle leak in ScanQuery commit fab5c723dc9d8926ed88f52af9d047de63afa31f Author: Pavel Tupitsyn Date: 2015-11-13T13:26:52Z Fix predicate close in Java > .Net: Possible handle leak in ScanQuery > --- > > Key: IGNITE-1910 > URL: https://issues.apache.org/jira/browse/IGNITE-1910 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > See ScanQuery.cs, "writer.WriteObject(holder);" line. > If it fails due to user filter being non-serializable, we leak a handle. > Another leak is in Java. If the GridCloseableIteratorAdapter fails in ctor, > it does not close keyValFilter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1910) .Net: Possible handle leak in ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1910: Description: See ScanQuery.cs, "writer.WriteObject(holder);" line. If it fails due to user filter being non-serializable, we leak a handle. Another leak is in Java. If the GridCloseableIteratorAdapter fails in ctor, it does not close keyValFilter. was: See ScanQuery.cs, "writer.WriteObject(holder);" line. If it fails due to user filter being non-serializable, we leak a handle. > .Net: Possible handle leak in ScanQuery > --- > > Key: IGNITE-1910 > URL: https://issues.apache.org/jira/browse/IGNITE-1910 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > See ScanQuery.cs, "writer.WriteObject(holder);" line. > If it fails due to user filter being non-serializable, we leak a handle. > Another leak is in Java. If the GridCloseableIteratorAdapter fails in ctor, > it does not close keyValFilter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1910) .Net: Possible handle leak in ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1910: Priority: Critical (was: Major) > .Net: Possible handle leak in ScanQuery > --- > > Key: IGNITE-1910 > URL: https://issues.apache.org/jira/browse/IGNITE-1910 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Fix For: 1.5 > > > See ScanQuery.cs, "writer.WriteObject(holder);" line. > If it fails due to user filter being non-serializable, we leak a handle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1911) Discovery MessageWorker thread moves node to "zombie" state when fails
Denis Magda created IGNITE-1911: --- Summary: Discovery MessageWorker thread moves node to "zombie" state when fails Key: IGNITE-1911 URL: https://issues.apache.org/jira/browse/IGNITE-1911 Project: Ignite Issue Type: Bug Affects Versions: ignite-1.4 Reporter: Denis Magda Assignee: Denis Magda Priority: Critical Fix For: 1.5 If MessageWorker thread fails by some reason (i.e. because of uncaught exception) it will move a node to "zombie" state. The node will still accept messages through SocketReader but won't process them. At some point of time the node will fail because the message queue will be overflowed. Such a node must be stopped as soon as MessageWorker terminates. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1910) .Net: Possible handle leak in ScanQuery
Pavel Tupitsyn created IGNITE-1910: --- Summary: .Net: Possible handle leak in ScanQuery Key: IGNITE-1910 URL: https://issues.apache.org/jira/browse/IGNITE-1910 Project: Ignite Issue Type: Bug Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 See ScanQuery.cs, "writer.WriteObject(holder);" line. If it fails due to user filter being non-serializable, we leak a handle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1894) .Net: Delegate support in the API via extension methods
[
https://issues.apache.org/jira/browse/IGNITE-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-1894:
---
Assignee: Pavel Tupitsyn
> .Net: Delegate support in the API via extension methods
> ---
>
> Key: IGNITE-1894
> URL: https://issues.apache.org/jira/browse/IGNITE-1894
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.6
>
>
> In many places we require a single-method interface implementation from the
> user:
> {code:title=ICompute}
> TRes Call(IComputeFunc clo);
> {code}
> All of these can be extended to accept a delegate:
> {code:title=ICompute}
> TRes Call(Func clo);
> {code}
> We can't replace interfaces with delegates completely (which is desirable),
> because it will take away serialization control from the user. So the
> interface approach has to stay as a primary.
> Delegate support can be added via extension methods, which wrap provided
> delegates into a class that implements corresponding interface.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1896) .Net: Improve query API
[
https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003931#comment-15003931
]
Pavel Tupitsyn commented on IGNITE-1896:
-
As you can see, the change is very simple, yet simplifies user code a lot.
And if I was a user, I would do the same via extension methods.
> .Net: Improve query API
> ---
>
> Key: IGNITE-1896
> URL: https://issues.apache.org/jira/browse/IGNITE-1896
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type
> explicitly.
> There are cases when query type is a string and/or is different from current
> cache generic type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
> IQueryCursor> ScanQuery(ICacheEntryFilter
> filter);
> IQueryCursor> SqlQuery(string sql, params
> object[] args);
> IQueryCursor> SqlQuery(string sql, bool local,
> params object[] args);
> IQueryCursor> TextQuery(string text);
> IQueryCursor> TextQuery(string text, bool local);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1896) .Net: Improve query API
[
https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003926#comment-15003926
]
ASF GitHub Bot commented on IGNITE-1896:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/231
IGNITE-1896 .Net: Improve query API
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-1896
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/231.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 #231
commit 66dc2543804e2639fd4b09da1ddd1cde3f552ffd
Author: Pavel Tupitsyn
Date: 2015-11-13T12:17:16Z
IGNITE-1896 .Net: Improve query API
commit ed6eba566795ae21b20f31a5b8b127ea01c2e934
Author: Pavel Tupitsyn
Date: 2015-11-13T12:18:38Z
Arg checks
commit a8040a2bdf73587b65c6413095389845b7f840bb
Author: Pavel Tupitsyn
Date: 2015-11-13T12:21:51Z
Examples & tests
commit eb150cd13a2488daee6006de86c5545aca8fd600
Author: Pavel Tupitsyn
Date: 2015-11-13T12:27:07Z
Fix typo
commit 9ed675e076790a3674a0df86de3201f43cd42a8a
Author: Pavel Tupitsyn
Date: 2015-11-13T12:29:37Z
Cleanup
> .Net: Improve query API
> ---
>
> Key: IGNITE-1896
> URL: https://issues.apache.org/jira/browse/IGNITE-1896
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type
> explicitly.
> There are cases when query type is a string and/or is different from current
> cache generic type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
> IQueryCursor> ScanQuery(ICacheEntryFilter
> filter);
> IQueryCursor> SqlQuery(string sql, params
> object[] args);
> IQueryCursor> SqlQuery(string sql, bool local,
> params object[] args);
> IQueryCursor> TextQuery(string text);
> IQueryCursor> TextQuery(string text, bool local);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1898) Make it possible to obtain the local Ignite instance statically
[
https://issues.apache.org/jira/browse/IGNITE-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov resolved IGNITE-1898.
---
Resolution: Won't Fix
> Make it possible to obtain the local Ignite instance statically
> ---
>
> Key: IGNITE-1898
> URL: https://issues.apache.org/jira/browse/IGNITE-1898
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Andrey Kornev
>Priority: Minor
>
> Currently the ways to obtain the local instance of Ignite make use of the
> grid name or the node UUID with the corresponding {{Ignition.ignite()}}
> methods. However, during deserialization if would sometime be desirable to be
> able to obtain the local instance of Ignite (the one on which the given class
> is being deserialized) without relying on the grid name. Such instance can
> then be used to look up the node-local resources and any other context. The
> grid name is not reliable way to serialize/deserialize {{IgniteKernal}} in a
> situation when a single JVM has multiple Ignite nodes started (as is often
> the case in unit tests).
> The proposed solution is to
> # implement a custom ThreadFactory to be used with the public, system,
> utility and so on thread pools. For all newly created thread, the factory
> will create a thread local and initialize it with the current instance of
> Ignite.
> # modify the classes that create their own threads, to do the same.
> # provide a public static method on the Ignition class
> {{public static Ignite getLocalNode();}}
> that returns the value of the thread local. It throws
> {{IllegalStateException}} if the method is invoked from a non-Ignite thread.
> This will guarantee that all threads started by a particular Ignite instance
> will have the instance reference available in their thread locals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1898) Make it possible to obtain the local Ignite instance statically
[
https://issues.apache.org/jira/browse/IGNITE-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov closed IGNITE-1898.
-
> Make it possible to obtain the local Ignite instance statically
> ---
>
> Key: IGNITE-1898
> URL: https://issues.apache.org/jira/browse/IGNITE-1898
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Andrey Kornev
>Priority: Minor
>
> Currently the ways to obtain the local instance of Ignite make use of the
> grid name or the node UUID with the corresponding {{Ignition.ignite()}}
> methods. However, during deserialization if would sometime be desirable to be
> able to obtain the local instance of Ignite (the one on which the given class
> is being deserialized) without relying on the grid name. Such instance can
> then be used to look up the node-local resources and any other context. The
> grid name is not reliable way to serialize/deserialize {{IgniteKernal}} in a
> situation when a single JVM has multiple Ignite nodes started (as is often
> the case in unit tests).
> The proposed solution is to
> # implement a custom ThreadFactory to be used with the public, system,
> utility and so on thread pools. For all newly created thread, the factory
> will create a thread local and initialize it with the current instance of
> Ignite.
> # modify the classes that create their own threads, to do the same.
> # provide a public static method on the Ignition class
> {{public static Ignite getLocalNode();}}
> that returns the value of the thread local. It throws
> {{IllegalStateException}} if the method is invoked from a non-Ignite thread.
> This will guarantee that all threads started by a particular Ignite instance
> will have the instance reference available in their thread locals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1900) Ignite JMX problem with Spring Boot
[
https://issues.apache.org/jira/browse/IGNITE-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003919#comment-15003919
]
Denis Magda commented on IGNITE-1900:
-
I've applied your patch on my side and got {{ClassCastException}}. I'm using
the latest sources from the master branch.
{noformat}
Exception in thread "main" java.lang.ClassCastException: java.util.ArrayList
cannot be cast to java.util.Set
at
org.apache.ignite.internal.IgniteKernal.getUserAttributesFormatted(IgniteKernal.java:571)
at org.gridgain.fsb.ServerTest.main(ServerTest.java:39)
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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
{noformat}
Code that I executed {{((IgniteKernal)ignite).getUserAttributesFormatted();}}.
Please follow this steps and then re-submit the pull-request:
1) Fix {{ClassCastException}}. It's absolutely correct to return {{Set}} from
{{getUserAttributesFormatted()}}. Re-implement IgniteKernal's implementation by
removing usage of {{F.transform}} function. Just create a set and prefill it
with data.
2) Add tests that will validate that the functions modified by you return what
is expected from them. You can add the tests into {{GridMBeanSelfTest}}.
3) When everything is fixed resubmit the pull-request and move this ticket to
"PATCH_AVAILABLE" state. This will trigger our TeamCity to check your patch
against all the tests we have in Ignite.
Full info on how to contribute using pull-request is located here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-1.CreateGitHubpull-request
BTW, look though our coding guidelines
(https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines). Now I
don't see any issues related to the guidelines, just in order to prevent them
in the future.
> Ignite JMX problem with Spring Boot
> ---
>
> Key: IGNITE-1900
> URL: https://issues.apache.org/jira/browse/IGNITE-1900
> Project: Ignite
> Issue Type: Bug
> Components: 1.4
>Affects Versions: ignite-1.4
>Reporter: wmz7year
>
> I use Ignite with Spring Boot.
> When start application,Spring Boot will register JMX info.
> In IgniteMXBean interface,There is two method getUserAttributesFormatted and
> getLifecycleBeansFormatted return Collection
> But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method
> will get method return type.
> {noformat}
> final Type rawType = objType.getRawType();
> if (rawType instanceof Class) {
> Class c = (Class) rawType;
> if (c == List.class || c == Set.class || c == SortedSet.class) {
> Type[] actuals = objType.getActualTypeArguments();
> assert(actuals.length == 1);
> if (c == SortedSet.class)
> mustBeComparable(c, actuals[0]);
> return makeArrayOrCollectionMapping(objType, actuals[0],
> factory);
> } else {
> boolean sortedMap = (c == SortedMap.class);
> if (c == Map.class || sortedMap) {
> Type[] actuals = objType.getActualTypeArguments();
> assert(actuals.length == 2);
> if (sortedMap)
> mustBeComparable(c, actuals[0]);
> return makeTabularMapping(objType, sortedMap,
> actuals[0], actuals[1], factory);
> }
> }
> }
> {noformat}
> The Collection will not match any type for this although IgniteKernal
> return type is Set or List.
> I think IgniteMXBean interface should change Collection to Set and List
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1899) Incorrect Ignite (IgniteKernal) instance deserialized when multiple Ignite nodes started in the same JVM
[
https://issues.apache.org/jira/browse/IGNITE-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov resolved IGNITE-1899.
---
Resolution: Won't Fix
> Incorrect Ignite (IgniteKernal) instance deserialized when multiple Ignite
> nodes started in the same JVM
>
>
> Key: IGNITE-1899
> URL: https://issues.apache.org/jira/browse/IGNITE-1899
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Andrey Kornev
>
> The current approach to serialization/deserialization of {{IgniteKernal}} is
> flawed as it relies on the grid name. However, in a situation when a single
> JVM instance has multiple Ignite instances started (as is often the case in
> unit tests) this approach doesn't work. Ignite requires that each Ignite
> instance started within the same JVM be assigned different names. Thus,
> during deserialization on another node a wrong instance of {{IgniteKernal}}
> gets looked up.
> Say, the JVM instance has 2 nodes started: node A and node B. Then, when the
> node A serializes {{IgniteKernal}} it'll write the grid name "A" to the wire.
> Then, during deserialization of the {{IgniteKernal}} instance on the node B,
> the name "A" will be read from the wire and used to look up the Ignite
> instance uisng {{Ignition.ignite("A");}}. Clearly the class (holding a
> reference to {{IgniteKernal}}) ends up with a wrong instance of Ignite. If
> the class also retrieves the node-local resources by doing
> {{Ignition.ignite(deserializedGridName).cluster().nodeLocalMap()}} then it
> may end up with incorrect data.
> As of Ignite 1.4, {{ClusterGroupAdapter}} class or any other class that
> serialize the instance of {{IgniteKernal}} suffer from this issue. The fix
> would be to simply stop serializing the grid name altogether and during
> deserialization rely on the thread local instead, as per IGNITE-1898.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1899) Incorrect Ignite (IgniteKernal) instance deserialized when multiple Ignite nodes started in the same JVM
[
https://issues.apache.org/jira/browse/IGNITE-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov closed IGNITE-1899.
-
> Incorrect Ignite (IgniteKernal) instance deserialized when multiple Ignite
> nodes started in the same JVM
>
>
> Key: IGNITE-1899
> URL: https://issues.apache.org/jira/browse/IGNITE-1899
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Andrey Kornev
>
> The current approach to serialization/deserialization of {{IgniteKernal}} is
> flawed as it relies on the grid name. However, in a situation when a single
> JVM instance has multiple Ignite instances started (as is often the case in
> unit tests) this approach doesn't work. Ignite requires that each Ignite
> instance started within the same JVM be assigned different names. Thus,
> during deserialization on another node a wrong instance of {{IgniteKernal}}
> gets looked up.
> Say, the JVM instance has 2 nodes started: node A and node B. Then, when the
> node A serializes {{IgniteKernal}} it'll write the grid name "A" to the wire.
> Then, during deserialization of the {{IgniteKernal}} instance on the node B,
> the name "A" will be read from the wire and used to look up the Ignite
> instance uisng {{Ignition.ignite("A");}}. Clearly the class (holding a
> reference to {{IgniteKernal}}) ends up with a wrong instance of Ignite. If
> the class also retrieves the node-local resources by doing
> {{Ignition.ignite(deserializedGridName).cluster().nodeLocalMap()}} then it
> may end up with incorrect data.
> As of Ignite 1.4, {{ClusterGroupAdapter}} class or any other class that
> serialize the instance of {{IgniteKernal}} suffer from this issue. The fix
> would be to simply stop serializing the grid name altogether and during
> deserialization rely on the thread local instead, as per IGNITE-1898.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amir Akhmedov reassigned IGNITE-640:
Assignee: Amir Akhmedov
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> Collection get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> Collection get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> Collection get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of
> keys, and maximum number of values for a key. The maximum number of keys
> should be controlled by Ignite standard eviction policy. The maximum number
> of values for a key should be controlled by the implementation of the
> multi-map. Either eviction parameter should be configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1906) .Net: Ignite configuration without Spring
[ https://issues.apache.org/jira/browse/IGNITE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1906: Description: * Spring is alien for .NET developers * In-code configuration is often preferrable was: * Spring is alien for .NET developers. * In-code configuration is often preferrable > .Net: Ignite configuration without Spring > - > > Key: IGNITE-1906 > URL: https://issues.apache.org/jira/browse/IGNITE-1906 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > * Spring is alien for .NET developers > * In-code configuration is often preferrable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1906) .Net: Ignite configuration without Spring
[ https://issues.apache.org/jira/browse/IGNITE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1906: Summary: .Net: Ignite configuration without Spring (was: .Net: Ignite configuration without Spring.) > .Net: Ignite configuration without Spring > - > > Key: IGNITE-1906 > URL: https://issues.apache.org/jira/browse/IGNITE-1906 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > * Spring is alien for .NET developers. > * In-code configuration is often preferrable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1908) .Net: Query configuration
Pavel Tupitsyn created IGNITE-1908: --- Summary: .Net: Query configuration Key: IGNITE-1908 URL: https://issues.apache.org/jira/browse/IGNITE-1908 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.5 Configure queries in code. This includes attribute-based configuration (similar to QuerySqlField in Java). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1909) .Net: Discovery configuration
Pavel Tupitsyn created IGNITE-1909: --- Summary: .Net: Discovery configuration Key: IGNITE-1909 URL: https://issues.apache.org/jira/browse/IGNITE-1909 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.5 Configure discovery in code -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1907) .Net: Cache configuration
Pavel Tupitsyn created IGNITE-1907: --- Summary: .Net: Cache configuration Key: IGNITE-1907 URL: https://issues.apache.org/jira/browse/IGNITE-1907 Project: Ignite Issue Type: Sub-task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.5 Configure cache in code -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1906) .Net: Ignite configuration without Spring.
Pavel Tupitsyn created IGNITE-1906: --- Summary: .Net: Ignite configuration without Spring. Key: IGNITE-1906 URL: https://issues.apache.org/jira/browse/IGNITE-1906 Project: Ignite Issue Type: Task Components: interop Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 * Spring is alien for .NET developers. * In-code configuration is often preferrable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1900) Ignite JMX problem with Spring Boot
[
https://issues.apache.org/jira/browse/IGNITE-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov updated IGNITE-1900:
--
Description:
I use Ignite with Spring Boot.
When start application,Spring Boot will register JMX info.
In IgniteMXBean interface,There is two method getUserAttributesFormatted and
getLifecycleBeansFormatted return Collection
But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method will
get method return type.
{noformat}
final Type rawType = objType.getRawType();
if (rawType instanceof Class) {
Class c = (Class) rawType;
if (c == List.class || c == Set.class || c == SortedSet.class) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 1);
if (c == SortedSet.class)
mustBeComparable(c, actuals[0]);
return makeArrayOrCollectionMapping(objType, actuals[0],
factory);
} else {
boolean sortedMap = (c == SortedMap.class);
if (c == Map.class || sortedMap) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 2);
if (sortedMap)
mustBeComparable(c, actuals[0]);
return makeTabularMapping(objType, sortedMap,
actuals[0], actuals[1], factory);
}
}
}
{noformat}
The Collection will not match any type for this although IgniteKernal
return type is Set or List.
I think IgniteMXBean interface should change Collection to Set and List
was:
I use Ignite with Spring Boot.
When start application,Spring Boot will register JMX info.
In IgniteMXBean interface,There is two method getUserAttributesFormatted and
getLifecycleBeansFormatted return Collection
But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method will
get method return type.
final Type rawType = objType.getRawType();
if (rawType instanceof Class) {
Class c = (Class) rawType;
if (c == List.class || c == Set.class || c == SortedSet.class) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 1);
if (c == SortedSet.class)
mustBeComparable(c, actuals[0]);
return makeArrayOrCollectionMapping(objType, actuals[0],
factory);
} else {
boolean sortedMap = (c == SortedMap.class);
if (c == Map.class || sortedMap) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 2);
if (sortedMap)
mustBeComparable(c, actuals[0]);
return makeTabularMapping(objType, sortedMap,
actuals[0], actuals[1], factory);
}
}
}
The Collection will not match any type for this although IgniteKernal
return type is Set or List.
I think IgniteMXBean interface should change Collection to Set and List
> Ignite JMX problem with Spring Boot
> ---
>
> Key: IGNITE-1900
> URL: https://issues.apache.org/jira/browse/IGNITE-1900
> Project: Ignite
> Issue Type: Bug
> Components: 1.4
>Affects Versions: ignite-1.4
>Reporter: wmz7year
>
> I use Ignite with Spring Boot.
> When start application,Spring Boot will register JMX info.
> In IgniteMXBean interface,There is two method getUserAttributesFormatted and
> getLifecycleBeansFormatted return Collection
> But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method
> will get method return type.
> {noformat}
> final Type rawType = objType.getRawType();
> if (rawType instanceof Class) {
> Class c = (Class) rawType;
> if (c == List.class || c == Set.class || c == SortedSet.class) {
> Type[] actuals = objType.getActualTypeArguments();
> assert(actuals.length == 1);
> if (c == SortedSet.class)
> mustBeComparable(c, actuals[0]);
> return makeArrayOrCollectionMapping(objType, actuals[0],
> factory);
> } else {
> boolean sortedMap = (c == SortedMap.class);
> if (c == Map.class || sortedMap) {
> Type[] actuals = objType.getActualTypeArguments();
> assert(actuals.length == 2);
> if (sortedMap)
> mustBeComparable(c, actuals[0]);
> return makeTabularMapping(objType, sortedMap,
> actuals[0], actuals[1], factory);
> }
> }
> }
> {noformat}
> The Co
[jira] [Commented] (IGNITE-1878) Implement support to package manager for vendor libs
[ https://issues.apache.org/jira/browse/IGNITE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003888#comment-15003888 ] Dmitriyff commented on IGNITE-1878: --- Added jspm config with vendords js libs > Implement support to package manager for vendor libs > > > Key: IGNITE-1878 > URL: https://issues.apache.org/jira/browse/IGNITE-1878 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Dmitriyff >Assignee: Dmitriyff > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1901) CPP: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-1901:
Assignee: Vladimir Ozerov (was: Igor Sapego)
> CPP: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1901
> URL: https://issues.apache.org/jira/browse/IGNITE-1901
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to CPP:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1905) High contention for CacheLockImpl causes AssertionErrors
[
https://issues.apache.org/jira/browse/IGNITE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1905:
Attachment: ServerTest.java
ClientTest.java
> High contention for CacheLockImpl causes AssertionErrors
>
>
> Key: IGNITE-1905
> URL: https://issues.apache.org/jira/browse/IGNITE-1905
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
> Environment: Windows 7
>Reporter: Denis Magda
>Priority: Critical
> Fix For: 1.5
>
> Attachments: ClientTest.java, ServerTest.java
>
>
> When multiple threads, running on the same client node, compete for
> CacheLockImpl this leads to AssertionErrors.
> Pseudo-code snippet, that is called from multiple threads and causes the
> assertions, looks like this:
> {noformat}
> boolean locked = lock.tryLock(100, TimeUnit.MILLISECONDS);
> if (locked)
> lock.unlock();
> {noformat}
> Initially the issue was detected on ignite-1.4.
> In server's node logs the following assertion appears
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.addOwned(GridDhtLockFuture.java:958)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$2.onOwnerChanged(GridCacheMvccManager.java:155)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.checkOwnerChanged(GridDistributedCacheEntry.java:810)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:516)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:576)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:764)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:973)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:557)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:132)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:130)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
>
> In addition from time to time a client node also outputs a different kind of
> assertion:
> {noformat}
> Exception in thread "ignite-#4%sys-null%" java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.GridCacheExplicitLockSpan.markOwned(GridCacheExplicitLockSpan.java:196)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.markExplicitOwner(GridCacheMvccManager.java:862)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture$MiniFuture.onResult(GridDhtColocatedLockFuture.java:1412)
> at
> org.a
[jira] [Created] (IGNITE-1905) High contention for CacheLockImpl causes AssertionErrors
Denis Magda created IGNITE-1905:
---
Summary: High contention for CacheLockImpl causes AssertionErrors
Key: IGNITE-1905
URL: https://issues.apache.org/jira/browse/IGNITE-1905
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: ignite-1.4
Environment: Windows 7
Reporter: Denis Magda
Priority: Critical
Fix For: 1.5
When multiple threads, running on the same client node, compete for
CacheLockImpl this leads to AssertionErrors.
Pseudo-code snippet, that is called from multiple threads and causes the
assertions, looks like this:
{noformat}
boolean locked = lock.tryLock(100, TimeUnit.MILLISECONDS);
if (locked)
lock.unlock();
{noformat}
Initially the issue was detected on ignite-1.4.
In server's node logs the following assertion appears
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.addOwned(GridDhtLockFuture.java:958)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:918)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:663)
at
org.apache.ignite.internal.processors.cache.GridCacheMvccManager$2.onOwnerChanged(GridCacheMvccManager.java:155)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.checkOwnerChanged(GridDistributedCacheEntry.java:810)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:516)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:576)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:764)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:973)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:557)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:88)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:132)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:130)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:580)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:198)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:77)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:160)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
at
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
In addition from time to time a client node also outputs a different kind of
assertion:
{noformat}
Exception in thread "ignite-#4%sys-null%" java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.GridCacheExplicitLockSpan.markOwned(GridCacheExplicitLockSpan.java:196)
at
org.apache.ignite.internal.processors.cache.GridCacheMvccManager.markExplicitOwner(GridCacheMvccManager.java:862)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture$MiniFuture.onResult(GridDhtColocatedLockFuture.java:1412)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.onResult(GridDhtColocatedLockFuture.java:437)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.processLockResponse(GridDhtColocatedCache.java:888)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColoc
[jira] [Assigned] (IGNITE-1227) Need to implement Ignite-based Spring transaction manager
[
https://issues.apache.org/jira/browse/IGNITE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amir Akhmedov reassigned IGNITE-1227:
-
Assignee: Valentin Kulichenko (was: Amir Akhmedov)
> Need to implement Ignite-based Spring transaction manager
> -
>
> Key: IGNITE-1227
> URL: https://issues.apache.org/jira/browse/IGNITE-1227
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Labels: newbie
> Attachments: IGNITE-1227.patch
>
>
> This will allow to use Spring transaction interceptor for wrapping cache
> operations into Ignite transaction.
> Essentially, we need to implement Spring's {{PlatformTransactionManager}}
> interface using {{IgniteTransactions}} API.
> Corresponding user list thread:
> http://apache-ignite-users.70518.x6.nabble.com/Transactions-td885.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1904) Need to add two new dependencies in pom-file to cover special cases
Pavel Konstantinov created IGNITE-1904:
--
Summary: Need to add two new dependencies in pom-file to cover
special cases
Key: IGNITE-1904
URL: https://issues.apache.org/jira/browse/IGNITE-1904
Project: Ignite
Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko
If user added Generic JDBC and Secondary file system in cluster configuration,
then the generated java-code contains to RED imports
{code}
import com.mchange.v2.c3p0.jboss.C3P0PooledDataSource;
import org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem;
{code}
We need to add that dependencies to the pom-file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1904) Need to add two new dependencies in pom-file to cover special cases
[
https://issues.apache.org/jira/browse/IGNITE-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov updated IGNITE-1904:
---
Description:
If user added Generic JDBC and Secondary file system in cluster configuration,
then the generated java-code contains two RED imports
{code}
import com.mchange.v2.c3p0.jboss.C3P0PooledDataSource;
import org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem;
{code}
We need to add that dependencies to the pom-file.
was:
If user added Generic JDBC and Secondary file system in cluster configuration,
then the generated java-code contains to RED imports
{code}
import com.mchange.v2.c3p0.jboss.C3P0PooledDataSource;
import org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem;
{code}
We need to add that dependencies to the pom-file.
> Need to add two new dependencies in pom-file to cover special cases
> ---
>
> Key: IGNITE-1904
> URL: https://issues.apache.org/jira/browse/IGNITE-1904
> Project: Ignite
> Issue Type: Sub-task
> Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
> Fix For: 1.5
>
>
> If user added Generic JDBC and Secondary file system in cluster
> configuration, then the generated java-code contains two RED imports
> {code}
> import com.mchange.v2.c3p0.jboss.C3P0PooledDataSource;
> import org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem;
> {code}
> We need to add that dependencies to the pom-file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1877) Add ClassLoaderCodec for OSGI support
[ https://issues.apache.org/jira/browse/IGNITE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Gilles updated IGNITE-1877: -- Assignee: Raúl Kripalani (was: Romain Gilles) > Add ClassLoaderCodec for OSGI support > - > > Key: IGNITE-1877 > URL: https://issues.apache.org/jira/browse/IGNITE-1877 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Dmitriy Setrakyan >Assignee: Raúl Kripalani > Fix For: 1.6 > > > The design is described here: > https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1901) CPP: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003839#comment-15003839
]
ASF GitHub Bot commented on IGNITE-1901:
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/230
IGNITE-1901: Adopted new marshalling flags.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/isapego/ignite ignite-1901
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/230.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 #230
commit 8f868dd482cf571d215f8b7c91a53ee3c451d038
Author: isapego
Date: 2015-11-13T10:37:09Z
IGNITE-1901: New marshalling flags adopted.
> CPP: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1901
> URL: https://issues.apache.org/jira/browse/IGNITE-1901
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to CPP:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1837) Rebalancing on a big cluster (64 nodes and more)
[ https://issues.apache.org/jira/browse/IGNITE-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003820#comment-15003820 ] Pavel Konstantinov commented on IGNITE-1837: >From my side I can add that I'm facing with slow rebalancing when cache type >metadata contains many indexes (30-40). In this case rebalancing the cache >with 1 backupd and 40 millions of keys executes more the 10 minutes when the >second node is starting. > Rebalancing on a big cluster (64 nodes and more) > > > Key: IGNITE-1837 > URL: https://issues.apache.org/jira/browse/IGNITE-1837 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Alexey Goncharuk > Fix For: 1.5 > > > It seems that Ignite has different rebalancing related issues that appear > when a big cluster is started. > Under the big cluster I mean: > - cluster of 64 server nodes; > - cluster of 64 server and 64 client nodes. > The issues can be divided on three main use cases. > 1) Slow rebalancing on start. > - If to set partitions number for some cache to value bigger than default one > (to 3200 or to 6400, etc.) then rebalancing of such caches may take several > minutes. The caches are empty at that time. In addition, as a part of this > issue let's document that the number of partitions can't exceed some value. > - exchange message on NODE_JOINED event that times out for a long time. > Discussed there: > http://apache-ignite-users.70518.x6.nabble.com/Help-with-tuning-for-larger-clusters-td1692.html#a1813 > 2) Slow rebalancing on client nodes shutdown. > If to stop a significant number of client nodes at the same time then again > by some reason the rebalancing will take serveral minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1093) Rebalancing with default parameters is very slow
[ https://issues.apache.org/jira/browse/IGNITE-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-1093: --- Assignee: Sergey Kozlov (was: Pavel Konstantinov) > Rebalancing with default parameters is very slow > > > Key: IGNITE-1093 > URL: https://issues.apache.org/jira/browse/IGNITE-1093 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: sprint-7 >Reporter: Pavel Konstantinov >Assignee: Sergey Kozlov >Priority: Critical > Fix For: 1.5 > > Attachments: Plot_ThroughputLatencyProbe_01.png, rebalancing.zip > > > # Start one node with partitioned cache with one backup. > # Load into the cache 40billions of keys using DataStreamer > # Start second node on the same host -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1890) ignitevisorcmd: description for "-dl" key for "log" command should be updated
[
https://issues.apache.org/jira/browse/IGNITE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko resolved IGNITE-1890.
---
Resolution: Fixed
Assignee: Pavel Konstantinov
> ignitevisorcmd: description for "-dl" key for "log" command should be updated
> -
>
> Key: IGNITE-1890
> URL: https://issues.apache.org/jira/browse/IGNITE-1890
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5
>Reporter: Vasilisa Sidorova
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 1.6
>
>
> -
> DESCRIPTION
> -
> Description for "-dl" key for "log" command is obsoleted
> -
> STEPS FOR REPRODUCE
> -
> # Run ignitevisorcmd from IGNITE_HOME/bin
> # Type "help log"
> -
> ACTUAL RESULT
> -
> The description of "-dl" is:
> {noformat}
> "-dl
> Disables collecting of job and task fail events, licence violation
> events, cache rebalance events from remote nodes."
> {noformat}
> -
> EXPECTED RESULT
> -
> The description of "-dl" is:
> {noformat}
> "-dl
> Disables collecting of job and task fail events, cache rebalance
> events from remote nodes."
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1890) ignitevisorcmd: description for "-dl" key for "log" command should be updated
[
https://issues.apache.org/jira/browse/IGNITE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003781#comment-15003781
]
Vasiliy Sisko commented on IGNITE-1890:
---
Fixed help.
> ignitevisorcmd: description for "-dl" key for "log" command should be updated
> -
>
> Key: IGNITE-1890
> URL: https://issues.apache.org/jira/browse/IGNITE-1890
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5
>Reporter: Vasilisa Sidorova
>Priority: Trivial
> Fix For: 1.6
>
>
> -
> DESCRIPTION
> -
> Description for "-dl" key for "log" command is obsoleted
> -
> STEPS FOR REPRODUCE
> -
> # Run ignitevisorcmd from IGNITE_HOME/bin
> # Type "help log"
> -
> ACTUAL RESULT
> -
> The description of "-dl" is:
> {noformat}
> "-dl
> Disables collecting of job and task fail events, licence violation
> events, cache rebalance events from remote nodes."
> {noformat}
> -
> EXPECTED RESULT
> -
> The description of "-dl" is:
> {noformat}
> "-dl
> Disables collecting of job and task fail events, cache rebalance
> events from remote nodes."
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1902) NET: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003777#comment-15003777
]
ASF GitHub Bot commented on IGNITE-1902:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/229
IGNITE-1902 NET: Adopt new marshalling flags.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-1902
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/229.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 #229
commit 351d64503b8dda4d10b1f13835c18ce134267d99
Author: Pavel Tupitsyn
Date: 2015-11-13T09:12:45Z
wip header
commit 0ff80f97708f5394945489417505e432ed33766f
Author: Pavel Tupitsyn
Date: 2015-11-13T09:17:42Z
wip header
commit 1e36575d7dd870b80017ad3cb349ba9468bb1854
Author: Pavel Tupitsyn
Date: 2015-11-13T09:20:41Z
wip
commit 8b00aabddf8b19634423851de8e67c8f91e07adf
Author: Pavel Tupitsyn
Date: 2015-11-13T09:22:02Z
Fix build
commit b0bdbd93f2407ffb6fefcd7e8802b5d530e2d871
Author: Pavel Tupitsyn
Date: 2015-11-13T09:33:10Z
wip
commit 9134e1bc671a70b7fb1aa67bdfc75082ae8a21ec
Author: Pavel Tupitsyn
Date: 2015-11-13T09:36:47Z
Fix flags calc
> NET: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1902
> URL: https://issues.apache.org/jira/browse/IGNITE-1902
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to NET:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1093) Rebalancing with default parameters is very slow
[ https://issues.apache.org/jira/browse/IGNITE-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003774#comment-15003774 ] Pavel Konstantinov commented on IGNITE-1093: For my test case I don't see any visual performance improvement. In my test case the main problem is cache indexing. When I'm turning off the indexing then preloading finished in 100x faster. I think we may trust Anton's benchmarks results and close this ticket. > Rebalancing with default parameters is very slow > > > Key: IGNITE-1093 > URL: https://issues.apache.org/jira/browse/IGNITE-1093 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: sprint-7 >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Critical > Fix For: 1.5 > > Attachments: Plot_ThroughputLatencyProbe_01.png, rebalancing.zip > > > # Start one node with partitioned cache with one backup. > # Load into the cache 40billions of keys using DataStreamer > # Start second node on the same host -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1901) CPP: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-1901:
---
Assignee: Igor Sapego
> CPP: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1901
> URL: https://issues.apache.org/jira/browse/IGNITE-1901
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to CPP:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (IGNITE-1870) Add aggregation function for Y axes values in TIME_LINE mode
[ https://issues.apache.org/jira/browse/IGNITE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-1870: Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Add aggregation function for Y axes values in TIME_LINE mode > > > Key: IGNITE-1870 > URL: https://issues.apache.org/jira/browse/IGNITE-1870 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 1.5 > > > Add support for: First, Last, Min, Max, Avg, Sum, Count -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1225) HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always fails on public TC
[ https://issues.apache.org/jira/browse/IGNITE-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Shutak closed IGNITE-1225. > HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always > fails on public TC > - > > Key: IGNITE-1225 > URL: https://issues.apache.org/jira/browse/IGNITE-1225 > Project: Ignite > Issue Type: Test >Reporter: Artem Shutak >Assignee: Artem Shutak >Priority: Blocker > Fix For: 1.5 > > > HadoopCommandLineTest testHadoopCommandLine and testHiveCommandLine always > fails on public TC. > See > HadoopCommandLineTest.testHadoopCommandLine > HadoopCommandLineTest.testHiveCommandLine > Need to investigate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1878) Implement support to package manager for vendor libs
[ https://issues.apache.org/jira/browse/IGNITE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003751#comment-15003751 ] ASF GitHub Bot commented on IGNITE-1878: GitHub user Dmitriyff opened a pull request: https://github.com/apache/ignite/pull/228 IGNITE-1878 added jspm as vendor libs packet manager You can merge this pull request into a Git repository by running: $ git pull https://github.com/Dmitriyff/ignite ignite-1878 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/228.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 #228 commit fef16a7d2e91e89a84e07cbdadf8baa890861471 Author: Dmitriyff Date: 2015-11-13T09:16:40Z IGNITE-1878 added jspm as vendor libs packet manager > Implement support to package manager for vendor libs > > > Key: IGNITE-1878 > URL: https://issues.apache.org/jira/browse/IGNITE-1878 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Dmitriyff >Assignee: Dmitriyff > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1870) Add aggregation function for Y axes values in TIME_LINE mode
[ https://issues.apache.org/jira/browse/IGNITE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003752#comment-15003752 ] Pavel Konstantinov commented on IGNITE-1870: 1. change Y-axis label when function was changed - add function name 2. use query "select random() from car" (start agent in test drive slq mode) set AVG as function and manually Execute several times - in my case the second and next executions returns 0 for aggregation 3. after playing with p.2 change function to LAST - no data available, chart does not repaint > Add aggregation function for Y axes values in TIME_LINE mode > > > Key: IGNITE-1870 > URL: https://issues.apache.org/jira/browse/IGNITE-1870 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov > Fix For: 1.5 > > > Add support for: First, Last, Min, Max, Avg, Sum, Count -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-1903:
---
Description:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
was:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{ SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }}
where {{ c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
> CacheStore implementation is serialised to grid clients whether they require
> it or not
> --
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Michael Griggs
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Br
[jira] [Updated] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-1903:
---
Description:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{ SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }}
where {{ c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
was:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
> CacheStore implementation is serialised to grid clients whether they require
> it or not
> --
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Michael Griggs
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Br
[jira] [Created] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
Michael Griggs created IGNITE-1903:
--
Summary: CacheStore implementation is serialised to grid clients
whether they require it or not
Key: IGNITE-1903
URL: https://issues.apache.org/jira/browse/IGNITE-1903
Project: Ignite
Issue Type: Bug
Affects Versions: 1.5
Reporter: Michael Griggs
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1829) We must use short name for packages in metadata dropdown list
[ https://issues.apache.org/jira/browse/IGNITE-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-1829: - Assignee: (was: Vasiliy Sisko) > We must use short name for packages in metadata dropdown list > - > > Key: IGNITE-1829 > URL: https://issues.apache.org/jira/browse/IGNITE-1829 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Priority: Critical > Fix For: 1.6 > > Attachments: ig-1829.png > > > Current view is uncomfortable because user don't see class name. > Please see attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1377) Portable metadata update on changing topology causes hangs in tests
[
https://issues.apache.org/jira/browse/IGNITE-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003737#comment-15003737
]
Vladimir Ozerov commented on IGNITE-1377:
-
Throwing an exception in case of primary node failure looks wrong to me. It
means that user will have to account for distributed failures in virtually
every single line of code, even if he performs only node-local operations.
Probably we should decouple preloading of marshaller cache somehow, and keep
retries because it is always possible to save value to replicated cache.
> Portable metadata update on changing topology causes hangs in tests
> ---
>
> Key: IGNITE-1377
> URL: https://issues.apache.org/jira/browse/IGNITE-1377
> Project: Ignite
> Issue Type: Sub-task
> Components: general, interop
>Reporter: Alexey Goncharuk
>Assignee: Semen Boikov
>Priority: Blocker
> Labels: Muted_test
> Fix For: 1.5
>
>
> I removed metadata update on for objects not defined in configuration (this
> is not an introduced bug, it existed before) because it causes portable
> failover suite to hang.
> Need to investigate further the cause of the hang and unmute
> {{testNoConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002326#comment-15002326 ] Pavel Tupitsyn edited comment on IGNITE-1626 at 11/13/15 8:54 AM: --- * nuspec file created to include all necessary JAR files, Apache.Ignite.Core.dll, and default config file * version is being set automatically from assemblyinfo * IGNITE_HOME resolve logic adjusted to detect NuGet deployment * Package tested locally: no extra steps from the user are required (besides Java installation). Install package => Ignition.Start works. * Package size is 13.5 MB * TC config created to build nupkg: http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet > INFRA team must be asked about a place where NuGet package could be stored. No need for this. Package is created by TC task, tested, and then pushed to nuget.org. was (Author: ptupitsyn): * nuspec file created to include all necessary JAR files, Apache.Ignite.Core.dll, and default config file * version is being set automatically from assemblyinfo * IGNITE_HOME resolve logic adjusted to detect NuGet deployment * Package tested locally: no extra steps from the user are required (besides Java installation). Install package => Ignition.Start works. * Package size is 13.5 MB * TC config created to build nupkg: http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet > INFRA team must be asked about a place where NuGet package could be stored. No need for this. Package is created by TC task, tested, and then pushed to nuget.org. What is left: * proper wording in summary and description * icon > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1626) .Net: Create NuGet package.
[ https://issues.apache.org/jira/browse/IGNITE-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002326#comment-15002326 ] Pavel Tupitsyn edited comment on IGNITE-1626 at 11/13/15 8:54 AM: --- * nuspec file created to include all necessary JAR files, Apache.Ignite.Core.dll, and default config file * version is being set automatically from assemblyinfo * IGNITE_HOME resolve logic adjusted to detect NuGet deployment * Package tested locally: no extra steps from the user are required (besides Java installation). Install package => Ignition.Start works. * Package size is 13.5 MB * TC config created to build nupkg: http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet > INFRA team must be asked about a place where NuGet package could be stored. No need for this. Package is created by TC task, tested, and then pushed to nuget.org. What is left: * proper wording in summary and description * icon was (Author: ptupitsyn): * nuspec file created to include all necessary JAR files, Apache.Ignite.Core.dll, and default config file * version is being set automatically from assemblyinfo * IGNITE_HOME resolve logic adjusted to detect NuGet deployment * Package tested locally: no extra steps from the user are required (besides Java installation). Install package => Ignition.Start works. * TC config created to build nupkg: http://94.72.60.102/viewType.html?buildTypeId=IgniteBuildsAndUploads_IgniteBuildFabricOnlyNet > INFRA team must be asked about a place where NuGet package could be stored. No need for this. Package is created by TC task, tested, and then pushed to nuget.org. What is left: * proper wording in summary and description * icon > .Net: Create NuGet package. > --- > > Key: IGNITE-1626 > URL: https://issues.apache.org/jira/browse/IGNITE-1626 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.5 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Blocker > Fix For: 1.6 > > > *Overview* > To boost usage of the product we need to distribute it using NuGet, which is > tightly integrated with Visual Studio. > To achieve this several technical, infrastructure and marketing tasks must be > completed. > *Technical tasks* > - Apache Ignite.NET heavily depends on relative positions of compiled Java > classes. We must be able to apply different classpath search strategies > depending on packaging. This includes normal search in exploded build > directory, search in NuGet package, search in local Maven repo. > - We need a way to select classpath search strategy. E.g. we can add special > marker resource to NuGet package so that DLL understands that it is > NuGet-based. More investigation here is reuqired. > - Minimal set of required JARs should be defined. Currently we have over > >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of > 30Mb per package. Only vital subset of JARs should be shipped. > *Infrastructure tasks* > - INFRA team must be asked about a place where NuGet package could be stored. > - Separate build plan should be created, producing NuGet artifacts. > *Marketing tasks* > - We need to produce clean, selling and intriguing header and description for > our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1892) Incorrect focus on table fields
[ https://issues.apache.org/jira/browse/IGNITE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-1892. -- Assignee: (was: Pavel Konstantinov) Tested. > Incorrect focus on table fields > --- > > Key: IGNITE-1892 > URL: https://issues.apache.org/jira/browse/IGNITE-1892 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Vasiliy Sisko > Fix For: 1.5 > > > Open metadata configuration dialog. > Configure query fields or aliases or indexes and add more than one row. > On edit second row focus on first field is lost. > Error popover showed in incorrect place. > On enter should be focused next editor or row should be saved -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1902) NET: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-1902:
---
Assignee: Pavel Tupitsyn
> NET: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1902
> URL: https://issues.apache.org/jira/browse/IGNITE-1902
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to NET:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1896) .Net: Improve query API
[
https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003723#comment-15003723
]
Pavel Tupitsyn commented on IGNITE-1896:
-
1) I don't propose to remove current method altogether, I propose to complement
it with more usable methods. If arguments are added, API won't be broken. We
can keep simple methods for simple scenarios, and current approach for higher
customization
2) There is a problem. When you use a dictionary, you have to specify generic
arguments only once, in constructor. Then you never have to do it again:
{code}
var dict = new Dictionary();
dict[1] = new Person(); // No generic arguments
var person = dict[1]; // No generic arguments
{code}
Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache(); // generic arguments specified
once, this is fine
var person = cache.Get(1); // no generic arguments, good
// Why do we force user to specify typeof(Person)? Cache already knows this
type.
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)
// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}
Same issue we had with GetFuture. Too much typing, prone to errors, makes
refactoring hard.
> .Net: Improve query API
> ---
>
> Key: IGNITE-1896
> URL: https://issues.apache.org/jira/browse/IGNITE-1896
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type
> explicitly.
> There are cases when query type is a string and/or is different from current
> cache generic type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
> IQueryCursor> ScanQuery(ICacheEntryFilter
> filter);
> IQueryCursor> SqlQuery(string sql, params
> object[] args);
> IQueryCursor> SqlQuery(string sql, bool local,
> params object[] args);
> IQueryCursor> TextQuery(string text);
> IQueryCursor> TextQuery(string text, bool local);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1896) .Net: Improve query API
[
https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003723#comment-15003723
]
Pavel Tupitsyn edited comment on IGNITE-1896 at 11/13/15 8:44 AM:
---
1) I don't propose to remove current method altogether, I propose to complement
it with more usable methods. If arguments are added, API won't be broken. We
can keep simple methods for simple scenarios, and current approach for higher
customization
2) There is a problem. When you use a dictionary, you have to specify generic
arguments only once, in constructor. Then you never have to do it again, no
chance to make a mistake:
{code}
var dict = new Dictionary();
dict[1] = new Person(); // No generic arguments
var person = dict[1]; // No generic arguments
{code}
Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache(); // generic arguments specified
once, this is fine
var person = cache.Get(1); // no generic arguments, good
// Why do we force user to specify typeof(Person)? Cache already knows this
type.
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)
// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}
Same issue we had with GetFuture. Too much typing, prone to errors, makes
refactoring hard.
was (Author: ptupitsyn):
1) I don't propose to remove current method altogether, I propose to complement
it with more usable methods. If arguments are added, API won't be broken. We
can keep simple methods for simple scenarios, and current approach for higher
customization
2) There is a problem. When you use a dictionary, you have to specify generic
arguments only once, in constructor. Then you never have to do it again:
{code}
var dict = new Dictionary();
dict[1] = new Person(); // No generic arguments
var person = dict[1]; // No generic arguments
{code}
Same with put/get in our cache, no problem there.
But with queries:
{code}
var cache = ignite.GetCache(); // generic arguments specified
once, this is fine
var person = cache.Get(1); // no generic arguments, good
// Why do we force user to specify typeof(Person)? Cache already knows this
type.
// And there will be an exception if the user specifies wrong type
var sqlQuery = cache.Query(new SqlQuery(typeof (Person), "Age > ?", 5));
// Much cleaner, isn't it?
var sqlQuery = cache.SqlQuery("Age > ?", 5)
// Again, why do we force user to type so much? Generic arguments are known.
var scanQuery = cache.Query(new ScanQuery());
// Compare to:
var scanQuery = cache.ScanQuery();
{code}
Same issue we had with GetFuture. Too much typing, prone to errors, makes
refactoring hard.
> .Net: Improve query API
> ---
>
> Key: IGNITE-1896
> URL: https://issues.apache.org/jira/browse/IGNITE-1896
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type
> explicitly.
> There are cases when query type is a string and/or is different from current
> cache generic type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
> IQueryCursor> ScanQuery(ICacheEntryFilter
> filter);
> IQueryCursor> SqlQuery(string sql, params
> object[] args);
> IQueryCursor> SqlQuery(string sql, bool local,
> params object[] args);
> IQueryCursor> TextQuery(string text);
> IQueryCursor> TextQuery(string text, bool local);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1892) Incorrect focus on table fields
[ https://issues.apache.org/jira/browse/IGNITE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko resolved IGNITE-1892. --- Resolution: Fixed Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Incorrect focus on table fields > --- > > Key: IGNITE-1892 > URL: https://issues.apache.org/jira/browse/IGNITE-1892 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 1.5 > > > Open metadata configuration dialog. > Configure query fields or aliases or indexes and add more than one row. > On edit second row focus on first field is lost. > Error popover showed in incorrect place. > On enter should be focused next editor or row should be saved -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1892) Incorrect focus on table fields
[ https://issues.apache.org/jira/browse/IGNITE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003716#comment-15003716 ] Vasiliy Sisko commented on IGNITE-1892: --- Fixed editors in table fields. To check: adding, removing, editing of all table fields. > Incorrect focus on table fields > --- > > Key: IGNITE-1892 > URL: https://issues.apache.org/jira/browse/IGNITE-1892 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 1.5 > > > Open metadata configuration dialog. > Configure query fields or aliases or indexes and add more than one row. > On edit second row focus on first field is lost. > Error popover showed in incorrect place. > On enter should be focused next editor or row should be saved -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1901) CPP: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003714#comment-15003714
]
Vladimir Ozerov commented on IGNITE-1901:
-
Please create a branch from IGNITE-1816.
> CPP: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1901
> URL: https://issues.apache.org/jira/browse/IGNITE-1901
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to CPP:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1902) NET: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003713#comment-15003713
]
Vladimir Ozerov commented on IGNITE-1902:
-
Please create a branch from IGNITE-1816.
> NET: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1902
> URL: https://issues.apache.org/jira/browse/IGNITE-1902
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to NET:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1902) NET: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1902:
Description:
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to .NET:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
was:
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to CPP:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
> NET: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1902
> URL: https://issues.apache.org/jira/browse/IGNITE-1902
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to .NET:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1902) NET: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-1902:
Description:
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to NET:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
was:
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to .NET:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
> NET: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1902
> URL: https://issues.apache.org/jira/browse/IGNITE-1902
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to NET:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1902) NET: Adopt new marshalling flags.
Vladimir Ozerov created IGNITE-1902:
---
Summary: NET: Adopt new marshalling flags.
Key: IGNITE-1902
URL: https://issues.apache.org/jira/browse/IGNITE-1902
Project: Ignite
Issue Type: Sub-task
Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 1.5
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to CPP:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1901) CPP: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-1901:
Issue Type: Sub-task (was: Bug)
Parent: IGNITE-1816
> CPP: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1901
> URL: https://issues.apache.org/jira/browse/IGNITE-1901
> Project: Ignite
> Issue Type: Sub-task
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to CPP:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1901) CPP: Adopt new marshalling flags.
[
https://issues.apache.org/jira/browse/IGNITE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-1901:
Issue Type: Bug (was: Sub-task)
Parent: (was: IGNITE-1847)
> CPP: Adopt new marshalling flags.
> -
>
> Key: IGNITE-1901
> URL: https://issues.apache.org/jira/browse/IGNITE-1901
> Project: Ignite
> Issue Type: Bug
> Components: interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.5
>
>
> As a part of IGNITE-1816 I had to revisit our flags. Here are how they look
> now:
> {code}
> /** Flag: user type. */
> public static final short FLAG_USR_TYP = 0x0001;
> /** Flag: schema exists. */
> public static final short FLAG_HAS_SCHEMA = 0x0002;
> /** Flag indicating that object has raw data. */
> public static final short FLAG_HAS_RAW = 0x0004;
> /** Flag: offsets take 1 byte. */
> public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
> /** Flag: offsets take 2 bytes. */
> public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
> /** Flag: compact footer, no field IDs. */
> public static final short FLAG_COMPACT_FOOTER = 0x0020;
> {code}
> The following changes must be made to CPP:
> 1) When schema exists (i.e. at least on non-raw fieid was written), HAS_
> SCHEMA flag is set to true. This is the inversed version of what previously
> was "RAW_ONLY".
> 2) When raw data exists, HAS_RAW flag is set to true. This flag should be
> used to determine location of raw data.
> *DO NOT USE % for this anymore!*
> 3) For now COMPACT_FOOTER should always be 0. If you receive an object with
> this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1901) CPP: Adopt new marshalling flags.
Vladimir Ozerov created IGNITE-1901:
---
Summary: CPP: Adopt new marshalling flags.
Key: IGNITE-1901
URL: https://issues.apache.org/jira/browse/IGNITE-1901
Project: Ignite
Issue Type: Sub-task
Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 1.5
As a part of IGNITE-1816 I had to revisit our flags. Here are how they look now:
{code}
/** Flag: user type. */
public static final short FLAG_USR_TYP = 0x0001;
/** Flag: schema exists. */
public static final short FLAG_HAS_SCHEMA = 0x0002;
/** Flag indicating that object has raw data. */
public static final short FLAG_HAS_RAW = 0x0004;
/** Flag: offsets take 1 byte. */
public static final short FLAG_OFFSET_ONE_BYTE = 0x0008;
/** Flag: offsets take 2 bytes. */
public static final short FLAG_OFFSET_TWO_BYTES = 0x0010;
/** Flag: compact footer, no field IDs. */
public static final short FLAG_COMPACT_FOOTER = 0x0020;
{code}
The following changes must be made to CPP:
1) When schema exists (i.e. at least on non-raw fieid was written), HAS_ SCHEMA
flag is set to true. This is the inversed version of what previously was
"RAW_ONLY".
2) When raw data exists, HAS_RAW flag is set to true. This flag should be used
to determine location of raw data.
*DO NOT USE % for this anymore!*
3) For now COMPACT_FOOTER should always be 0. If you receive an object with
this flag set to 1, an exception must be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1227) Need to implement Ignite-based Spring transaction manager
[ https://issues.apache.org/jira/browse/IGNITE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003704#comment-15003704 ] tc_commenter commented on IGNITE-1227: -- There was triggered next test builds for last attached patch-file: 01. http://ci.ignite.apache.org/viewQueued.html?itemId=117935 - Ignite 150 Clients 02. http://ci.ignite.apache.org/viewQueued.html?itemId=117936 - Ignite AOP 03. http://ci.ignite.apache.org/viewQueued.html?itemId=117937 - Ignite AWS 04. http://ci.ignite.apache.org/viewQueued.html?itemId=117938 - Ignite Basic 05. http://ci.ignite.apache.org/viewQueued.html?itemId=117939 - Ignite Cache 06. http://ci.ignite.apache.org/viewQueued.html?itemId=117940 - Ignite Cache 2 07. http://ci.ignite.apache.org/viewQueued.html?itemId=117941 - Ignite Cache 3 08. http://ci.ignite.apache.org/viewQueued.html?itemId=117942 - Ignite Cache 4 09. http://ci.ignite.apache.org/viewQueued.html?itemId=117943 - Ignite Cache 5 10. http://ci.ignite.apache.org/viewQueued.html?itemId=117944 - Ignite Cache Expiry Policy 11. http://ci.ignite.apache.org/viewQueued.html?itemId=117945 - Ignite Cache Failover 12. http://ci.ignite.apache.org/viewQueued.html?itemId=117946 - Ignite Cache Failover Multi JVM 13. http://ci.ignite.apache.org/viewQueued.html?itemId=117947 - Ignite Cache Failover2 14. http://ci.ignite.apache.org/viewQueued.html?itemId=117948 - Ignite Cache Failover3 15. http://ci.ignite.apache.org/viewQueued.html?itemId=117949 - Ignite Cache Full API 16. http://ci.ignite.apache.org/viewQueued.html?itemId=117950 - Ignite Cache Full API Multi JVM 17. http://ci.ignite.apache.org/viewQueued.html?itemId=117951 - Ignite Cache Full API Portable 18. http://ci.ignite.apache.org/viewQueued.html?itemId=117952 - Ignite Cache Portable 19. http://ci.ignite.apache.org/viewQueued.html?itemId=117953 - Ignite Cache Query Portable 20. http://ci.ignite.apache.org/viewQueued.html?itemId=117954 - Ignite Cache Restarts 21. http://ci.ignite.apache.org/viewQueued.html?itemId=117955 - Ignite Cache Restarts2 22. http://ci.ignite.apache.org/viewQueued.html?itemId=117956 - Ignite Cache Tx Recovery 23. http://ci.ignite.apache.org/viewQueued.html?itemId=117957 - Ignite Client Nodes 24. http://ci.ignite.apache.org/viewQueued.html?itemId=117958 - Ignite Cloud 25. http://ci.ignite.apache.org/viewQueued.html?itemId=117959 - Ignite Compute Grid 26. http://ci.ignite.apache.org/viewQueued.html?itemId=117960 - Ignite Data Strucutures 27. http://ci.ignite.apache.org/viewQueued.html?itemId=117961 - Ignite Examples 28. http://ci.ignite.apache.org/viewQueued.html?itemId=117962 - Ignite GCE 29. http://ci.ignite.apache.org/viewQueued.html?itemId=117963 - Ignite Geospacial Indexing 30. http://ci.ignite.apache.org/viewQueued.html?itemId=117964 - Ignite H2 Indexing 31. http://ci.ignite.apache.org/viewQueued.html?itemId=117965 - Ignite Hadoop 32. http://ci.ignite.apache.org/viewQueued.html?itemId=117966 - Ignite Hibernate 33. http://ci.ignite.apache.org/viewQueued.html?itemId=117967 - Ignite IGFS 34. http://ci.ignite.apache.org/viewQueued.html?itemId=117968 - Ignite IGFS Examples 35. http://ci.ignite.apache.org/viewQueued.html?itemId=117969 - Ignite IGFS Linux and MacOS 36. http://ci.ignite.apache.org/viewQueued.html?itemId=117970 - Ignite Indexed Objects Cache 37. http://ci.ignite.apache.org/viewQueued.html?itemId=117971 - Ignite Indexed Objects Cache 2 38. http://ci.ignite.apache.org/viewQueued.html?itemId=117972 - Ignite Indexed Objects Cache 3 39. http://ci.ignite.apache.org/viewQueued.html?itemId=117973 - Ignite Indexed Objects Cache 4 40. http://ci.ignite.apache.org/viewQueued.html?itemId=117974 - Ignite Indexed Objects Cache Expiry Policy 41. http://ci.ignite.apache.org/viewQueued.html?itemId=117975 - Ignite Indexed Objects Cache Failover 42. http://ci.ignite.apache.org/viewQueued.html?itemId=117976 - Ignite Indexed Objects Cache Failover2 43. http://ci.ignite.apache.org/viewQueued.html?itemId=117977 - Ignite Indexed Objects Cache Full API 44. http://ci.ignite.apache.org/viewQueued.html?itemId=117978 - Ignite Indexed Objects Cache Restarts 45. http://ci.ignite.apache.org/viewQueued.html?itemId=117979 - Ignite Indexed Objects Data Strucutures 46. http://ci.ignite.apache.org/viewQueued.html?itemId=117980 - Ignite Indexed Objects Queries 47. http://ci.ignite.apache.org/viewQueued.html?itemId=117981 - Ignite Java Client 48. http://ci.ignite.apache.org/viewQueued.html?itemId=117982 - Ignite JDBC Driver 49. http://ci.ignite.apache.org/viewQueued.html?itemId=117983 - Ignite JTA 50. http://ci.ignite.apache.org/viewQueued.html?itemId=117984 - Ignite Logging 51. http://ci.ignite.apache.org/viewQueued.html?itemId=117985 - Ignite Portables Basic 52. http://ci.ignite.apache.org/viewQueued.html?itemId=117986 - Ignite Queries 53. http://ci.ignite.apache.org/viewQueued.html?itemId=117987 - Ignite Queries Portable 54. http://ci.ignite.apache.org/v
[jira] [Commented] (IGNITE-1896) .Net: Improve query API
[
https://issues.apache.org/jira/browse/IGNITE-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003700#comment-15003700
]
Vladimir Ozerov commented on IGNITE-1896:
-
I do not think we should do anything here for several reasons:
1) We had similar approach in Java before, but decided to switch to current
model when all query arguments are kept inside an object. This allowed us to
have less methods on public API. What is more important, this design survives
changes gracefullly. E.g., if some new argument is added to query object, no
API changes is needed.
2) I do not see a problem with generics either. This is a standard way how they
used. See IDictionary API for example.
> .Net: Improve query API
> ---
>
> Key: IGNITE-1896
> URL: https://issues.apache.org/jira/browse/IGNITE-1896
> Project: Ignite
> Issue Type: Improvement
> Components: interop
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Current API is very clumsy.
> Cache is generic, however we require the user to specify query type
> explicitly.
> There are cases when query type is a string and/or is different from current
> cache generic type, so the current API has to be kept.
> However, we should provide simple methods with generic inference:
> {code}
> IQueryCursor> ScanQuery(ICacheEntryFilter
> filter);
> IQueryCursor> SqlQuery(string sql, params
> object[] args);
> IQueryCursor> SqlQuery(string sql, bool local,
> params object[] args);
> IQueryCursor> TextQuery(string text);
> IQueryCursor> TextQuery(string text, bool local);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1227) Need to implement Ignite-based Spring transaction manager
[
https://issues.apache.org/jira/browse/IGNITE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amir Akhmedov updated IGNITE-1227:
--
Attachment: IGNITE-1227.patch
> Need to implement Ignite-based Spring transaction manager
> -
>
> Key: IGNITE-1227
> URL: https://issues.apache.org/jira/browse/IGNITE-1227
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
> Labels: newbie
> Attachments: IGNITE-1227.patch
>
>
> This will allow to use Spring transaction interceptor for wrapping cache
> operations into Ignite transaction.
> Essentially, we need to implement Spring's {{PlatformTransactionManager}}
> interface using {{IgniteTransactions}} API.
> Corresponding user list thread:
> http://apache-ignite-users.70518.x6.nabble.com/Transactions-td885.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-529) Implement IgniteFlumeStreamer to stream data from Apache Flume
[
https://issues.apache.org/jira/browse/IGNITE-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003695#comment-15003695
]
Roman Shtykh commented on IGNITE-529:
-
Anton,
I have changed an implementation according to what was discussed and updated PR.
In addition, I have introduced batching for performance and Flume sink counter
for monitoring.
> Implement IgniteFlumeStreamer to stream data from Apache Flume
> --
>
> Key: IGNITE-529
> URL: https://issues.apache.org/jira/browse/IGNITE-529
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Roman Shtykh
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Flume|http://flume.apache.org/] for more information.
> We should create {{IgniteFlumeStreamer}} which will consume messages from
> Apache Flume and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert Flume data to Ignite data using an optional pluggable converter.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1870) Add aggregation function for Y axes values in TIME_LINE mode
[ https://issues.apache.org/jira/browse/IGNITE-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-1870. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Implemented support for aggregation functions over returned result set. Aggregation is implemented only for current fetched page. Available and visible only in TIME_LINE mode. Please test. > Add aggregation function for Y axes values in TIME_LINE mode > > > Key: IGNITE-1870 > URL: https://issues.apache.org/jira/browse/IGNITE-1870 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.5 >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov > Fix For: 1.5 > > > Add support for: First, Last, Min, Max, Avg, Sum, Count -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1867) Fix java class names and package declaration
[ https://issues.apache.org/jira/browse/IGNITE-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko resolved IGNITE-1867. --- Resolution: Fixed Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Fix java class names and package declaration > > > Key: IGNITE-1867 > URL: https://issues.apache.org/jira/browse/IGNITE-1867 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Prachi Garg >Assignee: Pavel Konstantinov > Fix For: 1.5 > > > I noticed a few issues when I imported my project, created using the web > console, in IDEA - > 1. ServerConfigurationFactory class name is create in the file called > “ConfigurationFactory.java”. Class name and file name should be the same. > 2. The package declaration for ClientConfigurationFactory and > SeverConfigurationFactory classes is missing. > 3. There should be simple 'nodeStartup' class for starting a node, in the > IDE, using the XML configuration file. > 4. Missing near configuration for client in java code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1867) Fix java class names and package declaration
[ https://issues.apache.org/jira/browse/IGNITE-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15001889#comment-15001889 ] Vasiliy Sisko edited comment on IGNITE-1867 at 11/13/15 8:06 AM: - Removed deprecated random eviction policy. Implemented generation of near caches in generated java factory class. was (Author: vsisko): Removed deprecated random eviction policy > Fix java class names and package declaration > > > Key: IGNITE-1867 > URL: https://issues.apache.org/jira/browse/IGNITE-1867 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Prachi Garg >Assignee: Vasiliy Sisko > Fix For: 1.5 > > > I noticed a few issues when I imported my project, created using the web > console, in IDEA - > 1. ServerConfigurationFactory class name is create in the file called > “ConfigurationFactory.java”. Class name and file name should be the same. > 2. The package declaration for ClientConfigurationFactory and > SeverConfigurationFactory classes is missing. > 3. There should be simple 'nodeStartup' class for starting a node, in the > IDE, using the XML configuration file. > 4. Missing near configuration for client in java code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
