Re: IgniteCache.invoke on ALL keys
Vova, even though it operates on single key we will need to "pin" partition so key does not go to another node. Pavel, you can also send closures to all primary nodes to do local scan query for each partition. This way you will go over each entry. Thanks! -- Yakov Zhdanov, Director R&D *GridGain Systems* www.gridgain.com 2016-05-30 16:05 GMT-04:00 Vladimir Ozerov : > Affinity run/call operate on a single key AFAIK. > > On Mon, May 30, 2016 at 10:55 PM, Dmitriy Setrakyan > > wrote: > > > Actually I have seen a ticket to block moving partitions if affinityCall > or > > affinityRun are called. I think once these tickets are implemented, the > > process will become reliable, no? > > > > D. > > > > On Mon, May 30, 2016 at 9:13 AM, Pavel Tupitsyn > > wrote: > > > > > Dmitriy, as I understand, there is no reliable way to do that if > > > rebalancing happens. > > > > > > On Mon, May 30, 2016 at 6:50 PM, Dmitriy Setrakyan < > > dsetrak...@apache.org> > > > wrote: > > > > > > > I think we do support this use case. Why not send a computation to a > > > server > > > > and then perform the iteration through the cache entries locally on > > that > > > > server? > > > > > > > > On Mon, May 30, 2016 at 4:44 AM, Pavel Tupitsyn < > > ptupit...@gridgain.com> > > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > Looks like we do not have an efficient way to perform an action on > > > EVERY > > > > > cache entry. > > > > > > > > > > Let's say I want to remove all entries that match a predicate. > > > > > My only option is to retrieve these entries via Scan or SQL query, > > and > > > > then > > > > > call removeAll. > > > > > This involves a lot of unnecessary network trips (send keys to > caller > > > > node, > > > > > send them back to primary nodes). > > > > > > > > > > Would it be possible to implement a method like > > > > > void IgniteCache.invokeAll(entryProcessor) > > > > > that invokes the processor on all entries and does not return > > anything? > > > > > There could be more overloads that return results or only return > > > results > > > > > for changed entries. > > > > > > > > > > Thoughts? > > > > > > > > > > Pavel. > > > > > > > > > > > > > > >
[jira] [Created] (IGNITE-3217) Text input in number field
Vasiliy Sisko created IGNITE-3217: - Summary: Text input in number field Key: IGNITE-3217 URL: https://issues.apache.org/jira/browse/IGNITE-3217 Project: Ignite Issue Type: Sub-task Components: wizards Affects Versions: 1.7 Reporter: Vasiliy Sisko Assignee: Dmitriyff Fix For: 1.7 Create new cluster and try to input text into number field (f.e. Cluster - General - Port number): # Field is empty (Chrome) or show text with error message (Firefox), # field in model (backupItem) is not set, # Buttons "Save" and "Undo all" and "Undo" is available, # On undo of section "Save" and "Undo all" still available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: IgniteCache.invoke on ALL keys
Affinity run/call operate on a single key AFAIK. On Mon, May 30, 2016 at 10:55 PM, Dmitriy Setrakyan wrote: > Actually I have seen a ticket to block moving partitions if affinityCall or > affinityRun are called. I think once these tickets are implemented, the > process will become reliable, no? > > D. > > On Mon, May 30, 2016 at 9:13 AM, Pavel Tupitsyn > wrote: > > > Dmitriy, as I understand, there is no reliable way to do that if > > rebalancing happens. > > > > On Mon, May 30, 2016 at 6:50 PM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > > > > I think we do support this use case. Why not send a computation to a > > server > > > and then perform the iteration through the cache entries locally on > that > > > server? > > > > > > On Mon, May 30, 2016 at 4:44 AM, Pavel Tupitsyn < > ptupit...@gridgain.com> > > > wrote: > > > > > > > Igniters, > > > > > > > > Looks like we do not have an efficient way to perform an action on > > EVERY > > > > cache entry. > > > > > > > > Let's say I want to remove all entries that match a predicate. > > > > My only option is to retrieve these entries via Scan or SQL query, > and > > > then > > > > call removeAll. > > > > This involves a lot of unnecessary network trips (send keys to caller > > > node, > > > > send them back to primary nodes). > > > > > > > > Would it be possible to implement a method like > > > > void IgniteCache.invokeAll(entryProcessor) > > > > that invokes the processor on all entries and does not return > anything? > > > > There could be more overloads that return results or only return > > results > > > > for changed entries. > > > > > > > > Thoughts? > > > > > > > > Pavel. > > > > > > > > > >
Re: IgniteCache.invoke on ALL keys
Actually I have seen a ticket to block moving partitions if affinityCall or affinityRun are called. I think once these tickets are implemented, the process will become reliable, no? D. On Mon, May 30, 2016 at 9:13 AM, Pavel Tupitsyn wrote: > Dmitriy, as I understand, there is no reliable way to do that if > rebalancing happens. > > On Mon, May 30, 2016 at 6:50 PM, Dmitriy Setrakyan > wrote: > > > I think we do support this use case. Why not send a computation to a > server > > and then perform the iteration through the cache entries locally on that > > server? > > > > On Mon, May 30, 2016 at 4:44 AM, Pavel Tupitsyn > > wrote: > > > > > Igniters, > > > > > > Looks like we do not have an efficient way to perform an action on > EVERY > > > cache entry. > > > > > > Let's say I want to remove all entries that match a predicate. > > > My only option is to retrieve these entries via Scan or SQL query, and > > then > > > call removeAll. > > > This involves a lot of unnecessary network trips (send keys to caller > > node, > > > send them back to primary nodes). > > > > > > Would it be possible to implement a method like > > > void IgniteCache.invokeAll(entryProcessor) > > > that invokes the processor on all entries and does not return anything? > > > There could be more overloads that return results or only return > results > > > for changed entries. > > > > > > Thoughts? > > > > > > Pavel. > > > > > >
[jira] [Created] (IGNITE-3216) Need to deduplicate addresses registered in the IP finder
Valentin Kulichenko created IGNITE-3216:
---
Summary: Need to deduplicate addresses registered in the IP finder
Key: IGNITE-3216
URL: https://issues.apache.org/jira/browse/IGNITE-3216
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Fix For: 1.7
{{IgniteUtils.toSocketAddresses(...)}} method can produce the collection with
duplicated addresses in some cases (e.g., if one of hostnames is provided as an
IP). We should deduplicate the list before returning it (most likely we should
simply use {{Set}} instead).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3215) IgniteRDD should be able to work with BinaryObjects
Valentin Kulichenko created IGNITE-3215:
---
Summary: IgniteRDD should be able to work with BinaryObjects
Key: IGNITE-3215
URL: https://issues.apache.org/jira/browse/IGNITE-3215
Project: Ignite
Issue Type: Improvement
Components: Ignite RDD
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Fix For: 1.7
Need to add {{withKeepBinary}} flag to {{IgniteRDD}}, similar to
{{IgniteCache}}. If set, functions used in methods like {{foreachPartition}}
will work with {{BinaryObject}} instances instead of deserialized objects.
Currently if such methods are used, classes are required to be deployed on
executors' classpath.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: IgniteCache.invoke on ALL keys
Dmitriy, as I understand, there is no reliable way to do that if rebalancing happens. On Mon, May 30, 2016 at 6:50 PM, Dmitriy Setrakyan wrote: > I think we do support this use case. Why not send a computation to a server > and then perform the iteration through the cache entries locally on that > server? > > On Mon, May 30, 2016 at 4:44 AM, Pavel Tupitsyn > wrote: > > > Igniters, > > > > Looks like we do not have an efficient way to perform an action on EVERY > > cache entry. > > > > Let's say I want to remove all entries that match a predicate. > > My only option is to retrieve these entries via Scan or SQL query, and > then > > call removeAll. > > This involves a lot of unnecessary network trips (send keys to caller > node, > > send them back to primary nodes). > > > > Would it be possible to implement a method like > > void IgniteCache.invokeAll(entryProcessor) > > that invokes the processor on all entries and does not return anything? > > There could be more overloads that return results or only return results > > for changed entries. > > > > Thoughts? > > > > Pavel. > > >
Re: A question about ignite-indexing and H2
Hi,
AFAIK, you cannot use 1.4.X version with Ignite.
If you want to use another version of H2 in your project,
you can try to use different classloader to load it separately.
Google it for details.
2016-05-30 9:20 GMT+03:00 王庆 :
> Hi，I am a developer from china .My English leaves much to be desired.
> Please ingore these syntax errors.When I use the spatial index module in
> ignite1.6.0 , I found it depends 1.3.175 version of the H2, but I need to
> use the 1.4.X h2 version.
> com.h2database
> h2
> 1.3.175
> compile
> This method
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing # start
> will call org.h2.constant.SysProperties and org.h2.util.Utils, in front of
> the class in the 1.3.176 version of the above have been It does not exist,
> the latter class is missing serializer
> variables. if (SysProperties.serializeJavaObject) {
>
> U.warn(log, "Serialization of Java objects in H2 was enabled.");
>
> SysProperties.serializeJavaObject = false;
> }
>
> if (Utils.serializer != null)
>
> U.warn(log, "Custom H2 serialization is already configured, will
> override.");
>
> Utils.serializer = h2Serializer();
> Is there any way to solve it? I am looking forward to your replay.Thank
> you.
--
Best regards,
Alexei Scherbakov
Re: IgniteCache.invoke on ALL keys
I think we do support this use case. Why not send a computation to a server and then perform the iteration through the cache entries locally on that server? On Mon, May 30, 2016 at 4:44 AM, Pavel Tupitsyn wrote: > Igniters, > > Looks like we do not have an efficient way to perform an action on EVERY > cache entry. > > Let's say I want to remove all entries that match a predicate. > My only option is to retrieve these entries via Scan or SQL query, and then > call removeAll. > This involves a lot of unnecessary network trips (send keys to caller node, > send them back to primary nodes). > > Would it be possible to implement a method like > void IgniteCache.invokeAll(entryProcessor) > that invokes the processor on all entries and does not return anything? > There could be more overloads that return results or only return results > for changed entries. > > Thoughts? > > Pavel. >
1.6 version in Jira is not released
Guys, Can we release version 1.6 in Jira? Currently I can still assign tickets to version 1.6, which is not correct. D.
A question about ignite-indexing and H2
Hi，I am a developer from china .My English leaves much to be desired. Please
ingore these syntax errors.When I use the spatial index module in ignite1.6.0 ,
I found it depends 1.3.175 version of the H2, but I need to use the 1.4.X h2
version.
com.h2database
h2
1.3.175
compile
This method
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing # start will
call org.h2.constant.SysProperties and org.h2.util.Utils, in front of the class
in the 1.3.176 version of the above have been It does not exist, the latter
class is missing serializer variables. if (SysProperties.serializeJavaObject) {
U.warn(log, "Serialization of Java objects in H2 was enabled.");
SysProperties.serializeJavaObject = false;
}
if (Utils.serializer != null)
U.warn(log, "Custom H2 serialization is already configured, will
override.");
Utils.serializer = h2Serializer();
Is there any way to solve it? I am looking forward to your replay.Thank you.
[GitHub] ignite pull request: Ignite 3183 to 7.6.1
GitHub user avinogradovgg opened a pull request: https://github.com/apache/ignite/pull/764 Ignite 3183 to 7.6.1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3183-to-7.6.1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/764.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 #764 commit edc2947d7340cac4a3c90fa726c23d5d47798ab9 Author: vozerov-gridgain Date: 2016-05-25T10:07:03Z IGNITE-3191: IGFS: Improved error logging for operations in dual mode. commit 2f1747d726da87b67f6c5323b3e64762d56398cb Author: vozerov-gridgain Date: 2016-05-27T11:40:17Z Merge remote-tracking branch 'upstream/gridgain-7.6.1' into gridgain-7.6.1 commit 1bb8b647264593034659b7db929c2664dec603e1 Author: sboikov Date: 2016-05-27T11:21:01Z ignite-3116 Fixed NodeStoppingException in GridDhtGetFuture. (cherry picked from commit 303d3ca) commit 47c575c8696d51b675a16aa260ec9d398e0a68e9 Author: nikolay_tikhonov Date: 2016-05-30T09:42:37Z Added benchmark property file. commit 00e2dda9a850f74178ee893a3acf74ddc30d4a13 Author: nikolay_tikhonov Date: 2016-05-30T11:45:38Z Updated benchmark property file. commit 8ac1c28d6d507651de835a3676b48a3f1b5f6c15 Author: Anton Vinogradov Date: 2016-05-27T16:51:45Z IGNITE-3183 ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode (cherry picked from commit 30ca35b) commit 2ed6cdbba5d8b80dc1d55115842e6664e4ad709c Author: Anton Vinogradov Date: 2016-05-30T12:58:46Z IGNITE-3183 7.6.1 after refactoring fix --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-3214) YARN allocates containers at random
Nikolay Tikhonov created IGNITE-3214: Summary: YARN allocates containers at random Key: IGNITE-3214 URL: https://issues.apache.org/jira/browse/IGNITE-3214 Project: Ignite Issue Type: Improvement Reporter: Nikolay Tikhonov YARN allocates containers at random it's pretty onerous to figure out which hostnames have Ignite nodes running on them and specifying those in the URL. Also need to add the property which allows to limit number of nodes per host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
IgniteCache.invoke on ALL keys
Igniters, Looks like we do not have an efficient way to perform an action on EVERY cache entry. Let's say I want to remove all entries that match a predicate. My only option is to retrieve these entries via Scan or SQL query, and then call removeAll. This involves a lot of unnecessary network trips (send keys to caller node, send them back to primary nodes). Would it be possible to implement a method like void IgniteCache.invokeAll(entryProcessor) that invokes the processor on all entries and does not return anything? There could be more overloads that return results or only return results for changed entries. Thoughts? Pavel.
[GitHub] ignite pull request: Gridgain 7.5.24
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/763 Gridgain 7.5.24 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite gridgain-7.5.24 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/763.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 #763 commit 612bcb6b4011f99d98c39196173ce7fa60862394 Author: sboikov Date: 2016-01-19T12:30:53Z ignite-1.5.4 Pass currently written message class to MessageWriter. commit 5ba47a03411f507d9db661f83b8fe487b77bec1a Author: Pavel Tupitsyn Date: 2016-01-20T10:48:41Z IGNITE-2414 .NET: TestWithExpiryPolicy is split into two parts: one is fine, another one is muted due to IGNITE-1423. commit bfaf1a634b82bf2666c79bb8f54ce71797d9a778 Author: Denis Magda Date: 2016-01-20T10:48:47Z Fixed queryEntities initialization from a default config commit d0e763cbfbf7f915c942b90901678eba4abde138 Author: Anton Vinogradov Date: 2016-01-20T11:51:36Z G-10964 commit 6577f1145eb67e505d69314250534f3b51ae2780 Author: Alexey Kuznetsov Date: 2016-01-20T14:42:04Z Fixed Visor tasks (cherry picked from commit c77fc84). commit e0ae5248064e22cc0537f22fc5daf24142390194 Author: Alexey Kuznetsov Date: 2016-01-21T05:31:01Z Fixed Visor tasks (cherry picked from commit bccd459). commit d5a5f6aa8dc193bec4307947d7b241b3c4f1397e Author: Alexey Kuznetsov Date: 2016-01-21T05:40:15Z Fixed Visor tasks. (cherry picked from commit ba93717) commit 0222978a64e00b015a3e0f737ba9a96c72d5f0fe Author: sboikov Date: 2016-01-21T08:45:27Z Added initialization of 'storeKeepBinary' flag for cache configurations received on discovery. (cherry picked from commit d2f84d1) commit 782e7438f7e46a87382da5ca07c1e2bb69a14d79 Author: Alexey Goncharuk Date: 2016-01-21T09:17:43Z Init simple value type if it was not set for a cache configuration received on discovery. (cherry picked from commit fb0173f) commit dc261786dea5f9af75cf8f81775c18eff8a89543 Author: sboikov Date: 2016-01-21T09:20:04Z Added initialization of 'storeKeepBinary' flag for cache configurations received on discovery. (cherry picked from commit abe44f9) commit a8743aa3fa8da672b79aefa375f5cefdb5467f43 Author: Alexey Kuznetsov Date: 2016-01-21T12:02:08Z Fixed Visor tasks (cherry picked from commit 340658d). commit 6db5dcd65367e5f375640fabfbb5e4cbd95ec1c5 Author: Denis Magda Date: 2016-01-21T13:13:36Z Disallow join a cluster that have a different value for IGNITE_OPTIMIZED_MARSHALLER_USE_DEFAULT_SUID commit 25ced4c9ee8b5cc71d36c94c09428f93757a5e1d Author: Ignite Teamcity Date: 2016-01-22T07:29:35Z 1.5.5-SNAPSHOT commit 81e75e1c4c9919bf867b4559dafdcf37d4229328 Author: Tikhonov Nikolay Date: 2016-01-22T10:26:33Z Fixed conflict resolver API. commit 7ec3110f699b94a60562aa66906b6cb6528b2bb4 Author: Anton Vinogradov Date: 2016-01-22T11:16:42Z Compilation hotfix commit 3dfdee83d4105f3ae082de5344f2d6e6802d48e5 Author: Alexey Goncharuk Date: 2016-01-22T13:26:41Z # Added failing test case (IGNITE-2434) commit 63f3b3c8b0d4e128a794bf3aba3dec8680d8fab5 Author: Alexey Goncharuk Date: 2016-01-22T17:39:43Z IGNITE-2434 - Do not update cache store if entry processor was a NOOP - Fixes #418. commit 2ed8eb107dbb52b3ab43d951972d750fc1d5908d Author: iveselovskiy Date: 2016-01-25T09:15:56Z IGNITE-2343: Hadoop: InputSplit is now singleton, it resolved the problem. This closes #399. commit b6ef47e2a2d2cd2cdc4ab778013d6b309b91b8e9 Author: Anton Vinogradov Date: 2016-01-25T16:16:47Z Compilation hotfix commit 7257625c3c6e0375fe5b8eae85707e8e63c4c877 Author: Ignite Teamcity Date: 2016-01-26T12:02:52Z 1.5.6-SNAPSHOT commit a3acc095d809f7576664154c6aaaddbc602a9fa2 Author: Valentin Kulichenko Date: 2016-01-28T02:51:12Z IGNITE-2332 - Support package-private implementations for services commit b04f3363d462dd43784f948eb1db3bd4ce73b905 Author: Valentin Kulichenko Date: 2016-01-29T00:09:20Z Fixed GridServicePackagePrivateSelfTest - nodes were not properly stopped commit d25db2a2d67e8f00d8c12565a0727917c1d09ba7 Author: vozerov-gridgain Date: 2016-01-29T09:20:12Z IGNITE-2498: Fix. commit efc92f7d91bbec2631228cf06ab1d5a0df3aef4e Author: vozerov-gridgain Date: 2016-01-29T09:44:49Z IGNITE-2498: Full fix for (p2p + offheap) deserialization issue. commit b68c5607cbbfeddce9ec2da78d73f9f2597f77f1 Author: vozerov-gridgain Date: 2016-01-29T10:10:48Z IGNITE-2498: Finalization. commit c64673a97c92c49e1484d28c3a2cafe27cdf7232 Author: vozerov-gridgain Date: 2016-01-29T10:43:44Z IGNITE-2498: Finalization (2). commit b146c0f5ac227e270d79c6bf18017676db6a1164 Author: Valentin Kulichenko Date:
[GitHub] ignite pull request: Ignite 3183
Github user avinogradovgg closed the pull request at: https://github.com/apache/ignite/pull/752 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-3213) 'false' value in the caches list of cluster
Pavel Konstantinov created IGNITE-3213: -- Summary: 'false' value in the caches list of cluster Key: IGNITE-3213 URL: https://issues.apache.org/jira/browse/IGNITE-3213 Project: Ignite Issue Type: Bug Components: UI Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov # remove all caches and clusters # add new cluster, save # open Caches page, add new cache, do not link with cluster, save # open Clusters page - list of caches contains 'false' value -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3212) Servers get stuck with the warning "Failed to wait for initial partition map exchange" during falover test
Ksenia Rybakova created IGNITE-3212:
---
Summary: Servers get stuck with the warning "Failed to wait for
initial partition map exchange" during falover test
Key: IGNITE-3212
URL: https://issues.apache.org/jira/browse/IGNITE-3212
Project: Ignite
Issue Type: Bug
Affects Versions: 1.6
Reporter: Ksenia Rybakova
Servers being restarted during falover test get stuck after some time with the
warning "Failed to wait for initial partition map exchange".
{noformat}
[08:44:41,303][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager] Added
new node to topology: TcpDiscoveryNode
[id=db557f04-43b7-4e28-ae0d-d4dcf4139c89, addrs=
[10.20.0.222, 127.0.0.1], sockAddrs=[fosters-222/10.20.0.222:47503,
/10.20.0.222:47503, /127.0.0.1:47503], discPort=47503, order=44, intOrder=32,
lastExchangeTime=1464
363880917, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
[08:44:41,304][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
Topology snapshot [ver=44, servers=19, clients=1, CPUs=64, heap=160.0GB]
[08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager] Added
new node to topology: TcpDiscoveryNode
[id=6fae61a7-c1c1-40e5-8ad0-8bf5d6c86eb7, addrs=
[10.20.0.223, 127.0.0.1], sockAddrs=[fosters-223/10.20.0.223:47503,
/10.20.0.223:47503, /127.0.0.1:47503], discPort=47503, order=45, intOrder=33,
lastExchangeTime=1464
363910999, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
[08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
Topology snapshot [ver=45, servers=20, clients=1, CPUs=64, heap=170.0GB]
[08:45:19,942][INFO ][ignite-update-notifier-timer][GridUpdateNotifier] Update
status is not available.
[08:46:20,370][WARN ][main][GridCachePartitionExchangeManager] Failed to wait
for initial partition map exchange. Possible reasons are:
^-- Transactions in deadlock.
^-- Long running transactions (ignore if this is the case).
^-- Unreleased explicit locks.
[08:48:30,375][WARN ][main][GridCachePartitionExchangeManager] Still waiting
for initial partition map exchange ...
{noformat}
"Failed to wait for partition release future" warnings are on other nodes.
{noformat}
[08:09:45,822][WARN
][exchange-worker-#82%null%][GridDhtPartitionsExchangeFuture] Failed to wait
for partition release future [topVer=AffinityTopologyVersion [topVer=29,
minorTopVer=0], node=cab5d0e0-7365-4774-8f99-d9f131c5d896]. Dumping pending
objects that might be the cause:
[08:09:45,822][WARN
][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Ready affinity
version: AffinityTopologyVersion [topVer=28, minorTopVer=1]
[08:09:45,826][WARN
][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Last exchange
future: GridDhtPartitionsExchangeFuture ...
{noformat}
Load config:
- 1 client, 20 servers (5 servers per 1 host)
- warmup 60
- duration 66h
- preload 5M
- key range 10M
- operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
PUT_IF_ABSENT REPLACE
- backups count 3
- 3 servers restart every 15 min with 30 sec step, pause between stop and start
5min
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] ignite pull request: Format miliseconds as they will be 3 digits
Github user alpert closed the pull request at: https://github.com/apache/ignite/pull/534 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request: Filter client nodes when loading caches
Github user alpert closed the pull request at: https://github.com/apache/ignite/pull/719 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-3211) "Failed to reinitialize local partitions", "Failed to wait for completion of partition map exchange" errors during failover test
Ksenia Rybakova created IGNITE-3211:
---
Summary: "Failed to reinitialize local partitions", "Failed to
wait for completion of partition map exchange" errors during failover test
Key: IGNITE-3211
URL: https://issues.apache.org/jira/browse/IGNITE-3211
Project: Ignite
Issue Type: Bug
Affects Versions: 1.6
Reporter: Ksenia Rybakova
"Failed to reinitialize local partitions (preloading will be stopped)" and
"Failed to wait for completion of partition map exchange (preloading will not
start)" errors occured during failover load test. Complete stack trace see
below.
Load config:
- 1 client, 20 servers (5 servers per 1 host)
- warmup 60
- duration 66h
- preload 5M
- key range 10M
- operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
PUT_IF_ABSENT REPLACE
- backups count 3
- 3 servers restart every 15 min with 30 sec step, pause between stop and start
5min
{noformat}
[08:32:21,002][ERROR][exchange-worker-#83%null%][GridDhtPartitionsExchangeFuture]
Failed to reinitialize local partitions (preloading will be stopped):
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=39,
minorTopVer=1], nodeId=20ddc8b7, evt=DISCOVERY_CUSTOM_EVT]
class org.apache.ignite.IgniteException: null
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:506)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:297)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.toString(IgniteTxLocalAdapter.java:3743)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.toString(GridDhtTxLocalAdapter.java:868)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.toString(GridDhtTxLocal.java:703)
at java.lang.String.valueOf(String.java:2849)
at java.lang.StringBuilder.append(StringBuilder.java:128)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpPendingObjects(GridCachePartitionExchangeManager.java:1172)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpDebugInfo(GridCachePartitionExchangeManager.java:1150)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.dumpPendingObjects(GridDhtPartitionsExchangeFuture.java:894)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:769)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:715)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:472)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1333)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteException: null
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:506)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:364)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxStateImpl.toString(IgniteTxStateImpl.java:443)
at java.lang.String.valueOf(String.java:2849)
at
org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:474)
... 15 more
Caused by: java.util.ConcurrentModificationException
at
java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:394)
at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:413)
at java.util.LinkedHashMap$EntryIterator.next(LinkedHashMap.java:412)
at java.util.AbstractMap.toString(AbstractMap.java:518)
at java.lang.String.valueOf(String.java:2849)
at
org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:474)
... 20 more
[08:32:21,072][ERROR][exchange-worker-#83%null%][GridCachePartitionExchangeManager]
Failed to wait for completion of partition map exchange (preloading will not
start): GridDhtPartitionsExchangeFuture [dummy=false, forcePreload=false,
reassign=false, discoEvt=DiscoveryCustomEvent [cust
[GitHub] ignite pull request: ignite-db-x-10884
Github user sboikov closed the pull request at: https://github.com/apache/ignite/pull/729 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
