[jira] [Assigned] (IGNITE-3408) Need to provide basic implementation of AddressResolver
[
https://issues.apache.org/jira/browse/IGNITE-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko reassigned IGNITE-3408:
---
Assignee: Valentin Kulichenko
> Need to provide basic implementation of AddressResolver
> ---
>
> Key: IGNITE-3408
> URL: https://issues.apache.org/jira/browse/IGNITE-3408
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> Currently if user intends to use {{AddressResolver}}, he is forced to create
> his own implementation and deploy it on all nodes. This is a complete
> overkill for a simple mapping between internal and external addresses, which
> is actually needed in majority of cases.
> We can provide our own {{BasicAddressResolver}} which will contain a
> {{Map}} that will describe the mapping and can be easily
> specified in the XML configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3408) Need to provide basic implementation of AddressResolver
[
https://issues.apache.org/jira/browse/IGNITE-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358334#comment-15358334
]
Valentin Kulichenko commented on IGNITE-3408:
-
We can also create implementation for EC2, which will resolve the public DNS
using instance metadata:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
> Need to provide basic implementation of AddressResolver
> ---
>
> Key: IGNITE-3408
> URL: https://issues.apache.org/jira/browse/IGNITE-3408
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
> Fix For: 1.7
>
>
> Currently if user intends to use {{AddressResolver}}, he is forced to create
> his own implementation and deploy it on all nodes. This is a complete
> overkill for a simple mapping between internal and external addresses, which
> is actually needed in majority of cases.
> We can provide our own {{BasicAddressResolver}} which will contain a
> {{Map}} that will describe the mapping and can be easily
> specified in the XML configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3408) Need to provide basic implementation of AddressResolver
Valentin Kulichenko created IGNITE-3408:
---
Summary: Need to provide basic implementation of AddressResolver
Key: IGNITE-3408
URL: https://issues.apache.org/jira/browse/IGNITE-3408
Project: Ignite
Issue Type: Improvement
Components: general
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Fix For: 1.7
Currently if user intends to use {{AddressResolver}}, he is forced to create
his own implementation and deploy it on all nodes. This is a complete overkill
for a simple mapping between internal and external addresses, which is actually
needed in majority of cases.
We can provide our own {{BasicAddressResolver}} which will contain a
{{Map}} that will describe the mapping and can be easily
specified in the XML configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3407) HTTP REST: query commands without pageSize failed with NPE
Andrey Novikov created IGNITE-3407: -- Summary: HTTP REST: query commands without pageSize failed with NPE Key: IGNITE-3407 URL: https://issues.apache.org/jira/browse/IGNITE-3407 Project: Ignite Issue Type: Bug Components: general Affects Versions: 1.6 Reporter: Andrey Novikov org/apache/ignite/internal/processors/rest/handlers/query/QueryCommandHandler.java:125 Need return response with error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3394) Failed to load data from Oracle DB with type TIMESTAMP(6)
[
https://issues.apache.org/jira/browse/IGNITE-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko updated IGNITE-3394:
--
Attachment:
IGNITE_3394_Add_conversation_oracle_timestamp_type_to_java_type.patch
> Failed to load data from Oracle DB with type TIMESTAMP(6)
> -
>
> Key: IGNITE-3394
> URL: https://issues.apache.org/jira/browse/IGNITE-3394
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 1.7
>
> Attachments:
> IGNITE_3394_Add_conversation_oracle_timestamp_type_to_java_type.patch
>
>
> To test:
> # Run Oracle database.
> # Create user.
> # Create table by script:
> {code}
> create table ""."TEST" (
> "A" INTEGER PRIMARY KEY,
> "B" TIMESTAMP,
> "C" TIMESTAMP(0),
> "D" TIMESTAMP(1),
> "E" TIMESTAMP(2),
> "F" TIMESTAMP(3),
> "G" TIMESTAMP(4),
> "H" TIMESTAMP(5),
> "J" TIMESTAMP(6),
> "K" TIMESTAMP(7),
> "L" TIMESTAMP(8),
> "M" TIMESTAMP(9)
> );
> {code}
> # Fill table by script:
> {code}
> INSERT INTO ""."TEST" VALUES (1,
> TO_TIMESTAMP('10-SEP-0214:10:10','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.1','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.12','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.123','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.1234','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.12345','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.123456','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.1234567','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.12345678','DD-MON-RRHH24:MI:SS.FF'),
> TO_TIMESTAMP('10-SEP-0214:10:10.123456789','DD-MON-RRHH24:MI:SS.FF')
> );
> {code}
> # Open Gridgain Web Console: https://console.gridgain.com/.
> # Import model from database on Model page.
> # Create cluster on Cluster page and link with autogenerated cache.
> # Download project code on Summary page.
> # In class ServerNodeCodeStartup change code of main function to:
> {code}
> Ignite ignite =
> Ignition.start(ServerConfigurationFactory.createConfiguration());
> ignite.cache("TestCache").loadCache(null);
> {code}
> # Run node by using ServerNodeCodeStartup.main function.
> - Node should run without exceptions.
> # Return to GridGain Web Console and go to SQL page.
> # Execute query for data extraction from TestCache cache, f.e:
> {code}
> Select b,d,f,h,k,m FROM "TestCache".Test
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3406) Interceptor and continuous query can get incorrect old value during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358195#comment-15358195
]
Valentin Kulichenko edited comment on IGNITE-3406 at 7/1/16 1:19 AM:
-
Probably {{GridDhtForceKeysRequest}} is not needed here, because sending the
old value with update will cover both scenarios. This needs to be tested.
was (Author: vkulichenko):
Probably `GridDhtForceKeysRequest` is not needed here, because sending the old
value with update will cover both scenarios. This needs to be tested.
> Interceptor and continuous query can get incorrect old value during
> rebalancing
> ---
>
> Key: IGNITE-3406
> URL: https://issues.apache.org/jira/browse/IGNITE-3406
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
> Fix For: 1.7
>
>
> During the rebalancing the old value passed to interceptor or continuous
> query can't be wrong due to scenarios described below.
> Scenario 1.
> # New node joins.
> # Update request arrives to the new node before the entry for the same key is
> rebalanced to this node.
> # Listeners are notified with {{null}} old value.
> In this case we should use {{GridDhtForceKeysRequest}} to get the old value.
> Scenario 2.
> # Entry is updated on primary node.
> # New backup node joins and the entry with already updated value is
> rebalanced from the primary node.
> # Update request arrives to this new backup node.
> # Listeners are notified with the old value which is the same as new value.
> In this case we should send the old value with the update request in case
> there is ongoing rebalancing and cache has interceptor configured or
> continuous queries registered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3406) Interceptor and continuous query can get incorrect old value during rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358195#comment-15358195
]
Valentin Kulichenko commented on IGNITE-3406:
-
Probably `GridDhtForceKeysRequest` is not needed here, because sending the old
value with update will cover both scenarios. This needs to be tested.
> Interceptor and continuous query can get incorrect old value during
> rebalancing
> ---
>
> Key: IGNITE-3406
> URL: https://issues.apache.org/jira/browse/IGNITE-3406
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
> Fix For: 1.7
>
>
> During the rebalancing the old value passed to interceptor or continuous
> query can't be wrong due to scenarios described below.
> Scenario 1.
> # New node joins.
> # Update request arrives to the new node before the entry for the same key is
> rebalanced to this node.
> # Listeners are notified with {{null}} old value.
> In this case we should use {{GridDhtForceKeysRequest}} to get the old value.
> Scenario 2.
> # Entry is updated on primary node.
> # New backup node joins and the entry with already updated value is
> rebalanced from the primary node.
> # Update request arrives to this new backup node.
> # Listeners are notified with the old value which is the same as new value.
> In this case we should send the old value with the update request in case
> there is ongoing rebalancing and cache has interceptor configured or
> continuous queries registered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3406) Interceptor and continuous query can get incorrect old value during rebalancing
Valentin Kulichenko created IGNITE-3406:
---
Summary: Interceptor and continuous query can get incorrect old
value during rebalancing
Key: IGNITE-3406
URL: https://issues.apache.org/jira/browse/IGNITE-3406
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Fix For: 1.7
During the rebalancing the old value passed to interceptor or continuous query
can't be wrong due to scenarios described below.
Scenario 1.
# New node joins.
# Update request arrives to the new node before the entry for the same key is
rebalanced to this node.
# Listeners are notified with {{null}} old value.
In this case we should use {{GridDhtForceKeysRequest}} to get the old value.
Scenario 2.
# Entry is updated on primary node.
# New backup node joins and the entry with already updated value is rebalanced
from the primary node.
# Update request arrives to this new backup node.
# Listeners are notified with the old value which is the same as new value.
In this case we should send the old value with the update request in case there
is ongoing rebalancing and cache has interceptor configured or continuous
queries registered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3227) IgniteCache: add method to calculate size per partition
[
https://issues.apache.org/jira/browse/IGNITE-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357650#comment-15357650
]
Saikat Maitra commented on IGNITE-3227:
---
[~ilantukh]
Thank you so much for reviewing the files. I have fixed the typo error.
Regards
Saikat
> IgniteCache: add method to calculate size per partition
> ---
>
> Key: IGNITE-3227
> URL: https://issues.apache.org/jira/browse/IGNITE-3227
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Magda
>Assignee: Saikat Maitra
> Labels: community, important
>
> It makes sense to add size calculation per partition. Actually the following
> methods should be added to the {{IgniteCache}} API.
> {code}
> public int size(int partition, CachePeekMode... peekModes) throws
> CacheException;
> public int localSize(int partition, CachePeekMode... peekModes);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2680) Terminating running SQL queries
[
https://issues.apache.org/jira/browse/IGNITE-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357413#comment-15357413
]
Alexei Scherbakov commented on IGNITE-2680:
---
2 fixed. Added TimeUnit argument to setTimeout
3.Implemented code for running SQL queries using RunnableFuture.
This way the query can be run synchronously on asynchronously with cancellation
and timeout support.
TC is OK, waiting for review.
> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
> Labels: important
>
> If to start a long running SQL query over a huge cache will millions of
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1680) CPP: Implement basic API for user job lookup
[ https://issues.apache.org/jira/browse/IGNITE-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-1680: Summary: CPP: Implement basic API for user job lookup (was: CPP: Implement basic API for remote job execution) > CPP: Implement basic API for user job lookup > > > Key: IGNITE-1680 > URL: https://issues.apache.org/jira/browse/IGNITE-1680 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Igor Sapego >Assignee: Igor Sapego > Fix For: 1.7 > > > Need to implement IgniteCompute class for C++ with one basic method > IgniteCompute::Call(...) which will provide basic remote job execution API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3404) Single cpp node doesn't build during Apache Ignite C++ Build on Linux
[
https://issues.apache.org/jira/browse/IGNITE-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego resolved IGNITE-3404.
-
Resolution: Cannot Reproduce
Assignee: Vasilisa Sidorova (was: Igor Sapego)
Can not reproduce.
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
>
> Key: IGNITE-3404
> URL: https://issues.apache.org/jira/browse/IGNITE-3404
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
> Environment: Ubuntu 14.04
>Reporter: Vasilisa Sidorova
>Assignee: Vasilisa Sidorova
>
> -
> DESCRIPTION
> -
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
> STEPS FOR REPRODUCE
> -
> # Build Apache Ignite C++ Build according to instruction from
> platforms/cpp/DEVNOTES.txt:
> {noformat}
> Building the Apache Ignite C++ components:
> * Navigate to the directory $IGNITE_HOME/platforms/cpp
> * Execute the following commands one by one to build the project:
> * libtoolize && aclocal && autoheader && automake --add-missing &&
> autoreconf
> * ./configure
> * make
> {noformat}
> -
> EXPECTED RESULT
> -
> There is ignite binary in the cpp/ignite folder
> -
> ACTUAL RESULT
> -
> There isn't ignite binary in cpp/ignite folder after building
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName
[ https://issues.apache.org/jira/browse/IGNITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356945#comment-15356945 ] ASF GitHub Bot commented on IGNITE-3207: Github user f7753 closed the pull request at: https://github.com/apache/ignite/pull/842 > Rename IgniteConfiguration.gridName > --- > > Key: IGNITE-3207 > URL: https://issues.apache.org/jira/browse/IGNITE-3207 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Biao Ma > Fix For: 1.7 > > > We have got a TON of questions on gridName property. Everyone thinks that > clusters are formed based on the gridName, that is, nodes with the same grid > name will join one cluster, and nodes with a different name will be in a > separate cluster. > Let's do the following: > * Deprecate IgniteConfiguration.gridName > * Add IgniteConfiguration.localInstanceName > * Rename related parameters in Ignition class (and other places, if present) > * Update Javadoc: clearly state that this name only works locally and has no > effect on topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1915) .Net: Ignite as Entity Framework Second-Level Cache
[ https://issues.apache.org/jira/browse/IGNITE-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1915: Fix Version/s: 1.7 > .Net: Ignite as Entity Framework Second-Level Cache > --- > > Key: IGNITE-1915 > URL: https://issues.apache.org/jira/browse/IGNITE-1915 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: 1.7 > > > Entity Framework is #1 ORM for .NET > We should provide easy solution to boost Entity Framework performance with > Ignite. > EF5 and EF6 have different 2nd level cache mechanisms (EF5 has a built-in > one, EF6 requies more customization or a 3rd party lib like > https://efcache.codeplex.com/). For now, let's do EF6 only. > This should be in a separate assembly and a separate NuGet package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName
[ https://issues.apache.org/jira/browse/IGNITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356931#comment-15356931 ] ASF GitHub Bot commented on IGNITE-3207: GitHub user f7753 opened a pull request: https://github.com/apache/ignite/pull/842 IGNITE-3207 Rename IgniteConfiguration.gridName - Deprecate IgniteConfiguration.gridName - Add IgniteConfiguration.localInstanceName - Rename related parameters in Ignition class (and other places, if present) - Update Javadoc: clearly state that this name only works locally and has no effect on topology. You can merge this pull request into a Git repository by running: $ git pull https://github.com/f7753/ignite ignite-3207 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/842.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 #842 > Rename IgniteConfiguration.gridName > --- > > Key: IGNITE-3207 > URL: https://issues.apache.org/jira/browse/IGNITE-3207 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Biao Ma > Fix For: 1.7 > > > We have got a TON of questions on gridName property. Everyone thinks that > clusters are formed based on the gridName, that is, nodes with the same grid > name will join one cluster, and nodes with a different name will be in a > separate cluster. > Let's do the following: > * Deprecate IgniteConfiguration.gridName > * Add IgniteConfiguration.localInstanceName > * Rename related parameters in Ignition class (and other places, if present) > * Update Javadoc: clearly state that this name only works locally and has no > effect on topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3405) IGFS: Do not allow DUAL -> PRIMARY -> DUAL modes interleaving.
Vladimir Ozerov created IGNITE-3405:
---
Summary: IGFS: Do not allow DUAL -> PRIMARY -> DUAL modes
interleaving.
Key: IGNITE-3405
URL: https://issues.apache.org/jira/browse/IGNITE-3405
Project: Ignite
Issue Type: Bug
Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Ivan Veselovsky
Priority: Critical
Fix For: 1.7
Currently we allow almost any combinations of path modes. This appears to be
wrong. Consider the following scenario:
1) /dir1 -> PRIMARY
2) /dir1/dir2 -> DUAL
It is impossible to support this scenario properly because {{dir1}} will be
created in both file systems anyway, but primary and secondary representation
will be "detached" from each other.
Instead, we should allow only DUAL -> PRIMARY and DUAL -> PROXY transitions.
Any other combinations doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3245) IGFS: Optimize performance for client nodes.
[ https://issues.apache.org/jira/browse/IGNITE-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3245. - Resolution: Fixed > IGFS: Optimize performance for client nodes. > > > Key: IGNITE-3245 > URL: https://issues.apache.org/jira/browse/IGNITE-3245 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.7 > > > *Problem* > Ignite can work in two modes - server (default) and client. Both modes > provide transparent cache API. > IGFS heavily rely on cache operations and sometimes perform lots of them with > assumption that metadata is located on the same node, so these operations are > cheap and do not require any cross-node communication. > But when user works with IGFS from client node, this code could be very > inefficient because even single operation could cause many network round > trips between a client and a server. > *Solution* > Provide special implementations of IGFS operations which will delegate the > whole execution to the server, thus leaving only a single network round trip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3245) IGFS: Optimize performance for client nodes.
[ https://issues.apache.org/jira/browse/IGNITE-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3245. --- > IGFS: Optimize performance for client nodes. > > > Key: IGNITE-3245 > URL: https://issues.apache.org/jira/browse/IGNITE-3245 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.7 > > > *Problem* > Ignite can work in two modes - server (default) and client. Both modes > provide transparent cache API. > IGFS heavily rely on cache operations and sometimes perform lots of them with > assumption that metadata is located on the same node, so these operations are > cheap and do not require any cross-node communication. > But when user works with IGFS from client node, this code could be very > inefficient because even single operation could cause many network round > trips between a client and a server. > *Solution* > Provide special implementations of IGFS operations which will delegate the > whole execution to the server, thus leaving only a single network round trip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.
[ https://issues.apache.org/jira/browse/IGNITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3335: Labels: important performance (was: performance) > IGFS: Route client requests only to metadata affinity nodes. > - > > Key: IGNITE-3335 > URL: https://issues.apache.org/jira/browse/IGNITE-3335 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: important, performance > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3335) IGFS: Route client requests only to metadata affinity nodes.
[ https://issues.apache.org/jira/browse/IGNITE-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3335: Labels: performance (was: ) > IGFS: Route client requests only to metadata affinity nodes. > - > > Key: IGNITE-3335 > URL: https://issues.apache.org/jira/browse/IGNITE-3335 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: important, performance > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3332) IGFS: Use task for file unlock routine on client nodes.
[ https://issues.apache.org/jira/browse/IGNITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3332: Issue Type: Task (was: Sub-task) Parent: (was: IGNITE-3245) > IGFS: Use task for file unlock routine on client nodes. > --- > > Key: IGNITE-3332 > URL: https://issues.apache.org/jira/browse/IGNITE-3332 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: important, perfomance > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3332) IGFS: Use task for file unlock routine on client nodes.
[ https://issues.apache.org/jira/browse/IGNITE-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3332: Labels: important perfomance (was: ) > IGFS: Use task for file unlock routine on client nodes. > --- > > Key: IGNITE-3332 > URL: https://issues.apache.org/jira/browse/IGNITE-3332 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: important, perfomance > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.
[ https://issues.apache.org/jira/browse/IGNITE-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3331: Labels: important perfomance (was: perfomance) > IGFS: Route client tasks to primary node when metadata co-location is enabled. > -- > > Key: IGNITE-3331 > URL: https://issues.apache.org/jira/browse/IGNITE-3331 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important, perfomance > Fix For: 1.7 > > > Currently we route IGFS client tasks to random metadata data node. When > co-location is enabled, it makes sense to requests which are going to change > metadata directly to primary node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3331) IGFS: Route client tasks to primary node when metadata co-location is enabled.
[ https://issues.apache.org/jira/browse/IGNITE-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3331: Issue Type: Task (was: Sub-task) Parent: (was: IGNITE-3245) > IGFS: Route client tasks to primary node when metadata co-location is enabled. > -- > > Key: IGNITE-3331 > URL: https://issues.apache.org/jira/browse/IGNITE-3331 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important, perfomance > Fix For: 1.7 > > > Currently we route IGFS client tasks to random metadata data node. When > co-location is enabled, it makes sense to requests which are going to change > metadata directly to primary node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3383) Hadoop: Ensure that component start exception doesn't stop node startup if the component is optional.
[ https://issues.apache.org/jira/browse/IGNITE-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3383. --- > Hadoop: Ensure that component start exception doesn't stop node startup if > the component is optional. > - > > Key: IGNITE-3383 > URL: https://issues.apache.org/jira/browse/IGNITE-3383 > Project: Ignite > Issue Type: Task > Components: hadoop >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.7 > > > In this case we should: > 1) Print a warning > 2) Fallback to no-op. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3404) Single cpp node doesn't build during Apache Ignite C++ Build on Linux
[
https://issues.apache.org/jira/browse/IGNITE-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-3404:
---
Assignee: Igor Sapego
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
>
> Key: IGNITE-3404
> URL: https://issues.apache.org/jira/browse/IGNITE-3404
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
> Environment: Ubuntu 14.04
>Reporter: Vasilisa Sidorova
>Assignee: Igor Sapego
>
> -
> DESCRIPTION
> -
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
> STEPS FOR REPRODUCE
> -
> # Build Apache Ignite C++ Build according to instruction from
> platforms/cpp/DEVNOTES.txt:
> {noformat}
> Building the Apache Ignite C++ components:
> * Navigate to the directory $IGNITE_HOME/platforms/cpp
> * Execute the following commands one by one to build the project:
> * libtoolize && aclocal && autoheader && automake --add-missing &&
> autoreconf
> * ./configure
> * make
> {noformat}
> -
> EXPECTED RESULT
> -
> There is ignite binary in the cpp/ignite folder
> -
> ACTUAL RESULT
> -
> There isn't ignite binary in cpp/ignite folder after building
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3404) Single cpp node doesn't build during Apache Ignite C++ Build on Linux
[
https://issues.apache.org/jira/browse/IGNITE-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-3404:
Description:
-
DESCRIPTION
-
Single cpp node doesn't build during Apache Ignite C++ Build on Linux
-
STEPS FOR REPRODUCE
-
# Build Apache Ignite C++ Build according to instruction from
platforms/cpp/DEVNOTES.txt:
{noformat}
Building the Apache Ignite C++ components:
* Navigate to the directory $IGNITE_HOME/platforms/cpp
* Execute the following commands one by one to build the project:
* libtoolize && aclocal && autoheader && automake --add-missing &&
autoreconf
* ./configure
* make
{noformat}
-
EXPECTED RESULT
-
There is ignite binary in the cpp/ignite folder
-
ACTUAL RESULT
-
There isn't ignite binary in cpp/ignite folder after building
was:
-
DESCRIPTION
-
Single cpp node doesn't build during Apache Ignite C++ Build on Linux
-
STEPS FOR REPRODUCE
-
# Build Apache Ignite C++ Build according to instruction from
platforms/cpp/DEVNOTES.txt:
{noformat}
Building the Apache Ignite C++ components:
* Navigate to the directory $IGNITE_HOME/platforms/cpp
* Execute the following commands one by one to build the project:
* libtoolize && aclocal && autoheader && automake --add-missing &&
autoreconf
* ./configure
* make
{noformat}
-
EXPECTED RESULT
-
There is ignite binary in the cpp/ignite folder
-
ACTUAL RESULT
-
There isn't cpp/ignite folder after building
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
>
> Key: IGNITE-3404
> URL: https://issues.apache.org/jira/browse/IGNITE-3404
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
> Environment: Ubuntu 14.04
>Reporter: Vasilisa Sidorova
>
> -
> DESCRIPTION
> -
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
> STEPS FOR REPRODUCE
> -
> # Build Apache Ignite C++ Build according to instruction from
> platforms/cpp/DEVNOTES.txt:
> {noformat}
> Building the Apache Ignite C++ components:
> * Navigate to the directory $IGNITE_HOME/platforms/cpp
> * Execute the following commands one by one to build the project:
> * libtoolize && aclocal && autoheader && automake --add-missing &&
> autoreconf
> * ./configure
> * make
> {noformat}
> -
> EXPECTED RESULT
> -
> There is ignite binary in the cpp/ignite folder
> -
> ACTUAL RESULT
> -
> There isn't ignite binary in cpp/ignite folder after building
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3404) Single cpp node doesn't build during Apache Ignite C++ Build on Linux
[
https://issues.apache.org/jira/browse/IGNITE-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-3404:
Description:
-
DESCRIPTION
-
Single cpp node doesn't build during Apache Ignite C++ Build on Linux
-
STEPS FOR REPRODUCE
-
# Build Apache Ignite C++ Build according to instruction from
platforms/cpp/DEVNOTES.txt:
{noformat}
Building the Apache Ignite C++ components:
* Navigate to the directory $IGNITE_HOME/platforms/cpp
* Execute the following commands one by one to build the project:
* libtoolize && aclocal && autoheader && automake --add-missing &&
autoreconf
* ./configure
* make
{noformat}
-
EXPECTED RESULT
-
There is ignite binary in the cpp/ignite folder
-
ACTUAL RESULT
-
There isn't cpp/ignite folder after building
was:
-
DESCRIPTION
-
Single cpp node doesn't build during Apache Ignite C++ Build on Linux
-
STEPS FOR REPRODUCE
-
# Build Apache Ignite C++ Build according to instruction from
platforms/cpp/DEVNOTES.txt:
{noformat}
Building the Apache Ignite C++ components:
* Navigate to the directory $IGNITE_HOME/platforms/cpp
* Execute the following commands one by one to build the project:
* libtoolize && aclocal && autoheader && automake --add-missing &&
autoreconf
* ./configure
* make
{noformat}
-
ACTUAL RESULT
-
There is ignite.sh in the cpp/ignite folder
-
EXPECTED RESULT
-
There isn't cpp/ignite folder after building
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
>
> Key: IGNITE-3404
> URL: https://issues.apache.org/jira/browse/IGNITE-3404
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
> Environment: Ubuntu 14.04
>Reporter: Vasilisa Sidorova
>
> -
> DESCRIPTION
> -
> Single cpp node doesn't build during Apache Ignite C++ Build on Linux
> -
> STEPS FOR REPRODUCE
> -
> # Build Apache Ignite C++ Build according to instruction from
> platforms/cpp/DEVNOTES.txt:
> {noformat}
> Building the Apache Ignite C++ components:
> * Navigate to the directory $IGNITE_HOME/platforms/cpp
> * Execute the following commands one by one to build the project:
> * libtoolize && aclocal && autoheader && automake --add-missing &&
> autoreconf
> * ./configure
> * make
> {noformat}
> -
> EXPECTED RESULT
> -
> There is ignite binary in the cpp/ignite folder
> -
> ACTUAL RESULT
> -
> There isn't cpp/ignite folder after building
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3404) Single cpp node doesn't build during Apache Ignite C++ Build on Linux
Vasilisa Sidorova created IGNITE-3404:
--
Summary: Single cpp node doesn't build during Apache Ignite C++
Build on Linux
Key: IGNITE-3404
URL: https://issues.apache.org/jira/browse/IGNITE-3404
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.6
Environment: Ubuntu 14.04
Reporter: Vasilisa Sidorova
-
DESCRIPTION
-
Single cpp node doesn't build during Apache Ignite C++ Build on Linux
-
STEPS FOR REPRODUCE
-
# Build Apache Ignite C++ Build according to instruction from
platforms/cpp/DEVNOTES.txt:
{noformat}
Building the Apache Ignite C++ components:
* Navigate to the directory $IGNITE_HOME/platforms/cpp
* Execute the following commands one by one to build the project:
* libtoolize && aclocal && autoheader && automake --add-missing &&
autoreconf
* ./configure
* make
{noformat}
-
ACTUAL RESULT
-
There is ignite.sh in the cpp/ignite folder
-
EXPECTED RESULT
-
There isn't cpp/ignite folder after building
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3021) Test org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated fails sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356888#comment-15356888
]
Ivan Veselovsky commented on IGNITE-3021:
-
Invocation in the test beginning {code}awaitPartitionMapExchange();{code} or
{code}IgniteConfiguration cfg =
cfg.setLateAffinityAssignment(false);
{code}
when making the configuration solves the problem. Reason is that before initial
partition map exchange affinity function considers one node to be backup of
another, so it may really return 2 nodes.
> Test
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated
> fails sometimes.
>
>
> Key: IGNITE-3021
> URL: https://issues.apache.org/jira/browse/IGNITE-3021
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Test
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated
> fails sometimes on master branch:
> {code}
> --- Stderr: ---
> [15:16:32,400][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<1> but was:<2>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest.testCreateFileColocated(IgfsStreamsSelfTest.java:237)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1759)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1697)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The problem is that data cache rebalancing happens during the test, that
> causes data blocks affinity calculation to be not reproducible: block that
> initially maps to 0-th node after some time maps to a different node.
> Suggested fix is to switch off automatic rebelancing, and do the rebalancing
> manually only once upon the test beginning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3403) Cache partitions task should return public entries information only.
[ https://issues.apache.org/jira/browse/IGNITE-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356873#comment-15356873 ] Vasiliy Sisko edited comment on IGNITE-3403 at 6/30/16 10:25 AM: - Changed to collect only information about public entries. ignite-3403 was (Author: vsisko): Changed to collect only information about public entries. > Cache partitions task should return public entries information only. > > > Key: IGNITE-3403 > URL: https://issues.apache.org/jira/browse/IGNITE-3403 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 1.7 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > > Partitions information include data about internal cache entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3403) Cache partitions task should return public entries information only.
[ https://issues.apache.org/jira/browse/IGNITE-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356873#comment-15356873 ] Vasiliy Sisko commented on IGNITE-3403: --- Changed to collect only information about public entries. > Cache partitions task should return public entries information only. > > > Key: IGNITE-3403 > URL: https://issues.apache.org/jira/browse/IGNITE-3403 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 1.7 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 1.7 > > > Partitions information include data about internal cache entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3403) Cache partitions task should return public entries information only.
Vasiliy Sisko created IGNITE-3403: - Summary: Cache partitions task should return public entries information only. Key: IGNITE-3403 URL: https://issues.apache.org/jira/browse/IGNITE-3403 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 1.7 Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Fix For: 1.7 Partitions information include data about internal cache entries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3021) Test org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated fails sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-3021.
---
> Test
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated
> fails sometimes.
>
>
> Key: IGNITE-3021
> URL: https://issues.apache.org/jira/browse/IGNITE-3021
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Test
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated
> fails sometimes on master branch:
> {code}
> --- Stderr: ---
> [15:16:32,400][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<1> but was:<2>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest.testCreateFileColocated(IgfsStreamsSelfTest.java:237)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1759)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1697)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The problem is that data cache rebalancing happens during the test, that
> causes data blocks affinity calculation to be not reproducible: block that
> initially maps to 0-th node after some time maps to a different node.
> Suggested fix is to switch off automatic rebelancing, and do the rebalancing
> manually only once upon the test beginning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3021) Test org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated fails sometimes.
[
https://issues.apache.org/jira/browse/IGNITE-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-3021.
-
Resolution: Fixed
Assignee: Vladimir Ozerov (was: Ivan Veselovsky)
> Test
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated
> fails sometimes.
>
>
> Key: IGNITE-3021
> URL: https://issues.apache.org/jira/browse/IGNITE-3021
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Test
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest#testCreateFileColocated
> fails sometimes on master branch:
> {code}
> --- Stderr: ---
> [15:16:32,400][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<1> but was:<2>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.ignite.internal.processors.igfs.IgfsStreamsSelfTest.testCreateFileColocated(IgfsStreamsSelfTest.java:237)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1759)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1697)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The problem is that data cache rebalancing happens during the test, that
> causes data blocks affinity calculation to be not reproducible: block that
> initially maps to 0-th node after some time maps to a different node.
> Suggested fix is to switch off automatic rebelancing, and do the rebalancing
> manually only once upon the test beginning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2310) Lock cache partition for affinityRun/affinityCall execution
[
https://issues.apache.org/jira/browse/IGNITE-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356842#comment-15356842
]
Taras Ledkov commented on IGNITE-2310:
--
The patch is available at the branch
[ignite-2310|https://github.com/gridgain/apache-ignite/tree/ignite-2310].
Please pay you attention to:
* the IgniteCacheLockPartitionOnAffinityRunTest test.
The test testLockPartitionOnAffinityRunByDhtPartition is stable passed but the
test testLockPartitionOnAffinityRunByLocalSql fails with stable
reproducibility. Look like there are some issues at the local SQL query.
* changes at the IgniteCompute public interface. Should we do any change in
methods affinityRun/Call with specified partitions to reserve?
> Lock cache partition for affinityRun/affinityCall execution
> ---
>
> Key: IGNITE-2310
> URL: https://issues.apache.org/jira/browse/IGNITE-2310
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
> Labels: community
> Fix For: 1.7
>
>
> Partition of a key passed to {{affinityRun}} must be located on the affinity
> node when a compute job is being sent to the node. The partition has to be
> locked on the cache until the compute job is being executed. This will let to
> execute queries safely (Scan or local SQL) over the data that is located
> locally in the locked partition.
> In addition Ignite Compute API has to be extended by adding {{affinityCall}}
> and {{affinityRun}} methods that accept list of caches which partitions have
> to be locked at the time a compute task is being executed.
> Test cases to validate the functionality:
> 1) local SQL query over data located in a concrete partition in multple
> caches.
> - create cache Organisation cache and create Persons cache.
> - collocate Persons by 'organisationID';
> - send {{affinityRun}} using 'organisationID' as an affinity key and passing
> Organisation and Persons caches' names to the method to be sure that the
> partition will be locked on caches;
> - execute local SQL query "SELECT * FROM Persons as p, Organisation as o
> WHERE p.orgId=o.id' on a changing topology. The result set must be complete,
> the partition over which the query will be executed mustn't be moved to the
> other node. Due to affinity collocation the partition number will be the same
> for all Persons that belong to particular 'organisationID'
> 2) Scan Query over particular partition that is locked when {{affinityCall}}
> is executed.
> UPD (YZ May, 31)
> # If closure arrives to node but partition is not there it should be silently
> failed over to current owner.
> # I don't think user should provide list of caches. How about reserving only
> one partition, but evict partitions after all partitions in all caches (with
> same affinity function) on this node are locked for eviction. [~sboikov], can
> you please comment? It seems this should work faster for closures and will
> hardly affect rebalancing stuff.
> # I would add method {{affinityCall(int partId, String cacheName,
> IgniteCallable)}} and same for Runnable. This will allow me not to mess with
> affinity key in case I know partition before.
> UPD (SB, June, 01)
> Yakov, I think it is possible to implement this 'locking for evictions'
> approach, but personally I better like partitions reservation:
> - approach with reservation already implemented and works fine in sql queries
> - partition reservation is just CAS operation, if we need do ~10 reservation
> I think this will be negligible comparing to job execution time
> - now caches are rebalanced completely independently and changing this be
> complicated refactoring
> - I see some difficulties how to understand that caches have same affinity.
> If user uses custom function should he implement 'equals'? For standard
> affinity functions user can set backup filter, what do in this case? should
> user implement 'equals' for filter? Even if affinity functions are the same
> cache configuration can have node filter, so affinity mapping will be
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3402) "Remote node ID is not as expected" errors at driver during load test
[
https://issues.apache.org/jira/browse/IGNITE-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ksenia Rybakova closed IGNITE-3402.
---
> "Remote node ID is not as expected" errors at driver during load test
> -
>
> Key: IGNITE-3402
> URL: https://issues.apache.org/jira/browse/IGNITE-3402
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ksenia Rybakova
>Assignee: Ksenia Rybakova
> Fix For: 1.7
>
>
> A lot of errors at some drivers after several minutes after grid is up during
> load test:
> {noformat}
> [14:33:42] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Failed to send
> message (node may have left the grid or TCP connection cannot be established
> due to fir
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1193)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.submit(DataStreamerImpl.java:1378)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.update(DataStreamerImpl.java:1173)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:756)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:568)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:604)
> at
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark$1.run(IgniteCacheRandomOperationBenchmark.java:383)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
> message to remote node: TcpDiscoveryNode
> [id=11da20f5-87c5-4321-8163-ffef85f2d54c, addrs=[10.20.0.215, 127.0.0.1],
> sockAddrs=[/127.0.0.1:47503, fosters-215/10.20.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1986)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1926)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1124)
> ... 7 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect
> to node (is node still alive?). Make sure that each GridComputeTask and
> GridCacheTransaction has a timeout set in order to prevent parties from
> waiting forever
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2489)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2130)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2024)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1960)
> ... 9 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> connect to address: fosters-215/10.20.0.215:47103
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> read remote node recovery handshake (connection closed).
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2699)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> connect to address: /127.0.0.1:47103
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Remote
> node ID is not as expected [expected=11da20f5-87c5-4321-8163-ffef85f2d54c,
> rcvd=03bc7d54-4fec-481d-af24-6f5408b32fe2]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2604)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> {noformat}
> Tested version: 1.5.27
> Load config:
> - 7 hosts with 4 servers and 3 drivers each (28 servers and 21 drivers in
> total)
> -
[jira] [Resolved] (IGNITE-3402) "Remote node ID is not as expected" errors at driver during load test
[
https://issues.apache.org/jira/browse/IGNITE-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ksenia Rybakova resolved IGNITE-3402.
-
Resolution: Duplicate
Jira accidentally created two identical issues IGNITE-3401 and IGNITE-3402.
> "Remote node ID is not as expected" errors at driver during load test
> -
>
> Key: IGNITE-3402
> URL: https://issues.apache.org/jira/browse/IGNITE-3402
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ksenia Rybakova
>Assignee: Ksenia Rybakova
> Fix For: 1.7
>
>
> A lot of errors at some drivers after several minutes after grid is up during
> load test:
> {noformat}
> [14:33:42] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Failed to send
> message (node may have left the grid or TCP connection cannot be established
> due to fir
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1193)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.submit(DataStreamerImpl.java:1378)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.update(DataStreamerImpl.java:1173)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:756)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:568)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:604)
> at
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark$1.run(IgniteCacheRandomOperationBenchmark.java:383)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
> message to remote node: TcpDiscoveryNode
> [id=11da20f5-87c5-4321-8163-ffef85f2d54c, addrs=[10.20.0.215, 127.0.0.1],
> sockAddrs=[/127.0.0.1:47503, fosters-215/10.20.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1986)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1926)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1124)
> ... 7 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect
> to node (is node still alive?). Make sure that each GridComputeTask and
> GridCacheTransaction has a timeout set in order to prevent parties from
> waiting forever
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2489)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2130)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2024)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1960)
> ... 9 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> connect to address: fosters-215/10.20.0.215:47103
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> read remote node recovery handshake (connection closed).
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2699)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> connect to address: /127.0.0.1:47103
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Remote
> node ID is not as expected [expected=11da20f5-87c5-4321-8163-ffef85f2d54c,
> rcvd=03bc7d54-4fec-481d-af24-6f5408b32fe2]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2604)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> {noformat}
> Tested version:
[jira] [Assigned] (IGNITE-3402) "Remote node ID is not as expected" errors at driver during load test
[
https://issues.apache.org/jira/browse/IGNITE-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ksenia Rybakova reassigned IGNITE-3402:
---
Assignee: Ksenia Rybakova
> "Remote node ID is not as expected" errors at driver during load test
> -
>
> Key: IGNITE-3402
> URL: https://issues.apache.org/jira/browse/IGNITE-3402
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ksenia Rybakova
>Assignee: Ksenia Rybakova
> Fix For: 1.7
>
>
> A lot of errors at some drivers after several minutes after grid is up during
> load test:
> {noformat}
> [14:33:42] (err) Failed to execute compound future reducer: Compound future
> listener []class org.apache.ignite.IgniteCheckedException: Failed to send
> message (node may have left the grid or TCP connection cannot be established
> due to fir
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1193)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.submit(DataStreamerImpl.java:1378)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.update(DataStreamerImpl.java:1173)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:756)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:568)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:604)
> at
> org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark$1.run(IgniteCacheRandomOperationBenchmark.java:383)
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
> message to remote node: TcpDiscoveryNode
> [id=11da20f5-87c5-4321-8163-ffef85f2d54c, addrs=[10.20.0.215, 127.0.0.1],
> sockAddrs=[/127.0.0.1:47503, fosters-215/10.20.0
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1986)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1926)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1124)
> ... 7 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect
> to node (is node still alive?). Make sure that each GridComputeTask and
> GridCacheTransaction has a timeout set in order to prevent parties from
> waiting forever
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2489)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2130)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2024)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1960)
> ... 9 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> connect to address: fosters-215/10.20.0.215:47103
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> read remote node recovery handshake (connection closed).
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2699)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> connect to address: /127.0.0.1:47103
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
> ... 12 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Remote
> node ID is not as expected [expected=11da20f5-87c5-4321-8163-ffef85f2d54c,
> rcvd=03bc7d54-4fec-481d-af24-6f5408b32fe2]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2604)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
> ... 12 more
> {noformat}
> Tested version: 1.5.27
> Load config:
> - 7 hosts with 4 servers and 3 drivers each (28
[jira] [Commented] (IGNITE-2310) Lock cache partition for affinityRun/affinityCall execution
[
https://issues.apache.org/jira/browse/IGNITE-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356806#comment-15356806
]
ASF GitHub Bot commented on IGNITE-2310:
Github user tledkov-gridgain closed the pull request at:
https://github.com/apache/ignite/pull/769
> Lock cache partition for affinityRun/affinityCall execution
> ---
>
> Key: IGNITE-2310
> URL: https://issues.apache.org/jira/browse/IGNITE-2310
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Critical
> Labels: community
> Fix For: 1.7
>
>
> Partition of a key passed to {{affinityRun}} must be located on the affinity
> node when a compute job is being sent to the node. The partition has to be
> locked on the cache until the compute job is being executed. This will let to
> execute queries safely (Scan or local SQL) over the data that is located
> locally in the locked partition.
> In addition Ignite Compute API has to be extended by adding {{affinityCall}}
> and {{affinityRun}} methods that accept list of caches which partitions have
> to be locked at the time a compute task is being executed.
> Test cases to validate the functionality:
> 1) local SQL query over data located in a concrete partition in multple
> caches.
> - create cache Organisation cache and create Persons cache.
> - collocate Persons by 'organisationID';
> - send {{affinityRun}} using 'organisationID' as an affinity key and passing
> Organisation and Persons caches' names to the method to be sure that the
> partition will be locked on caches;
> - execute local SQL query "SELECT * FROM Persons as p, Organisation as o
> WHERE p.orgId=o.id' on a changing topology. The result set must be complete,
> the partition over which the query will be executed mustn't be moved to the
> other node. Due to affinity collocation the partition number will be the same
> for all Persons that belong to particular 'organisationID'
> 2) Scan Query over particular partition that is locked when {{affinityCall}}
> is executed.
> UPD (YZ May, 31)
> # If closure arrives to node but partition is not there it should be silently
> failed over to current owner.
> # I don't think user should provide list of caches. How about reserving only
> one partition, but evict partitions after all partitions in all caches (with
> same affinity function) on this node are locked for eviction. [~sboikov], can
> you please comment? It seems this should work faster for closures and will
> hardly affect rebalancing stuff.
> # I would add method {{affinityCall(int partId, String cacheName,
> IgniteCallable)}} and same for Runnable. This will allow me not to mess with
> affinity key in case I know partition before.
> UPD (SB, June, 01)
> Yakov, I think it is possible to implement this 'locking for evictions'
> approach, but personally I better like partitions reservation:
> - approach with reservation already implemented and works fine in sql queries
> - partition reservation is just CAS operation, if we need do ~10 reservation
> I think this will be negligible comparing to job execution time
> - now caches are rebalanced completely independently and changing this be
> complicated refactoring
> - I see some difficulties how to understand that caches have same affinity.
> If user uses custom function should he implement 'equals'? For standard
> affinity functions user can set backup filter, what do in this case? should
> user implement 'equals' for filter? Even if affinity functions are the same
> cache configuration can have node filter, so affinity mapping will be
> different.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3227) IgniteCache: add method to calculate size per partition
[
https://issues.apache.org/jira/browse/IGNITE-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356793#comment-15356793
]
Ilya Lantukh commented on IGNITE-3227:
--
[~samaitra],
Please fix a typo in variable name:
{code}GridDhtLocalPartition gridDthLocalPartition{code}
Beside that, everything looks fine to me.
> IgniteCache: add method to calculate size per partition
> ---
>
> Key: IGNITE-3227
> URL: https://issues.apache.org/jira/browse/IGNITE-3227
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Magda
>Assignee: Saikat Maitra
> Labels: community, important
>
> It makes sense to add size calculation per partition. Actually the following
> methods should be added to the {{IgniteCache}} API.
> {code}
> public int size(int partition, CachePeekMode... peekModes) throws
> CacheException;
> public int localSize(int partition, CachePeekMode... peekModes);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3371) .NET: Configure PlatformAffinityFunction in Spring
[ https://issues.apache.org/jira/browse/IGNITE-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-3371. -- > .NET: Configure PlatformAffinityFunction in Spring > -- > > Key: IGNITE-3371 > URL: https://issues.apache.org/jira/browse/IGNITE-3371 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > Add PlatformAffinityFunction.typeName property to initialize a user-defined > function with Reflection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3400) IGFS: Does not correctly deallocate free space in courner case.
[ https://issues.apache.org/jira/browse/IGNITE-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3400: Assignee: Ivan Veselovsky > IGFS: Does not correctly deallocate free space in courner case. > --- > > Key: IGNITE-3400 > URL: https://issues.apache.org/jira/browse/IGNITE-3400 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.7 >Reporter: Vasiliy Sisko >Assignee: Ivan Veselovsky > Fix For: 1.7 > > > Steps to reproduce: > 1) Run node with configured IGFS limited by max space (f.e. 104857600). > 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb) > 3) Copy to IGFS file with size more than free space size. > Second file have 0 size in IGFS. Used IGFS size approximately equal to the > IGFS space size. > 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. > 10-15 Mb) > New file have 0 size. > 5) Remove all files of format IGFS > IGFS free space approximately equal to the size of first file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3402) "Remote node ID is not as expected" errors at driver during load test
Ksenia Rybakova created IGNITE-3402:
---
Summary: "Remote node ID is not as expected" errors at driver
during load test
Key: IGNITE-3402
URL: https://issues.apache.org/jira/browse/IGNITE-3402
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Ksenia Rybakova
Fix For: 1.7
A lot of errors at some drivers after several minutes after grid is up during
load test:
{noformat}
[14:33:42] (err) Failed to execute compound future reducer: Compound future
listener []class org.apache.ignite.IgniteCheckedException: Failed to send
message (node may have left the grid or TCP connection cannot be established
due to fir
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1193)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.submit(DataStreamerImpl.java:1378)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.update(DataStreamerImpl.java:1173)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:756)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:568)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:604)
at
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark$1.run(IgniteCacheRandomOperationBenchmark.java:383)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
message to remote node: TcpDiscoveryNode
[id=11da20f5-87c5-4321-8163-ffef85f2d54c, addrs=[10.20.0.215, 127.0.0.1],
sockAddrs=[/127.0.0.1:47503, fosters-215/10.20.0
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1986)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1926)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1124)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect to
node (is node still alive?). Make sure that each GridComputeTask and
GridCacheTransaction has a timeout set in order to prevent parties from waiting
forever
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2489)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2130)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2024)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1960)
... 9 more
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
connect to address: fosters-215/10.20.0.215:47103
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
... 12 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
read remote node recovery handshake (connection closed).
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2699)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
... 12 more
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
connect to address: /127.0.0.1:47103
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
... 12 more
Caused by: class org.apache.ignite.IgniteCheckedException: Remote node
ID is not as expected [expected=11da20f5-87c5-4321-8163-ffef85f2d54c,
rcvd=03bc7d54-4fec-481d-af24-6f5408b32fe2]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2604)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
... 12 more
{noformat}
Tested version: 1.5.27
Load config:
- 7 hosts with 4 servers and 3 drivers each (28 servers and 21 drivers in total)
- benchmark: IgniteCacheRandomOperationBenchmark
- preload: 2M
- key range: 4M
- warmup: 30s
- duration: 10h
- operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
PUT_IF_ABSENT REPLACE
-backup count: 1
- GC: G1
- heap size: 8Gb for servers, 4Gb for drivers
- caches:
{noformat}
[jira] [Updated] (IGNITE-3400) IGFS: Does not correctly deallocate free space in courner case.
[ https://issues.apache.org/jira/browse/IGNITE-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3400: Fix Version/s: 1.7 > IGFS: Does not correctly deallocate free space in courner case. > --- > > Key: IGNITE-3400 > URL: https://issues.apache.org/jira/browse/IGNITE-3400 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.7 >Reporter: Vasiliy Sisko > Fix For: 1.7 > > > Steps to reproduce: > 1) Run node with configured IGFS limited by max space (f.e. 104857600). > 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb) > 3) Copy to IGFS file with size more than free space size. > Second file have 0 size in IGFS. Used IGFS size approximately equal to the > IGFS space size. > 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. > 10-15 Mb) > New file have 0 size. > 5) Remove all files of format IGFS > IGFS free space approximately equal to the size of first file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3400) IGFS: Does not correctly deallocate free space in courner case.
[ https://issues.apache.org/jira/browse/IGNITE-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-3400: -- Description: Steps to reproduce: 1) Run node with configured IGFS limited by max space (f.e. 104857600). 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb) 3) Copy to IGFS file with size more than free space size. Second file have 0 size in IGFS. Used IGFS size approximately equal to the IGFS space size. 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. 10-15 Mb) New file have 0 size. 5) Remove all files of format IGFS IGFS free space approximately equal to the size of first file. was: Steps to reproduce: 1) Run node with configured IGFS limited by max space (f.e. 104857600). 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb) 3) Copy to IGFS file with size more than free space size. - Second file have 0 size in IGFS. Used IGFS size approximately equal to the IGFS space size. 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. 10-15 Mb) - New file have 0 size. 5) Remove all files of format IGFS - IGFS free space approximately equal to the size of first file. > IGFS: Does not correctly deallocate free space in courner case. > --- > > Key: IGNITE-3400 > URL: https://issues.apache.org/jira/browse/IGNITE-3400 > Project: Ignite > Issue Type: Bug > Components: IGFS >Affects Versions: 1.7 >Reporter: Vasiliy Sisko > Fix For: 1.7 > > > Steps to reproduce: > 1) Run node with configured IGFS limited by max space (f.e. 104857600). > 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb) > 3) Copy to IGFS file with size more than free space size. > Second file have 0 size in IGFS. Used IGFS size approximately equal to the > IGFS space size. > 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. > 10-15 Mb) > New file have 0 size. > 5) Remove all files of format IGFS > IGFS free space approximately equal to the size of first file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3401) "Remote node ID is not as expected" errors at driver during load test
Ksenia Rybakova created IGNITE-3401:
---
Summary: "Remote node ID is not as expected" errors at driver
during load test
Key: IGNITE-3401
URL: https://issues.apache.org/jira/browse/IGNITE-3401
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Ksenia Rybakova
Fix For: 1.7
A lot of errors at some drivers after several minutes after grid is up during
load test:
{noformat}
[14:33:42] (err) Failed to execute compound future reducer: Compound future
listener []class org.apache.ignite.IgniteCheckedException: Failed to send
message (node may have left the grid or TCP connection cannot be established
due to fir
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1193)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.submit(DataStreamerImpl.java:1378)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.update(DataStreamerImpl.java:1173)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.load0(DataStreamerImpl.java:756)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addDataInternal(DataStreamerImpl.java:568)
at
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:604)
at
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark$1.run(IgniteCacheRandomOperationBenchmark.java:383)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send
message to remote node: TcpDiscoveryNode
[id=11da20f5-87c5-4321-8163-ffef85f2d54c, addrs=[10.20.0.215, 127.0.0.1],
sockAddrs=[/127.0.0.1:47503, fosters-215/10.20.0
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1986)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1926)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1124)
... 7 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect to
node (is node still alive?). Make sure that each GridComputeTask and
GridCacheTransaction has a timeout set in order to prevent parties from waiting
forever
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2489)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2130)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2024)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1960)
... 9 more
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
connect to address: fosters-215/10.20.0.215:47103
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
... 12 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
read remote node recovery handshake (connection closed).
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2699)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
... 12 more
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
connect to address: /127.0.0.1:47103
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2494)
... 12 more
Caused by: class org.apache.ignite.IgniteCheckedException: Remote node
ID is not as expected [expected=11da20f5-87c5-4321-8163-ffef85f2d54c,
rcvd=03bc7d54-4fec-481d-af24-6f5408b32fe2]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2604)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2361)
... 12 more
{noformat}
Tested version: 1.5.27
Load config:
- 7 hosts with 4 servers and 3 drivers each (28 servers and 21 drivers in total)
- benchmark: IgniteCacheRandomOperationBenchmark
- preload: 2M
- key range: 4M
- warmup: 30s
- duration: 10h
- operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
PUT_IF_ABSENT REPLACE
-backup count: 1
- GC: G1
- heap size: 8Gb for servers, 4Gb for drivers
- caches:
{noformat}
[jira] [Created] (IGNITE-3400) IGFS: Does not correctly deallocate free space in courner case.
Vasiliy Sisko created IGNITE-3400: - Summary: IGFS: Does not correctly deallocate free space in courner case. Key: IGNITE-3400 URL: https://issues.apache.org/jira/browse/IGNITE-3400 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.7 Reporter: Vasiliy Sisko Steps to reproduce: 1) Run node with configured IGFS limited by max space (f.e. 104857600). 2) Copy to IGFS file with size less than IGFS space size. (f.e. 10-15 Mb) 3) Copy to IGFS file with size more than free space size. - Second file have 0 size in IGFS. Used IGFS size approximately equal to the IGFS space size. 4) Copy to IGFS file with size less than expected IGFS free space size. (f.e. 10-15 Mb) - New file have 0 size. 5) Remove all files of format IGFS - IGFS free space approximately equal to the size of first file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName
[ https://issues.apache.org/jira/browse/IGNITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356748#comment-15356748 ] Biao Ma commented on IGNITE-3207: - Yes, I think I've rename most of the "gridName" to "instanceName", Now I am running "mvn clean package -DskipTests" . If there is nothing wrong, I'd format the patch and push a PR. > Rename IgniteConfiguration.gridName > --- > > Key: IGNITE-3207 > URL: https://issues.apache.org/jira/browse/IGNITE-3207 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Biao Ma > Fix For: 1.7 > > > We have got a TON of questions on gridName property. Everyone thinks that > clusters are formed based on the gridName, that is, nodes with the same grid > name will join one cluster, and nodes with a different name will be in a > separate cluster. > Let's do the following: > * Deprecate IgniteConfiguration.gridName > * Add IgniteConfiguration.localInstanceName > * Rename related parameters in Ignition class (and other places, if present) > * Update Javadoc: clearly state that this name only works locally and has no > effect on topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3160) WebSession: Incorrect session ID change logic.
[ https://issues.apache.org/jira/browse/IGNITE-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3160. --- > WebSession: Incorrect session ID change logic. > -- > > Key: IGNITE-3160 > URL: https://issues.apache.org/jira/browse/IGNITE-3160 > Project: Ignite > Issue Type: Bug > Components: websession >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.7 > > > When user change session ID, we call invalidate() method on our session after > leaving the filter. > This call will invalidate genuine session as well, which is wrong. Looks like > our session ID change is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3161) WebSession: Session must be created on demand, not always.
[
https://issues.apache.org/jira/browse/IGNITE-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356686#comment-15356686
]
Vladimir Ozerov commented on IGNITE-3161:
-
This ticket also fixes IGNITE-3160:
"When user change session ID, we call invalidate() method on our session after
leaving the filter.
This call will invalidate genuine session as well, which is wrong. Looks like
our session ID change is broken."
> WebSession: Session must be created on demand, not always.
> --
>
> Key: IGNITE-3161
> URL: https://issues.apache.org/jira/browse/IGNITE-3161
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.7
>
>
> Our filter will always creates new session (both in Ignite and in container).
> This is wrong, as session must be created only when it is really requested
> through {{HttpRequest.getSession(true)}} call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2693) withKeepBinary and non-binary marshallers
[
https://issues.apache.org/jira/browse/IGNITE-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356628#comment-15356628
]
Denis Magda commented on IGNITE-2693:
-
[~vozerov], did you have a chance to check the TC? When do you expected the
changes to be merged?
> withKeepBinary and non-binary marshallers
> -
>
> Key: IGNITE-2693
> URL: https://issues.apache.org/jira/browse/IGNITE-2693
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Sergey Kozlov
>Assignee: Oddo
> Labels: newbie
> Fix For: 1.7
>
>
> Currently the user is able to set {{.withKeepBinary()}} for any used
> marshaller. But it obviously causes ClassCastException for non-binary
> marshallers and should be available only for binary marshaller.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3207) Rename IgniteConfiguration.gridName
[ https://issues.apache.org/jira/browse/IGNITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356626#comment-15356626 ] Denis Magda commented on IGNITE-3207: - [~F7753], do you have any progress on this? Do you need any assistance from our side? > Rename IgniteConfiguration.gridName > --- > > Key: IGNITE-3207 > URL: https://issues.apache.org/jira/browse/IGNITE-3207 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Assignee: Biao Ma > Fix For: 1.7 > > > We have got a TON of questions on gridName property. Everyone thinks that > clusters are formed based on the gridName, that is, nodes with the same grid > name will join one cluster, and nodes with a different name will be in a > separate cluster. > Let's do the following: > * Deprecate IgniteConfiguration.gridName > * Add IgniteConfiguration.localInstanceName > * Rename related parameters in Ignition class (and other places, if present) > * Update Javadoc: clearly state that this name only works locally and has no > effect on topology. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
