[jira] [Resolved] (IGNITE-2778) implemente support to include jade for jspm
[ https://issues.apache.org/jira/browse/IGNITE-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriyff resolved IGNITE-2778. --- Resolution: Fixed Assignee: Alexey Kuznetsov (was: Dmitriyff) > implemente support to include jade for jspm > --- > > Key: IGNITE-2778 > URL: https://issues.apache.org/jira/browse/IGNITE-2778 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriyff >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2789) Fix dropdown placeholder
Dmitriyff created IGNITE-2789: - Summary: Fix dropdown placeholder Key: IGNITE-2789 URL: https://issues.apache.org/jira/browse/IGNITE-2789 Project: Ignite Issue Type: Sub-task Reporter: Dmitriyff Assignee: Dmitriyff -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2790) LGPL CacheHibernateStoreExample fails if it runs w/o IDEA
Sergey Kozlov created IGNITE-2790:
-
Summary: LGPL CacheHibernateStoreExample fails if it runs w/o IDEA
Key: IGNITE-2790
URL: https://issues.apache.org/jira/browse/IGNITE-2790
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.5.0.final
Reporter: Sergey Kozlov
1. Build and package examples via maven:
{noformat}
c:\Work>cd examples
c:\Work\examples>mvn clean package -Plgpl
{noformat}
2. Copy example jar in {{libs}} directory
3. Run CachePutGetExample to make sure that it works
{noformat}
c:\Work>c:\java\jdk1.7.0_80\bin\java -cp c:\Work\libs\
*;C:\Work\libs\ignite-indexing\*;C:\Work\libs\ignite-s
pring\* org.apache.ignite.examples.datagrid.CachePutGetExample
...
[11:04:06] Topology snapshot [ver=1, servers=1, clients=0, C
>>> Cache put-get example started.
>>> Stored values in cache.
Got [key=0, val=0]
Got [key=1, val=1]
Got [key=2, val=2]
Got [key=3, val=3]
Got [key=4, val=4]
Got [key=5, val=5]
Got [key=6, val=6]
Got [key=7, val=7]
Got [key=8, val=8]
Got [key=9, val=9]
Got [key=10, val=10]
Got [key=11, val=11]
Got [key=12, val=12]
Got [key=13, val=13]
Got [key=14, val=14]
Got [key=15, val=15]
Got [key=16, val=16]
Got [key=17, val=17]
Got [key=18, val=18]
Got [key=19, val=19]
>>> Starting putAll-getAll example.
>>> Bulk-stored values in cache.
Got entry [key=0, val=bulk-0]
Got entry [key=1, val=bulk-1]
Got entry [key=2, val=bulk-2]
Got entry [key=3, val=bulk-3]
Got entry [key=4, val=bulk-4]
Got entry [key=5, val=bulk-5]
Got entry [key=6, val=bulk-6]
Got entry [key=7, val=bulk-7]
Got entry [key=8, val=bulk-8]
Got entry [key=9, val=bulk-9]
Got entry [key=10, val=bulk-10]
Got entry [key=11, val=bulk-11]
Got entry [key=12, val=bulk-12]
Got entry [key=13, val=bulk-13]
Got entry [key=14, val=bulk-14]
Got entry [key=15, val=bulk-15]
Got entry [key=17, val=bulk-17]
Got entry [key=16, val=bulk-16]
Got entry [key=19, val=bulk-19]
Got entry [key=18, val=bulk-18]
[11:04:06] Ignite node stopped OK [uptime=00:00:00:254]
{noformat}
4. Copy directory {{libs/optional/ignite-hibernate}} in {{libs/}}
5. Run CacheHibernateStoreExample. It fails with ClassNotFoundException:
{noformat}
c:\Work>c:\java\jdk1.7.0_80\bin\java -cp c:\Work\libs\
*;C:\Work\libs\ignite-indexing\*;C:\Work\libs\ignite-s
pring\*;C:\Work\libs\ignite-hibernate\*
org.apache.ignite.examples.datagrid.store.hiber
nate.CacheHibernateStoreExample
[11:06:38]__
[11:06:38] / _/ ___/ |/ / _/_ __/ __/
[11:06:38] _/ // (7 7// / / / / _/
[11:06:38] /___/\___/_/|_/___/ /_/ /___/
[11:06:38]
...
[11:06:51] Ignite node started OK (id=16d64392)
[11:06:51] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=3.5GB]
>>> Cache store example started.
[11:06:51,926][SEVERE][exchange-worker-#49%null%][GridDhtPartitionsExchangeFuture]
Failed to reinitialize local partitio
ns (preloading will be stopped): GridDhtPartitionExchangeId
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], n
odeId=16d64392, evt=DISCOVERY_CUSTOM_EVT]
java.lang.NoClassDefFoundError:
org/hibernate/annotations/common/reflection/ReflectionManager
at
org.apache.ignite.cache.store.hibernate.CacheHibernateStoreSessionListener.start(CacheHibernateStoreSessionLi
stener.java:161)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.startStoreSessionListeners(GridCacheUtils.java:171
2)
at
org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.start0(GridCacheStoreManagerAd
apter.java:213)
at
org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:64)
at
org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1042)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1639
)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCachesStart(GridCacheProcessor.java:155
4)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.startCa
ches(GridDhtPartitionsExchangeFuture.java:960)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(Gr
idDhtPartitionsExchangeFuture.java:523)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePa
rtitionExchangeManager.java:1297)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException:
org.hibernate.annotations.common.reflection.ReflectionManager
at java.net.URLClassLoader$1.run(URLC
[jira] [Commented] (IGNITE-2788) Redis API for Ignite to work with data via the Redis protocol
[ https://issues.apache.org/jira/browse/IGNITE-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188943#comment-15188943 ] Dmitriy Setrakyan commented on IGNITE-2788: --- This is a great idea! I would break this task into multiple phases - we should not try to be fully compatible right away. Roman, would you be interested in this task? > Redis API for Ignite to work with data via the Redis protocol > - > > Key: IGNITE-2788 > URL: https://issues.apache.org/jira/browse/IGNITE-2788 > Project: Ignite > Issue Type: New Feature >Reporter: Roman Shtykh > > Introduce Redis API that works with the Redis protocol but uses Ignite grid. > Needless to say, Redis is an extremely popular caching solution. Such API > will enable smooth migration to Ignite. > As a first phase we can start with most frequently used commands and enhance > gradually. > Redis commands http://redis.io/commands -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2690) Format of uptime for metrics
[
https://issues.apache.org/jira/browse/IGNITE-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189004#comment-15189004
]
Denis Magda commented on IGNITE-2690:
-
[~alpert], I've provided you with contributors rights in JIRA. Please try to
assign ticket on yourself and change the ticket's status.
> Format of uptime for metrics
>
>
> Key: IGNITE-2690
> URL: https://issues.apache.org/jira/browse/IGNITE-2690
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Priority: Trivial
> Labels: newbie
> Attachments: master_baa1312_IGNITE-2690.patch
>
>
> Milliseconds of uptime from metrics should be properly formatted (3 digits):
> {noformat}
> [16:35:08,994][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:04:00:996]
> ...
> [16:36:09,011][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:05:01:14]
> {noformat}
> :14 -> :014
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2756) StreamVisitorExample returns empty result set
[
https://issues.apache.org/jira/browse/IGNITE-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov updated IGNITE-2756:
--
Assignee: Vasilisa Sidorova (was: Sergey Kozlov)
> StreamVisitorExample returns empty result set
> -
>
> Key: IGNITE-2756
> URL: https://issues.apache.org/jira/browse/IGNITE-2756
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>Assignee: Vasilisa Sidorova
>
> 1. Start {{ExampleNodeStartup}}
> 2. Start {{StreamVisitorExample}}
> {noformat}
> [15:31:22] Ignite node started OK (id=4395613e)
> [15:31:22] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=7.1GB]
> Number of tuples streamed into Ignite: 50
> Number of tuples streamed into Ignite: 100
> ...
> Number of tuples streamed into Ignite: 950
> Number of tuples streamed into Ignite: 1000
> Top performing financial instruments:
> Query result set is empty.
> [15:31:47] Ignite node stopped OK [uptime=00:00:25:209]
> Process finished with exit code 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2753) Binary object might be deserialized unexpectedly when cache store is enabled.
[
https://issues.apache.org/jira/browse/IGNITE-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2753.
---
> Binary object might be deserialized unexpectedly when cache store is enabled.
> -
>
> Key: IGNITE-2753
> URL: https://issues.apache.org/jira/browse/IGNITE-2753
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Labels: community, customer, important
> Fix For: 1.6
>
>
> *Problem*
> See {{GridCacheMapEntry}} class. There are lots of calls to store like this:
> {code}
> cctx.store().put(null, keyValue(false), CU.value(val, cctx, false), ver);
> {code}
> When {{keyValue()}} is called, it might force object deserialization. And if
> there is no class on the server, the following exception might appear:
> {code}
> g.apache.ignite.binary.BinaryInvalidTypeException: XXX
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:558)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1442)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:542)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.keyValue(GridCacheMapEntry.java:1261)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3326)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:1598)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
> ~[ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:304)
> [ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:49)
> [ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:79)
> [ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
> [ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> [ignite-core-1.5.7.jar:1.5.7]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
> [ignite-core-1.5.7.jar:1.5.7]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_51]
> {code}
> *Proposed solution*
> Pass key and value directly to store manager. It should already handle
> everything correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2791) Continuous query listener is not notified during concurrent key put.
[ https://issues.apache.org/jira/browse/IGNITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2791: Attachment: CacheListenersKillingMe3Main.java > Continuous query listener is not notified during concurrent key put. > > > Key: IGNITE-2791 > URL: https://issues.apache.org/jira/browse/IGNITE-2791 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Nikolay Tikhonov >Priority: Critical > Fix For: 1.6 > > Attachments: CacheListenersKillingMe3Main.java > > > Attached the code reproducing the problem. What is evident from the log, is > that that filter was invoked, but the listener was not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2791) Continuous query listener is not notified during concurrent key put.
Vladimir Ozerov created IGNITE-2791: --- Summary: Continuous query listener is not notified during concurrent key put. Key: IGNITE-2791 URL: https://issues.apache.org/jira/browse/IGNITE-2791 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Nikolay Tikhonov Priority: Critical Fix For: 1.6 Attachments: CacheListenersKillingMe3Main.java Attached the code reproducing the problem. What is evident from the log, is that that filter was invoked, but the listener was not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2792) System caches should not use user-defined TransactionConfiguration.
Vladimir Ozerov created IGNITE-2792: --- Summary: System caches should not use user-defined TransactionConfiguration. Key: IGNITE-2792 URL: https://issues.apache.org/jira/browse/IGNITE-2792 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Semen Boikov Priority: Critical Fix For: 1.6 *Problem* Currently if user set his custom TransactionConfiguration, it will be used not only user public caches, but by internal Ignite caches as well. This could lead to some bad situations, such a transaction timeouts, optimistic exceptions, etc.. *Proposed solution* Ensure that transactional system caches do not use custom TransactionConfiguraton. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2690) Format of uptime for metrics
[
https://issues.apache.org/jira/browse/IGNITE-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alpet Tekinalp reassigned IGNITE-2690:
--
Assignee: Alpet Tekinalp
> Format of uptime for metrics
>
>
> Key: IGNITE-2690
> URL: https://issues.apache.org/jira/browse/IGNITE-2690
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Sergey Kozlov
>Assignee: Alpet Tekinalp
>Priority: Trivial
> Labels: newbie
> Attachments: master_baa1312_IGNITE-2690.patch
>
>
> Milliseconds of uptime from metrics should be properly formatted (3 digits):
> {noformat}
> [16:35:08,994][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:04:00:996]
> ...
> [16:36:09,011][INFO][grid-timeout-worker-#33%null%][IgniteKernal]
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=fcc9d9ca, name=null, uptime=01:05:01:14]
> {noformat}
> :14 -> :014
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2700) GridClosureProcessor internal closures are [de]serialized by OptimizedMarshaller even if BinaryMarshaller is configured
[ https://issues.apache.org/jira/browse/IGNITE-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2700. --- > GridClosureProcessor internal closures are [de]serialized by > OptimizedMarshaller even if BinaryMarshaller is configured > --- > > Key: IGNITE-2700 > URL: https://issues.apache.org/jira/browse/IGNITE-2700 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 1.5.0.final >Reporter: Ilya Lantukh >Assignee: Vladimir Ozerov > Labels: community > Fix For: 1.6 > > > Usage of OptimizedMarshaller is forced because: > a. Closures implement Externalizable. > b. classnames.properties file contains closure class names. > Need to implement new versions of closures (C1, C1MLA, C2, C2MLA, C4) that > can be processed by BinaryMarshaller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2700) GridClosureProcessor internal closures are [de]serialized by OptimizedMarshaller even if BinaryMarshaller is configured
[ https://issues.apache.org/jira/browse/IGNITE-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189221#comment-15189221 ] ASF GitHub Bot commented on IGNITE-2700: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/518 > GridClosureProcessor internal closures are [de]serialized by > OptimizedMarshaller even if BinaryMarshaller is configured > --- > > Key: IGNITE-2700 > URL: https://issues.apache.org/jira/browse/IGNITE-2700 > Project: Ignite > Issue Type: Bug > Components: compute >Affects Versions: 1.5.0.final >Reporter: Ilya Lantukh >Assignee: Vladimir Ozerov > Labels: community > Fix For: 1.6 > > > Usage of OptimizedMarshaller is forced because: > a. Closures implement Externalizable. > b. classnames.properties file contains closure class names. > Need to implement new versions of closures (C1, C1MLA, C2, C2MLA, C4) that > can be processed by BinaryMarshaller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2764) LINQ plan caching
[ https://issues.apache.org/jira/browse/IGNITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-2764: -- Assignee: Pavel Tupitsyn > LINQ plan caching > - > > Key: IGNITE-2764 > URL: https://issues.apache.org/jira/browse/IGNITE-2764 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Investigate EF/NHibernate: how do they calculate cache key from expression > tree to cache query plan? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2764) LINQ plan caching
[ https://issues.apache.org/jira/browse/IGNITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189263#comment-15189263 ] Pavel Tupitsyn commented on IGNITE-2764: * EF walks the expression tree and generates a string key for caching * caching can be disabled globally or for a specific query > LINQ plan caching > - > > Key: IGNITE-2764 > URL: https://issues.apache.org/jira/browse/IGNITE-2764 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Investigate EF/NHibernate: how do they calculate cache key from expression > tree to cache query plan? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2764) LINQ plan caching
[ https://issues.apache.org/jira/browse/IGNITE-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189263#comment-15189263 ] Pavel Tupitsyn edited comment on IGNITE-2764 at 3/10/16 1:48 PM: - * EF walks the expression tree and generates a string key for caching * caching can be disabled globally or for a specific query * NH reuses ReLinq visitor to generate key, we should go the same way: https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate/Linq/NhLinqExpression.cs was (Author: ptupitsyn): * EF walks the expression tree and generates a string key for caching * caching can be disabled globally or for a specific query > LINQ plan caching > - > > Key: IGNITE-2764 > URL: https://issues.apache.org/jira/browse/IGNITE-2764 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Investigate EF/NHibernate: how do they calculate cache key from expression > tree to cache query plan? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
[ https://issues.apache.org/jira/browse/IGNITE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189381#comment-15189381 ] ASF GitHub Bot commented on IGNITE-2765: GitHub user avinogradovgg opened a pull request: https://github.com/apache/ignite/pull/543 IGNITE-2765 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2765 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/543.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 #543 commit 2e64d0d7cc51552fffc231cbc850cd615076fb85 Author: vozerov-gridgain Date: 2015-12-29T06:31:58Z IGNITE-2258: IGFS: now default path modes could be optionally disabled using FileSystemConfiguration.isInitializeDefaultPathModes() property. commit 4cd3b3dc2f1fa0f1a9cceb6bf544dd8fb505d7f5 Author: vozerov-gridgain Date: 2015-12-29T09:52:00Z IGNITE-2258: Fixed type on getter/setter. commit 5d58fcbf40fdb9114e4cbb32b72dd9bce7fa38ca Author: iveselovskiy Date: 2016-01-04T06:47:28Z IGNITE-2308: Fixed HadoopClassLoader dependency resolution. This closes #391. commit 83a19179cee2bb15adc36c2265dd0a3c794b60bb Author: vozerov-gridgain Date: 2016-01-04T08:14:58Z IGNITE-2218: Fixed a problem with native Hadoop libraries load. This closes #378. commit 1d7fb5702fa33cf395e797161f3a86a9600921a7 Author: vozerov-gridgain Date: 2016-01-05T06:59:31Z IGNITE-2206: Hadoop file system creation is now abstracted out using factory interface. commit a12ec7d08573d5396654a5ba05bb7d873e4c2677 Author: Ignite Teamcity Date: 2016-01-06T10:50:48Z 1.5.2 commit 090a5de6a930c10a3a57a6e28c486fe5c87e028d Author: vozerov-gridgain Date: 2015-12-29T12:50:39Z Minor fix. commit c786820dda7f7cd1849c5593ac24ca9072945887 Author: vozerov-gridgain Date: 2016-01-07T13:48:14Z IgniteHadoopIgfsSecondaryFileSystem.usrName field is renamed to "userName" to preserve backward compatibility. commit 6ab4ce246316442fa4295f9941c372fea70c24ef Author: vozerov-gridgain Date: 2016-01-08T06:23:55Z IGNITE-2342: Set correct classlader before calling FileSystem.get(). commit 077ab1b3a77fdb1c2c2fd6360fc5b60fda6c50c3 Author: vozerov-gridgain Date: 2016-01-08T07:17:45Z IGNITE-2341: Improved warning message when BinaryMarshaller cannot be used. Also it is not shown when "org.apache.ignite" classes is in described situation. commit 86c4816edfd0e983014f136ffc92cde28ec56cca Author: vozerov-gridgain Date: 2016-01-08T07:26:03Z IGNITE-2340: Improved error thrown when PROXY mode exists, but secondary file system is not IgniteHadoopIgfsSecondaryFileSystem. commit fc48a8429a84ef6c87ed3225a218d7d3ae617e14 Author: vozerov-gridgain Date: 2016-01-08T07:48:42Z Merge branch 'ignite-1.5.2' into ignite-1.5.3 commit 86740cefe212ed0f506d81056dd8e76de9a31e4f Author: Ignite Teamcity Date: 2016-01-08T09:32:11Z 1.5.3-SNAPSHOT commit 92229d2a6c6ef86772a62cb52b3aa07a55c99d89 Author: sboikov Date: 2016-01-13T05:56:34Z ignite-2359 Added locking for files used by MarshallerContextImpl. (cherry picked from commit 1d8c4e2) commit 2e4ce585d5f54502c6511d3425b1cd5fbf0a7f4f Author: Ignite Teamcity Date: 2016-01-13T10:37:33Z 1.5.4-SNAPSHOT commit 6e5f9f0c7d4c86773b1f0cd5c5a673acb58c86c2 Author: Denis Magda Date: 2016-01-13T11:42:27Z Changed year to 2016 in Copyrights commit 02dbcfd8ed2701a4f415c8871d0b8fd08bfa0583 Author: Alexey Goncharuk Date: 2016-01-13T13:47:32Z IGNITE-2365 - Notify policy if swap or offheap is enabled and rebalanced entry was not preloaded. IGNITE-2099 - Fixing custom collections. This closes #396 commit 86c2ba2a601e82b824cf17422683e5398a4d8c7d Author: sboikov Date: 2016-01-13T15:40:08Z ignite-2350 Pass update notifier flag in discovery data (all cluster nodes will have the same notifier status as first cluster node) (cherry picked from commit 7175a42) commit e1a494df400fc37ca04e8d88d1cf20bca02607b4 Author: sboikov Date: 2016-01-14T11:16:33Z Renamed fields to change fields write order (to preserve backward compatibility). (cherry picked from commit 2a4adf5) commit 09f978234b6062afa1e1658d5a6439365a856aca Author: sboikov Date: 2016-01-14T11:42:44Z Merge remote-tracking branch 'origin/ignite-1.5.4' into ignite-1.5.4 commit 30043e7892d0b52dc851ce5ec79c7eb3b7cc44fb Author: Denis Magda Date: 2016-01-14T13:02:50Z Added release notes commit cc3db35925698f1670a8bf1c6a1830c0c9b51290 Author: vershov Date: 2016-01-14T14:21:56Z IGNITE-2032 Unwind undeploys in preloader - Fixes #369. Signed-off-by: Alexey Goncharuk commit a5c85ca7749ae90af2e4a29e2162713b480e40fa Author: Valentin Kulichenko Date:
[jira] [Assigned] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov reassigned IGNITE-2765:
Assignee: Anton Vinogradov (was: Valentin Kulichenko)
> WebSessionFilter doesn't survive client reconnect
> -
>
> Key: IGNITE-2765
> URL: https://issues.apache.org/jira/browse/IGNITE-2765
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> If a {{WebSessionFilter}} is started with an embedded client, it is not
> functional after the client disconnects and reconnects. Any operation throws
> the exception below.
> {noformat}
> java.lang.IllegalStateException: Cache has been closed or destroyed: WebCache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:160)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1958)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:855)
> at
> org.apache.ignite.cache.websession.WebSessionFilter.doFilter0(WebSessionFilter.java:341)
> {noformat}
> We should get a new instance of the cache when the exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2758) IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't contain any classes
[
https://issues.apache.org/jira/browse/IGNITE-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189420#comment-15189420
]
Vasilisa Sidorova commented on IGNITE-2758:
Done. All looks good now for Apache Ignite build #542 and there is not artifact
aws-java-sdk in the binaries.
Artifacts aws-java-sdk-core, aws-java-sdk-s3, joda-time, aws-java-sdk-kms
contain some classes.
> IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't contain any
> classes
>
>
> Key: IGNITE-2758
> URL: https://issues.apache.org/jira/browse/IGNITE-2758
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vasilisa Sidorova
>Priority: Blocker
> Labels: community, customer, important
> Fix For: 1.6
>
>
> To observe the issue do this:
> * Build the fabric ZIP file.
> * Go to {{ignite-aws}} module folder.
> * Unzip {{aws-java-sdk-1.10.29.jar}}.
> * JAR file contains only pom.xml, no classes.
> We need to make sure that all required AWS SDK components are included. At
> least we need these ones:
> * aws-java-sdk-core
> * aws-java-sdk-s3
> * joda-time
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2756) StreamVisitorExample returns empty result set
[
https://issues.apache.org/jira/browse/IGNITE-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189429#comment-15189429
]
Vasilisa Sidorova commented on IGNITE-2756:
Fix verified. Thank you, Valentin
> StreamVisitorExample returns empty result set
> -
>
> Key: IGNITE-2756
> URL: https://issues.apache.org/jira/browse/IGNITE-2756
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Sergey Kozlov
>Assignee: Vasilisa Sidorova
>
> 1. Start {{ExampleNodeStartup}}
> 2. Start {{StreamVisitorExample}}
> {noformat}
> [15:31:22] Ignite node started OK (id=4395613e)
> [15:31:22] Topology snapshot [ver=2, servers=1, clients=1, CPUs=8, heap=7.1GB]
> Number of tuples streamed into Ignite: 50
> Number of tuples streamed into Ignite: 100
> ...
> Number of tuples streamed into Ignite: 950
> Number of tuples streamed into Ignite: 1000
> Top performing financial instruments:
> Query result set is empty.
> [15:31:47] Ignite node stopped OK [uptime=00:00:25:209]
> Process finished with exit code 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2605) Apache Apex Integration
[ https://issues.apache.org/jira/browse/IGNITE-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189471#comment-15189471 ] Suminda Dharmasena commented on IGNITE-2605: See: https://issues.apache.org/jira/browse/IGNITE-2606 and https://issues.apache.org/jira/browse/IGNITE-2607 > Apache Apex Integration > --- > > Key: IGNITE-2605 > URL: https://issues.apache.org/jira/browse/IGNITE-2605 > Project: Ignite > Issue Type: New Feature >Reporter: Suminda Dharmasena > > Is it possible to have Apache Apex run on top of Ignite without YARN -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2789) Fix dropdown placeholder
[ https://issues.apache.org/jira/browse/IGNITE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-2789: Assignee: Alexey Kuznetsov (was: Dmitriyff) > Fix dropdown placeholder > > > Key: IGNITE-2789 > URL: https://issues.apache.org/jira/browse/IGNITE-2789 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriyff >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2791) Continuous query listener is not notified during concurrent key put.
[ https://issues.apache.org/jira/browse/IGNITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189486#comment-15189486 ] Nikolay Tikhonov commented on IGNITE-2791: -- If listener registration is happen during cache update in this case may be that a local listener will be ignore this update (on start continuous query it get update counter for this cache update and set the counter as starting), but remote filter will be applied for this update. For avoid this situation need to set a starting update counters to remote filter and ignore this event in filter too. > Continuous query listener is not notified during concurrent key put. > > > Key: IGNITE-2791 > URL: https://issues.apache.org/jira/browse/IGNITE-2791 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Nikolay Tikhonov >Priority: Critical > Fix For: 1.6 > > Attachments: CacheListenersKillingMe3Main.java > > > Attached the code reproducing the problem. What is evident from the log, is > that that filter was invoked, but the listener was not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2752) LINQ NuGet package
[ https://issues.apache.org/jira/browse/IGNITE-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-2752. -- > LINQ NuGet package > -- > > Key: IGNITE-2752 > URL: https://issues.apache.org/jira/browse/IGNITE-2752 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Since NuGet is merged, we should create a package for LINQ assembly, and > include LINQPad samples in it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2752) LINQ NuGet package
[ https://issues.apache.org/jira/browse/IGNITE-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-2752. Resolution: Done > LINQ NuGet package > -- > > Key: IGNITE-2752 > URL: https://issues.apache.org/jira/browse/IGNITE-2752 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.6 > > > Since NuGet is merged, we should create a package for LINQ assembly, and > include LINQPad samples in it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2759) Cache conflicts must honour "keepBinary" flag.
[
https://issues.apache.org/jira/browse/IGNITE-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Karachentsev reassigned IGNITE-2759:
---
Assignee: Vladimir Ozerov (was: Dmitry Karachentsev)
> Cache conflicts must honour "keepBinary" flag.
> --
>
> Key: IGNITE-2759
> URL: https://issues.apache.org/jira/browse/IGNITE-2759
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Labels: community, customer, important
> Fix For: 1.6
>
>
> *Problem*
> {{GridCacheMapEntry}} deals with conflicts in some methods like {{innerSet}}.
> {{innerUpdate}}, etc.. When conflict occurs, we always deserialize
> keys/values what could lead to exceptions if there are no classes on the
> server.
> *Solution*
> Deserialize keys/values only if "keepBinary=false".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2793) ODBC: Add support for Arrays.
Igor Sapego created IGNITE-2793:
---
Summary: ODBC: Add support for Arrays.
Key: IGNITE-2793
URL: https://issues.apache.org/jira/browse/IGNITE-2793
Project: Ignite
Issue Type: Sub-task
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 1.6
Support for arrays should be added. We need to at least support byte arrays to
match {{SQL_C_BINARY}} type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2794) ODBC: Make sure that SQL_C_BINARY type is supported.
Igor Sapego created IGNITE-2794:
---
Summary: ODBC: Make sure that SQL_C_BINARY type is supported.
Key: IGNITE-2794
URL: https://issues.apache.org/jira/browse/IGNITE-2794
Project: Ignite
Issue Type: Sub-task
Components: odbc
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 1.6
Need to make sure that any column can be fetched as {{SQL_C_BINARY}} type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2795) Cache query cursor do not create value copy
Valentin Kulichenko created IGNITE-2795: --- Summary: Cache query cursor do not create value copy Key: IGNITE-2795 URL: https://issues.apache.org/jira/browse/IGNITE-2795 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Valentin Kulichenko Priority: Critical Fix For: 1.6 If entries returned from SQL query are modified, these changes are reflected in the cache. Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2795) Cache query cursor do not create value copy
[ https://issues.apache.org/jira/browse/IGNITE-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2795: Attachment: QueryTest.java > Cache query cursor do not create value copy > --- > > Key: IGNITE-2795 > URL: https://issues.apache.org/jira/browse/IGNITE-2795 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Priority: Critical > Fix For: 1.6 > > Attachments: QueryTest.java > > > If entries returned from SQL query are modified, these changes are reflected > in the cache. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1071) IgniteCache.metrics() method returns local metrics
[
https://issues.apache.org/jira/browse/IGNITE-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190035#comment-15190035
]
Valentin Kulichenko commented on IGNITE-1071:
-
Semen, I think we should check other MBeans as well. From what I see in the
code, non-cache metrics are also node-local in MBeans.
> IgniteCache.metrics() method returns local metrics
> --
>
> Key: IGNITE-1071
> URL: https://issues.apache.org/jira/browse/IGNITE-1071
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Priority: Minor
> Labels: Usability
> Fix For: 1.6
>
>
> To get metrics for the whole cluster user needs to use
> {{cache.metrics(ignite.cluster())}}, which is counterintuitive and
> inconsistent with other APIs. {{IgniteCache.metrics()}} w/o parameters should
> return metrics for the whole cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2791) Continuous query listener is not notified during concurrent key put.
[
https://issues.apache.org/jira/browse/IGNITE-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190184#comment-15190184
]
Andrey Kornev commented on IGNITE-2791:
---
Nikolay,
It looks like this condition is treated by CacheContinuousQueryHandler as a
duplicate event (as can be seen from the log message:
{noformat}
DEBUG CacheContinuousQueryHandler - Skip duplicate continuous query message:
CacheContinuousQueryEntry [evtType=CREATED, key=KeyCacheObjectImpl [val=1,
hasValBytes=true], newVal=CacheObjectImpl [val=null, hasValBytes=true],
oldVal=null, cacheId=-1368047377, part=1, updateCntr=1, flags=0,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], filteredEvts=null,
keepBinary=false]
{noformat}
which is of course wrong since it's not a duplicate. This issue still occurs
when the continuous query is defined as local and both the filter and the
listener are on the same node.
> Continuous query listener is not notified during concurrent key put.
>
>
> Key: IGNITE-2791
> URL: https://issues.apache.org/jira/browse/IGNITE-2791
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Tikhonov
>Priority: Critical
> Fix For: 1.6
>
> Attachments: CacheListenersKillingMe3Main.java
>
>
> Attached the code reproducing the problem. What is evident from the log, is
> that that filter was invoked, but the listener was not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2765) WebSessionFilter doesn't survive client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190250#comment-15190250
]
Valentin Kulichenko commented on IGNITE-2765:
-
Anton,
I reviewed the changes and have couple of comments:
* When cache is recreated, it's possible that it lready has a different
configuration than before. I think you should move all the code on lines
239-265 to {{initCache()}} method and call it inside {{init()}}, as well as
instead of {{reinitCache()}}.
* I don't like that we wait on reconnect and retry futures indefinitely. This
can cause HTTP request to hang for a long time, or even forever. I think we
should have a configurable time out there (e.g., 5sec by default). If it times
out, we can throw the exception right away without retrying.
Otherwise looks good!
> WebSessionFilter doesn't survive client reconnect
> -
>
> Key: IGNITE-2765
> URL: https://issues.apache.org/jira/browse/IGNITE-2765
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: community, customer, important
> Fix For: 1.6
>
>
> If a {{WebSessionFilter}} is started with an embedded client, it is not
> functional after the client disconnects and reconnects. Any operation throws
> the exception below.
> {noformat}
> java.lang.IllegalStateException: Cache has been closed or destroyed: WebCache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:160)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:1958)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:855)
> at
> org.apache.ignite.cache.websession.WebSessionFilter.doFilter0(WebSessionFilter.java:341)
> {noformat}
> We should get a new instance of the cache when the exception is thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2796) NPE during rebalancing
Valentin Kulichenko created IGNITE-2796:
---
Summary: NPE during rebalancing
Key: IGNITE-2796
URL: https://issues.apache.org/jira/browse/IGNITE-2796
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
This exception sometimes appear in logs when topology changes under load:
{noformat}
2016-03-06T08:07:52,500 ERROR [sys-#47%null%] (Slf4jLogger.java:112) - Failed
processing message [senderId=ad2315fd-237c-492c-a1c6-7ea69c7f3807,
msg=GridDhtPartitionSupplyMessageV2 [updateSeq=35,
topVer=AffinityTopologyVersion [topVer=1413, minorTopVer=0], missed=null,
msgSize=0, size=1, parts=[718], super=GridCacheMessage [msgId=52249,
depInfo=null, err=null, skipPrepare=false, cacheId=1762189895,
cacheId=1762189895]]]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:971)
~[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1100(GridDhtPartitionDemander.java:751)
~[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:600)
~[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:407)
~[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:342)
~[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:335)
~[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:80)
[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1085)
[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2236)
[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1003)
[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1800(GridIoManager.java:103)
[ignite-core-1.5.5.jar:1.5.5]
at
org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:972)
[ignite-core-1.5.5.jar:1.5.5]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_51]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_51]
{noformat}
It doesn't seem to break anything, but still has to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2797) Prepare and finish future never time out
Valentin Kulichenko created IGNITE-2797: --- Summary: Prepare and finish future never time out Key: IGNITE-2797 URL: https://issues.apache.org/jira/browse/IGNITE-2797 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Valentin Kulichenko Priority: Blocker Fix For: 1.6 Even if transaction timeout is configured, transaction will not timeout if it's already in prepare state. It will be shown in log as pending transaction and can cause the whole cluster hang. We need to add a mechanism that will properly timeout prepare and (if possible) finish futures. Also we can create an event that will be fired if there is a transaction pending for a long time, showing which nodes we are waiting responses from. This will allow user to recover by stopping only these nodes instead of restarting the whole cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2798) 'Transaction has already been completed' in restart tests
[
https://issues.apache.org/jira/browse/IGNITE-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2798:
Description:
When running transaction tests with node restarts (e.g.
{{IgniteCacheTxNearDisabledPutGetRestartTest}}, logs are flooded with
exceptions like below. Need to check if it's an issue or not.
{noformat}
[18:03:18,760][WARN
][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
Received finish request for completed transaction (the message may be too late
and transaction could have been DGCed by now) [commit=false,
xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
globalTime=1457661798754, order=1457662644887]]
[18:03:18] (err) Failed to execute compound future reducer: Compound future
listener []class org.apache.ignite.IgniteCheckedException: Transaction has been
already completed.
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
at
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
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}
was:
When running transaction tests with node restarts, logs are flooded with
exceptions like below. Need to check if it's an issue or not.
{noformat}
[18:03:18,760][WARN
][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
Received finish request for completed transaction (the message may be too late
and transaction could have been DGCed by now) [commit=false,
xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
globalTime=1457661798754, order=1457662644887]]
[18:03:18] (err) Failed to execute compound future reducer: Compound future
listener []class org.apache.ignite.IgniteCheckedException: Transaction has been
already completed.
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
at
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
at
ja
[jira] [Created] (IGNITE-2798) 'Transaction has already been completed' in restart tests
Valentin Kulichenko created IGNITE-2798:
---
Summary: 'Transaction has already been completed' in restart tests
Key: IGNITE-2798
URL: https://issues.apache.org/jira/browse/IGNITE-2798
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
Fix For: 1.6
When running transaction tests with node restarts, logs are flooded with
exceptions like below. Need to check if it's an issue or not.
{noformat}
[18:03:18,760][WARN
][sys-#11142%distributed.IgniteCacheTxNearDisabledPutGetRestartTest2%][IgniteTxHandler]
Received finish request for completed transaction (the message may be too late
and transaction could have been DGCed by now) [commit=false,
xid=GridCacheVersion [topVer=69142079, nodeOrderDrId=3,
globalTime=1457661798754, order=1457662644887]]
[18:03:18] (err) Failed to execute compound future reducer: Compound future
listener []class org.apache.ignite.IgniteCheckedException: Transaction has been
already completed.
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:650)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:597)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:568)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:127)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:125)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:280)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:204)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:80)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:163)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:822)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
at
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:785)
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}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2735) Interrupt all acquires on local node after ignite.close
[ https://issues.apache.org/jira/browse/IGNITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190465#comment-15190465 ] ASF GitHub Bot commented on IGNITE-2735: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/525 > Interrupt all acquires on local node after ignite.close > --- > > Key: IGNITE-2735 > URL: https://issues.apache.org/jira/browse/IGNITE-2735 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 1.6 >Reporter: Vladisav Jelisavcic >Assignee: Vladisav Jelisavcic > Fix For: 1.5.0.final > > > "acquire" method should throw an exception when semaphore is no longer > accessible when node is stopped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2735) Interrupt all acquires on local node after ignite.close
[ https://issues.apache.org/jira/browse/IGNITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko resolved IGNITE-2735. - Resolution: Fixed > Interrupt all acquires on local node after ignite.close > --- > > Key: IGNITE-2735 > URL: https://issues.apache.org/jira/browse/IGNITE-2735 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 1.6 >Reporter: Vladisav Jelisavcic >Assignee: Vladisav Jelisavcic > Fix For: 1.5.0.final > > > "acquire" method should throw an exception when semaphore is no longer > accessible when node is stopped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2735) Interrupt all acquires on local node after ignite.close
[ https://issues.apache.org/jira/browse/IGNITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190464#comment-15190464 ] Valentin Kulichenko commented on IGNITE-2735: - Yes, makes sense. Merged changes to master. Thanks for the contribution! > Interrupt all acquires on local node after ignite.close > --- > > Key: IGNITE-2735 > URL: https://issues.apache.org/jira/browse/IGNITE-2735 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 1.6 >Reporter: Vladisav Jelisavcic >Assignee: Vladisav Jelisavcic > Fix For: 1.5.0.final > > > "acquire" method should throw an exception when semaphore is no longer > accessible when node is stopped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2735) Interrupt all acquires on local node after ignite.close
[ https://issues.apache.org/jira/browse/IGNITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-2735. --- > Interrupt all acquires on local node after ignite.close > --- > > Key: IGNITE-2735 > URL: https://issues.apache.org/jira/browse/IGNITE-2735 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 1.6 >Reporter: Vladisav Jelisavcic >Assignee: Vladisav Jelisavcic > Fix For: 1.5.0.final > > > "acquire" method should throw an exception when semaphore is no longer > accessible when node is stopped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2708) Need to validate that SPIs are started only once
[
https://issues.apache.org/jira/browse/IGNITE-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-2708:
--
Assignee: Ryan Zhao
> Need to validate that SPIs are started only once
>
>
> Key: IGNITE-2708
> URL: https://issues.apache.org/jira/browse/IGNITE-2708
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Ryan Zhao
> Labels: newbie, usability
>
> User forum discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-instance-hangs-during-restart-in-client-mode-td3101.html
> If one uses the same instance of {{IgniteConfiguration}} more than once, it
> doesn't work because SPIs have lifecycle and can be started only once.
> Currently this causes hang on start which is counterintuitive.
> We should add a validation step to {{GridSpiAdapter}} that will check that
> the SPI was never started before. Its {{spiStart()}} method should set some
> flag there or throw exception if it has already been set. All internal SPI
> implementations should be changed to call {{super.spiStart()}} as first
> statement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2663) ODBC: Add protocol version to protocol packet header.
[
https://issues.apache.org/jira/browse/IGNITE-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190513#comment-15190513
]
Vladimir Ozerov commented on IGNITE-2663:
-
Stateless is not an advantage per se. Moreover, our protocol is already
statefull even without these changes, because query IDs are linked to concrete
network connection.
> ODBC: Add protocol version to protocol packet header.
> -
>
> Key: IGNITE-2663
> URL: https://issues.apache.org/jira/browse/IGNITE-2663
> Project: Ignite
> Issue Type: Sub-task
> Components: odbc
>Affects Versions: 1.5.0.final
>Reporter: Igor Sapego
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Currently, there is no way for server to find out that ODBC driver uses
> incompatible protocol version. Consider adding {{protocolVersion}} field to
> ODBC protocol message header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2549) ODBC: Implement example that can be used for data visualization.
[ https://issues.apache.org/jira/browse/IGNITE-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2549: Summary: ODBC: Implement example that can be used for data visualization. (was: CPP: Implement example that can be used for data visualization.) > ODBC: Implement example that can be used for data visualization. > > > Key: IGNITE-2549 > URL: https://issues.apache.org/jira/browse/IGNITE-2549 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Affects Versions: 1.5.0.final >Reporter: Igor Sapego >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > As the one of the purposes for development of the ODBC driver was to use data > visualization tools with Apache Ignite, we need to have example that can be > used to test interoperability with such tools. Such example should contain > several caches with relational data that can provide meaningful graphs when > visualized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2429) ODBC: Add examples.
[ https://issues.apache.org/jira/browse/IGNITE-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2429: Summary: ODBC: Add examples. (was: CPP: Add examples for the ODBC.) > ODBC: Add examples. > --- > > Key: IGNITE-2429 > URL: https://issues.apache.org/jira/browse/IGNITE-2429 > Project: Ignite > Issue Type: Sub-task > Components: odbc >Reporter: Igor Sapego >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > We need to implement examples that will show how to use our ODBC driver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2800) Coordinator floods network with partitions' full map messages
Denis Magda created IGNITE-2800: --- Summary: Coordinator floods network with partitions' full map messages Key: IGNITE-2800 URL: https://issues.apache.org/jira/browse/IGNITE-2800 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Denis Magda Assignee: Vladimir Ozerov Priority: Critical Fix For: 1.6 It is detected that the more machines in the cluster we have and the more caches are started then the more outgoing traffic is produced by a coordinator node. As an example in the current deployment - 30 nodes; - 67 caches; - caches are empty and the cluster is not used at all (idle). the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast each other node shows constant 10 Mbit/s usage of incoming traffic. Most likely the reason is that the coordinator indefinitely sends partitions full map for all the caches to all the nodes. This shouldn't happen. Need to debug the reason of the issue and fix it. Attached snapshots taken from the coordinator and on of cluster's nodes. Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2799) Coordinator floods network with partitions' full map messages
Denis Magda created IGNITE-2799: --- Summary: Coordinator floods network with partitions' full map messages Key: IGNITE-2799 URL: https://issues.apache.org/jira/browse/IGNITE-2799 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Denis Magda Assignee: Vladimir Ozerov Priority: Critical Fix For: 1.6 It is detected that the more machines in the cluster we have and the more caches are started then the more outgoing traffic is produced by a coordinator node. As an example in the current deployment - 30 nodes; - 67 caches; - caches are empty and the cluster is not used at all (idle). the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast each other node shows constant 10 Mbit/s usage of incoming traffic. Most likely the reason is that the coordinator indefinitely sends partitions full map for all the caches to all the nodes. This shouldn't happen. Need to debug the reason of the issue and fix it. Attached snapshots taken from the coordinator and on of cluster's nodes. Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2801) Coordinator floods network with partitions' full map messages
Denis Magda created IGNITE-2801: --- Summary: Coordinator floods network with partitions' full map messages Key: IGNITE-2801 URL: https://issues.apache.org/jira/browse/IGNITE-2801 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.5.0.final Reporter: Denis Magda Assignee: Vladimir Ozerov Priority: Critical Fix For: 1.6 It is detected that the more machines in the cluster we have and the more caches are started then the more outgoing traffic is produced by a coordinator node. As an example in the current deployment - 30 nodes; - 67 caches; - caches are empty and the cluster is not used at all (idle). the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast each other node shows constant 10 Mbit/s usage of incoming traffic. Most likely the reason is that the coordinator indefinitely sends partitions full map for all the caches to all the nodes. This shouldn't happen. Need to debug the reason of the issue and fix it. Attached snapshots taken from the coordinator and on of cluster's nodes. Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2801) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2801: Labels: community important (was: ) > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2801 > URL: https://issues.apache.org/jira/browse/IGNITE-2801 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Labels: community, important > Fix For: 1.6 > > Attachments: basic_node.nps, basic_node.png, coordinator.nps, > coordinator.png > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2801) Coordinator floods network with partitions' full map messages
[ https://issues.apache.org/jira/browse/IGNITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2801: Attachment: coordinator.png coordinator.nps basic_node.png basic_node.nps > Coordinator floods network with partitions' full map messages > - > > Key: IGNITE-2801 > URL: https://issues.apache.org/jira/browse/IGNITE-2801 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Labels: community, important > Fix For: 1.6 > > Attachments: basic_node.nps, basic_node.png, coordinator.nps, > coordinator.png > > > It is detected that the more machines in the cluster we have and the more > caches are started then the more outgoing traffic is produced by a > coordinator node. > As an example in the current deployment > - 30 nodes; > - 67 caches; > - caches are empty and the cluster is not used at all (idle). > the coordinator constantly uses 300 Mbit/s of outgoing traffic. In contrast > each other node shows constant 10 Mbit/s usage of incoming traffic. > Most likely the reason is that the coordinator indefinitely sends partitions > full map for all the caches to all the nodes. This shouldn't happen. > Need to debug the reason of the issue and fix it. > Attached snapshots taken from the coordinator and on of cluster's nodes. > Probably they would help. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
