[jira] [Comment Edited] (IGNITE-3519) Web console: add ability to specify a node filter in cache configuration
[
https://issues.apache.org/jira/browse/IGNITE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420614#comment-15420614
]
Pavel Konstantinov edited comment on IGNITE-3519 at 8/15/16 4:43 AM:
-
1) create a new cluster
2) open Node Filter section
3) choose 'Igfs nodes' option - Save become available
4) click Save - there is no error message about empty IGFS drop down field
Another case:
1) Save become available on dropping down Node filter filed before user made
any changes in the list. The same for IGFS field too.
Another case:
1) The field Node IDs with invalid value is deleted by clicking on triangle
icon.
was (Author: pkonstantinov):
1) create a new cluster
2) open Node Filter section
3) choose 'Igfs nodes' option - Save become available
4) click Save - there is no error message about empty IGFS drop down field
Another case:
1) Save become available on dropping down Node filter filed before user made
any changes in the list. The same for IGFS field too.
> Web console: add ability to specify a node filter in cache configuration
>
>
> Key: IGNITE-3519
> URL: https://issues.apache.org/jira/browse/IGNITE-3519
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
> Fix For: 1.8
>
>
> For example:
> {code}
>
> class="org.gridgain.visor.tester.cache.VisorCacheNodeAttrFilter">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3519) Web console: add ability to specify a node filter in cache configuration
[
https://issues.apache.org/jira/browse/IGNITE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420614#comment-15420614
]
Pavel Konstantinov edited comment on IGNITE-3519 at 8/15/16 4:37 AM:
-
1) create a new cluster
2) open Node Filter section
3) choose 'Igfs nodes' option - Save become available
4) click Save - there is no error message about empty IGFS drop down field
Another case:
1) Save become available on dropping down Node filter filed before user made
any changes in the list. The same for IGFS field too.
was (Author: pkonstantinov):
1) create a new cluster
2) open Node Filter section
3) choose 'Igfs nodes' option - Save become available
4) click Save - there is no error message about empty IGFS drop down field
Another case:
1) Save become available on dropping down Node filter filed before user made
any changes in the list
> Web console: add ability to specify a node filter in cache configuration
>
>
> Key: IGNITE-3519
> URL: https://issues.apache.org/jira/browse/IGNITE-3519
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
> Fix For: 1.8
>
>
> For example:
> {code}
>
> class="org.gridgain.visor.tester.cache.VisorCacheNodeAttrFilter">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3519) Web console: add ability to specify a node filter in cache configuration
[
https://issues.apache.org/jira/browse/IGNITE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420614#comment-15420614
]
Pavel Konstantinov edited comment on IGNITE-3519 at 8/15/16 4:36 AM:
-
1) create a new cluster
2) open Node Filter section
3) choose 'Igfs nodes' option - Save become available
4) click Save - there is no error message about empty IGFS drop down field
Another case:
1) Save become available on dropping down Node filter filed before user made
any changes in the list
was (Author: pkonstantinov):
1) create a new cluster
2) open Node Filter section
3) choose 'Igfs nodes' option - Save become available
4) click Save - there is no error message about empty IGFS drop down field
> Web console: add ability to specify a node filter in cache configuration
>
>
> Key: IGNITE-3519
> URL: https://issues.apache.org/jira/browse/IGNITE-3519
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
> Fix For: 1.8
>
>
> For example:
> {code}
>
> class="org.gridgain.visor.tester.cache.VisorCacheNodeAttrFilter">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (IGNITE-3519) Web console: add ability to specify a node filter in cache configuration
[
https://issues.apache.org/jira/browse/IGNITE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov reopened IGNITE-3519:
Assignee: Andrey Novikov (was: Pavel Konstantinov)
1) create a new cluster
2) open Node Filter section
3) choose 'Igfs nodes' option - Save become available
4) click Save - there is no error message about empty IGFS drop down field
> Web console: add ability to specify a node filter in cache configuration
>
>
> Key: IGNITE-3519
> URL: https://issues.apache.org/jira/browse/IGNITE-3519
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
> Fix For: 1.8
>
>
> For example:
> {code}
>
> class="org.gridgain.visor.tester.cache.VisorCacheNodeAttrFilter">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (IGNITE-2268) Implement CacheKeyConfiguration on cluster page
[ https://issues.apache.org/jira/browse/IGNITE-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-2268: Assignee: Andrey Novikov (was: Pavel Konstantinov) It is allowable to Save cluster with incorrect CacheKeyConfiguration: 1) input incorrect values into CacheKeyConfiguration's fields 2) Click Save on cluster level > Implement CacheKeyConfiguration on cluster page > --- > > Key: IGNITE-2268 > URL: https://issues.apache.org/jira/browse/IGNITE-2268 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 1.6 >Reporter: Vasiliy Sisko >Assignee: Andrey Novikov > Fix For: 1.8 > > > Extend binary configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (IGNITE-3250) Web console: incorrect Undo behavior in corner case
[ https://issues.apache.org/jira/browse/IGNITE-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-3250: Assignee: Dmitriyff (was: Pavel Konstantinov) Still works incorrect in this case: 1) add cluster 2) add Binary Configuration > Type Configuration 3) Save 4) delete Type Configuration 5) Check\Uncheck Compact footer Observing: 6) Click Undo in the Binary section - deleted Type Configuration doesn't restore 7) Undo on top level has different state compare to Undo in section > Web console: incorrect Undo behavior in corner case > --- > > Key: IGNITE-3250 > URL: https://issues.apache.org/jira/browse/IGNITE-3250 > Project: Ignite > Issue Type: Bug > Components: UI >Reporter: Pavel Konstantinov >Assignee: Dmitriyff >Priority: Minor > > # open any section with checkboxes > # enable any checkbox - Undo buttons in the section and on the top level are > become enabled > # disable the same checkbox - Undo still enabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (IGNITE-3219) Not work validation of nester forms on save.
[ https://issues.apache.org/jira/browse/IGNITE-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-3219: Assignee: Dmitriyff (was: Pavel Konstantinov) Initial issue is fixed but I've faced with another one related to Binary Configuration - Save button is unavailable after I've deleted Type Configuration. > Not work validation of nester forms on save. > > > Key: IGNITE-3219 > URL: https://issues.apache.org/jira/browse/IGNITE-3219 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Affects Versions: 1.7 >Reporter: Vasiliy Sisko >Assignee: Dmitriyff >Priority: Minor > Fix For: 1.8 > > > # On cluster page add type in binary configuration. > # Input valid type name. > # Input invalid id mapper, name mapper, serializer > # Save cluster. > Cluster saved successfully, fields marked as wrong and validation do not show > them. > Also problem reproduced for Failover configuration -> Custom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420437#comment-15420437
]
Amir Akhmedov edited comment on IGNITE-640 at 8/14/16 6:46 PM:
---
I'm proposing IgniteMultimap interface to be as Guava has: IgniteMultimap is a
base interface and also there will be 3 derived interfaces: IgniteListMultimap,
IgniteSetMultimap, IgniteSortedSetMultimap. All 3 subinterfaces will have
Atomic and Transactional implementations.
Please review it, any comments and concerns will be highly appreciated.
{code:title=IgniteMultimap.java|borderStyle=solid}
public interface IgniteMultimap extends Closeable {
/**
* Returns collection of values to which the specified key is mapped,
* or empty collection if this multimap contains no mapping for the key.
*
* @param key the key whose associated values are to be returned
* @return the list of values to which the specified key is mapped,
* or empty collection if this multimap contains no mapping for the key.
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public Collection get(K key);
/**
* Returns the list of values for a collection of keys to which the keys
are mapped.
* Empty collection will be added to resulting list if this multimap
contains no mapping for the key.
* @param keys collection of keys
* @return the list of values for a collection of keys to which the keys
are mapped.
* Empty collection will be added to resulting list if this multimap
contains no mapping for the key.
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public Map getAll(Collection keys);
/**
* Clears the multimap. Removes all key-value pairs.
*/
public void clear();
/**
* Returns {@code true} if this multimap contains a mapping for the
specified key.
*
* @param key key whose presence in this multimap is to be tested
* @return {@code true} if this multimap contains a mapping for the
specified key
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public boolean containsKey(K key);
/**
* Returns {@code true} if this multimap contains at least one key-value
pair
* with the value {@code value}.
*
* @param value value whose presence in this multimap is to be tested
* @return {@code true} if this multimap contains at least one key-value
pair
* with the value {@code value}.
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public boolean containsValue(V value);
/**
* Returns whether the multimap contains the given key-value pair.
*
* @param key key whose presence in this multimap is to be tested
* @param value value whose presence in this multimap is to be tested
*
* @return {@code true} if the multimap contains the key-value pair, {@code
false} otherwise
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public boolean containsEntry(K key, V value);
/**
* Returns a {@link Collection} view of the mappings contained in this
multimap.
*
* @return a {@link Collection} view of the mappings contained in this
multimap.
*/
public Collection> entries();
/**
* Returns the locally owned set of keys.
*
* @return the locally owned set of keys.
*/
public Set localKeySet();
/**
* Returns a {@link Set} view of the keys contained in this multimap.
*
* @return a {@link Set} view of the keys contained in this multimap.
*/
public Set keySet();
/**
* Associates the specified value with the specified key in this multimap
*
* @param key key with which the specified value is to be associated
* @param value value to be associated with the specified key
* @return {@code true} if the method increased the size of the multimap, or
* {@code false} if the multimap already contained the key-value pair and
* doesn't allow duplicates
* @throws ClassCastException if the class of the specified key or value
* prevents it from being stored in this multimap
*/
public boolean put(K key, V value);
/**
* Stores a key-value pair in this multimap for each of {@code values}, all
* using the same key, {@code key}. Equivalent to (but expected to be more
* efficient than):{@code
*
* for (V value : values) {
* put(key, value);
* }}
*
* In particular, this is a no-op if {@code values} is empty.
*
* @return {@code true} if the multimap changed
* @throws ClassCastException if the class of the specified key or
[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420437#comment-15420437
]
Amir Akhmedov commented on IGNITE-640:
--
I'm proposing IgniteMultimap interface to be as Guava has: IgniteMultimap is a
base interface and also there will be 3 derived interfaces: IgniteListMultimap,
IgniteSetMultimap, IgniteSortedSetMultimap. All 3 subinterfaces will have
Atomic and Transactional implementations.
Please review it, any comments and concerns will be highly appreciated.
{code:title=IgniteMultimap.java|borderStyle=solid}
public interface IgniteMultimap extends Closeable {
/**
* Returns collection of values to which the specified key is mapped,
* or empty collection if this multimap contains no mapping for the key.
*
* @param key the key whose associated values are to be returned
* @return the list of values to which the specified key is mapped,
* or empty collection if this multimap contains no mapping for the key.
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public Collection get(K key);
/**
* Returns the list of values for a collection of keys to which the keys
are mapped.
* Empty collection will be added to resulting list if this multimap
contains no mapping for the key.
* @param keys collection of keys
* @return the list of values for a collection of keys to which the keys
are mapped.
* Empty collection will be added to resulting list if this multimap
contains no mapping for the key.
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public Map getAll(Collection keys);
/**
* Clears the multimap. Removes all key-value pairs.
*/
public void clear();
/**
* Returns {@code true} if this multimap contains a mapping for the
specified key.
*
* @param key key whose presence in this multimap is to be tested
* @return {@code true} if this multimap contains a mapping for the
specified key
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public boolean containsKey(K key);
/**
* Returns {@code true} if this multimap contains at least one key-value
pair
* with the value {@code value}.
*
* @param value value whose presence in this multimap is to be tested
* @return {@code true} if this multimap contains at least one key-value
pair
* with the value {@code value}.
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public boolean containsValue(V value);
/**
* Returns whether the multimap contains the given key-value pair.
*
* @param key key whose presence in this multimap is to be tested
* @param value value whose presence in this multimap is to be tested
*
* @return {@code true} if the multimap contains the key-value pair, {@code
false} otherwise
* @throws ClassCastException if the key is of an inappropriate type for
this multimap
*/
public boolean containsEntry(K key, V value);
/**
* Returns a {@link Collection} view of the mappings contained in this
multimap.
*
* @return a {@link Collection} view of the mappings contained in this
multimap.
*/
public Collection> entries();
/**
* Returns the locally owned set of keys.
*
* @return the locally owned set of keys.
*/
public Set localKeySet();
/**
* Returns a {@link Set} view of the keys contained in this multimap.
*
* @return a {@link Set} view of the keys contained in this multimap.
*/
public Set keySet();
/**
* Associates the specified value with the specified key in this multimap
*
* @param key key with which the specified value is to be associated
* @param value value to be associated with the specified key
* @return {@code true} if the method increased the size of the multimap, or
* {@code false} if the multimap already contained the key-value pair and
* doesn't allow duplicates
* @throws ClassCastException if the class of the specified key or value
* prevents it from being stored in this multimap
*/
public boolean put(K key, V value);
/**
* Stores a key-value pair in this multimap for each of {@code values}, all
* using the same key, {@code key}. Equivalent to (but expected to be more
* efficient than):{@code
*
* for (V value : values) {
* put(key, value);
* }}
*
* In particular, this is a no-op if {@code values} is empty.
*
* @return {@code true} if the multimap changed
* @throws ClassCastException if the class of the specified key or value
* prevents it from being stored in
[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420426#comment-15420426
]
Amir Akhmedov commented on IGNITE-640:
--
Discussion thread:
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-640-IgniteMultimap-interface-draft-version-td10659.html
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of
> keys, and maximum number of values for a key. The maximum number of keys
> should be controlled by Ignite standard eviction policy. The maximum number
> of values for a key should be controlled by the implementation of the
> multi-map. Either eviction parameter should be configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amir Akhmedov reassigned IGNITE-640:
Assignee: Amir Akhmedov
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of
> keys, and maximum number of values for a key. The maximum number of keys
> should be controlled by Ignite standard eviction policy. The maximum number
> of values for a key should be controlled by the implementation of the
> multi-map. Either eviction parameter should be configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3407) HTTP REST: query commands without pageSize failed with NPE
[
https://issues.apache.org/jira/browse/IGNITE-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420374#comment-15420374
]
Andrey Gura edited comment on IGNITE-3407 at 8/14/16 3:50 PM:
--
Saikat, change looks good. But I think that additional exception handling is
redundant because each {{callLocalSafe()}} call returns future with exception
if query failed. Just return instance of {{GridFinishFuture}} with exception in
case of {{pageSize}} is {{null}} and delegate exception handling to upper level
(remove additional exception handling):
{code}
if (pageSize == null)
return new GridFinishedFuture<>(
new
IgniteCheckedException(GridRestCommandHandlerAdapter.missingParameter("pageSize"))
);
{code}
was (Author: agura):
Saikat, change looks good. But I think that additional exception handling is
redundant because each {{callLocalSafe()}} call returns future with exception
if query failed. Just return instance of {{GridFinishFuture}} with exception in
case of {{pageSize}} is {{null}} and delegate exception handling to upper level
(remove additional exception handling):
{{code}}
if (pageSize == null)
return new GridFinishedFuture<>(
new
IgniteCheckedException(GridRestCommandHandlerAdapter.missingParameter("pageSize"))
);
{{code}}
> 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
>Assignee: Saikat Maitra
> Fix For: 1.8
>
>
> 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] [Commented] (IGNITE-3407) HTTP REST: query commands without pageSize failed with NPE
[
https://issues.apache.org/jira/browse/IGNITE-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420374#comment-15420374
]
Andrey Gura commented on IGNITE-3407:
-
Saikat, change looks good. But I think that additional exception handling is
redundant because each {{callLocalSafe()}} call returns future with exception
if query failed. Just return instance of {{GridFinishFuture}} with exception in
case of {{pageSize}} is {{null}} and delegate exception handling to upper level
(remove additional exception handling):
{{code}}
if (pageSize == null)
return new GridFinishedFuture<>(
new
IgniteCheckedException(GridRestCommandHandlerAdapter.missingParameter("pageSize"))
);
{{code}}
> 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
>Assignee: Saikat Maitra
> Fix For: 1.8
>
>
> 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] [Created] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.
Vladimir Ozerov created IGNITE-3682:
---
Summary: GridFunc: move all inner anonymous classes to separate
top-level classes.
Key: IGNITE-3682
URL: https://issues.apache.org/jira/browse/IGNITE-3682
Project: Ignite
Issue Type: Task
Components: general
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Priority: Critical
Fix For: 2.0
Otherwise almost any change to class {{GridFunc}} will lead to serialization
issues because we have no control over inner class names.
E.g. if removed single anonymous class, another anonymous class might change
it's name from {{GridFunc$4}} to {{GridFunc$3}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3681) Binary: special handling for TreeMap and TreeSet.
[ https://issues.apache.org/jira/browse/IGNITE-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3681. --- > Binary: special handling for TreeMap and TreeSet. > - > > Key: IGNITE-3681 > URL: https://issues.apache.org/jira/browse/IGNITE-3681 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2852) Support of Comparable interface for BinaryObject
[
https://issues.apache.org/jira/browse/IGNITE-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-2852.
-
Resolution: Fixed
Fixed by adding special wrappers for these types.
> Support of Comparable interface for BinaryObject
>
>
> Key: IGNITE-2852
> URL: https://issues.apache.org/jira/browse/IGNITE-2852
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> When trying to convert {{TreeMap}} into binary object using {{toBinary}}
> method, the following exception fails:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
> java.lang.Comparable
> at java.util.TreeMap.compare(TreeMap.java:1188)
> at java.util.TreeMap.put(TreeMap.java:531)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:495)
> at
> org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.toBinary(IgniteBinaryImpl.java:67)
> at TreeMapTest.main(TreeMapTest.java:15)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {noformat}
> This happens because maps are not wrapped into binary objects, therefore we
> create another {{TreeMap}} and put {{BinaryObject}} instances, which are not
> {{Comparable}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2852) Support of Comparable interface for BinaryObject
[
https://issues.apache.org/jira/browse/IGNITE-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2852.
---
> Support of Comparable interface for BinaryObject
>
>
> Key: IGNITE-2852
> URL: https://issues.apache.org/jira/browse/IGNITE-2852
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> When trying to convert {{TreeMap}} into binary object using {{toBinary}}
> method, the following exception fails:
> {noformat}
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
> java.lang.Comparable
> at java.util.TreeMap.compare(TreeMap.java:1188)
> at java.util.TreeMap.put(TreeMap.java:531)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:495)
> at
> org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.toBinary(IgniteBinaryImpl.java:67)
> at TreeMapTest.main(TreeMapTest.java:15)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {noformat}
> This happens because maps are not wrapped into binary objects, therefore we
> create another {{TreeMap}} and put {{BinaryObject}} instances, which are not
> {{Comparable}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2968) Near cache support in transactions deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15417698#comment-15417698 ] Andrey Gura edited comment on IGNITE-2968 at 8/14/16 3:10 PM: -- || || LinkedHashMap with sync addEntry() method || ConcurrentLinkedHashMap || delta || | tx-optimistic-getAllPutAll| 7,427.68 | 7,298.35 | 1.74% | | tx-optimistic-getEntriesPutAll | 7,342.14 | 7,355.78 | -0.19% | | tx-optimistic-put | 65,972.43 | 65,640.25 | 0.50% | | tx-optimistic-put-offheap | 62,924.71 | 62,511.65 | 0.66% | | tx-optimistic-put-offheap-val | 66,470.79 | 65,867.27 | 0.91% | | tx-optim-repRead-put-get | 42,724.33 | 41,877.81 | 1.98% | | tx-optim-repRead-put-getEntry | 42,447.68 | 42,470.36 | -0.05% | | tx-opt-serializable-getAllPutAll | 11,764.93 | 11,370.30 | 3.35% | | tx-opt-serializable-getEntriesPutAll | 11,783.39 | 11,563.64 | 1.86% | | tx-opt-serial-put-get | 31,768.87 | 30,232.00 | 4.84% | | tx-opt-serial-put-getEntry | 31,633.73 | 30,048.69 | 5.01% | | tx-pessimistic-getAllPutAll | 7,962.77 | 7,973.28 | -0.13% | | tx-pessimistic-getEntriesPutAll | 8,034.16 | 7,816.37 | 2.71% | | tx-pessim-repRead-put-get | 22,445.55 | 21,458.48 | 4.40% | | tx-pessim-repRead-put-getEntry | 22,070.84 | 21,641.62 | 1.94% | | tx-putAll | 1,285.69 | 1,260.84 | 1.93% | | tx-putAllSerializable | 4,776.64 | 4,750.38 | 0.55% | Solution mentioned in previous comment shows good results. Please review commit https://github.com/apache/ignite/pull/943/commits/63e13c5fb4750ae8bf0fdb1f6ac64b1165332eed was (Author: agura): Solution mentioned in previous comment shows good results. Please review. > Near cache support in transactions deadlock detection > - > > Key: IGNITE-2968 > URL: https://issues.apache.org/jira/browse/IGNITE-2968 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Gura >Assignee: Andrey Gura > Fix For: 1.8 > > > Deadlock detection doesn't support transactions on near cache. Need implement > it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3197) OverlappingFileLockException in marshaller context
[
https://issues.apache.org/jira/browse/IGNITE-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420357#comment-15420357
]
Andrey Gura commented on IGNITE-3197:
-
Val, Andrey,
I don't think that ignoring of this exception is good idea. Different
classloader lead to different instances of {{GridStripedLock}}. Whether we can
somehow avoid this (e.g. common classloader)?
> OverlappingFileLockException in marshaller context
> --
>
> Key: IGNITE-3197
> URL: https://issues.apache.org/jira/browse/IGNITE-3197
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Andrey Velichko
>Priority: Minor
> Labels: important
> Fix For: 1.8
>
>
> {{MarshallerContextImpl}} uses static locks to avoid writing to the same file
> concurrently. But if Ignite is running embedded in managed environment (e.g.,
> application server), it's possible that there will be two clients loaded by
> different class loaders. In this case they will not share these static locks
> and therefore they can try to acquire the file lock for the same file,
> causing the {{OverlappingFileLockException}}:
> {noformat}
> [#|2016-05-17T08:02:21.950+0100|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=291;_ThreadName=Thread-2;|java.nio.channels.OverlappingFileLockException
> at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1011)
> at
> org.apache.ignite.internal.MarshallerContextImpl$ContinuousQueryListener.onUpdated(MarshallerContextImpl.java:239)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:655)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:967)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1900(GridContinuousProcessor.java:94)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:612)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1058)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:104)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1018)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:104)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:987)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> |#]
> {noformat}
> It's actually harmless, but the logs are flooded with the errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3407) HTTP REST: query commands without pageSize failed with NPE
[ https://issues.apache.org/jira/browse/IGNITE-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15420252#comment-15420252 ] Saikat Maitra commented on IGNITE-3407: --- [~agura] Hi Andrey, I have updated the PR based on review comments. Please review and let me know your feedback. Regards Saikat > 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 >Assignee: Saikat Maitra > Fix For: 1.8 > > > 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)
