[jira] [Commented] (IGNITE-5416) KafkaStreamer: add a helper function for single tuple streaming
[ https://issues.apache.org/jira/browse/IGNITE-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16449360#comment-16449360 ] Michael Griggs commented on IGNITE-5416: [~dpavlov] [~agura] I'll take a look and fix > KafkaStreamer: add a helper function for single tuple streaming > --- > > Key: IGNITE-5416 > URL: https://issues.apache.org/jira/browse/IGNITE-5416 > Project: Ignite > Issue Type: Improvement > Components: streaming >Affects Versions: 2.0 >Reporter: Michael Griggs >Assignee: Michael Griggs >Priority: Minor > > Link to Ignite dev thread: > http://apache-ignite-developers.2346864.n4.nabble.com/Writing-a-helper-for-KafkaStreamer-tp18511.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268459#comment-16268459 ] Michael Griggs edited comment on IGNITE-6069 at 4/4/18 7:38 PM: It is essential that server nodes *not* need to be stopped in order to deploy a new service. This implies that we have peer-class loading for Service interfaces and implementations. was (Author: endian675): It is essential that server nodes must need to be stopped in order to deploy a new service. This implies that we have peer-class loading for Service interfaces and implementations. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Major > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426054#comment-16426054 ] Michael Griggs commented on IGNITE-6069: The use-case for multiple versions of service active at one time is as follows: # Central Team creates a service that provides functionality # Application Team 1 accesses that service to use functionality # Application Team 2 accesses that service to use functionality # Central team needs to modify the service to improve functionality # Application Team 1 updates its code to use improved functionality, but Application Team 2 does not have time do so. If multiple active Service versions are not available, the Central Team can only evolve the functionality at the pace of the slowest Application Team. Multiple active service versions removes that limitation. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh >Priority: Major > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381899#comment-16381899
]
Michael Griggs edited comment on IGNITE-1903 at 3/1/18 12:08 PM:
-
I have built a simple reproducer for this
[https://gitlab.com/michael.griggs/cachestorerepro]
was (Author: endian675):
I have built a simple reproducer for this
https://gitlab.com/michael.griggs/cachestorerepro
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: community, usability
> Fix For: 2.5
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381899#comment-16381899
]
Michael Griggs commented on IGNITE-1903:
I have built a simple reproducer for this
https://gitlab.com/michael.griggs/cachestorerepro
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: community, usability
> Fix For: 2.5
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268459#comment-16268459 ] Michael Griggs commented on IGNITE-6069: It is essential that server nodes must need to be stopped in order to deploy a new service. This implies that we have peer-class loading for Service interfaces and implementations. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16182665#comment-16182665 ] Michael Griggs commented on IGNITE-6069: >all service instances with the same name must have the same version I think this ticket is a good opportunity to have multiple versions of a service available in the cluster at the same time. By default requests would go to the latest version, but earlier versions could be requested by adding a parameter to the `serviceProxy()` method. The service version could be better indicated using an attribute on the service implementation, rather than using serialVersionUuid. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException
[
https://issues.apache.org/jira/browse/IGNITE-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs closed IGNITE-4878.
--
> IgniteH2Indexing can throw java.util.ConcurrentModificationException
>
>
> Key: IGNITE-4878
> URL: https://issues.apache.org/jira/browse/IGNITE-4878
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> From the Collections#synchronizedCollection method:
> {noformat}
> * It is imperative that the user manually synchronize on the returned
> * collection when traversing it via {@link Iterator}, {@link Spliterator}
> * or {@link Stream}:
> *
> * Collection c = Collections.synchronizedCollection(myCollection);
> * ...
> * synchronized (c) {
> * Iterator i = c.iterator(); // Must be in the synchronized block
> * while (i.hasNext())
> * foo(i.next());
> * }
> *
> * Failure to follow this advice may result in non-deterministic behavior.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException
[
https://issues.apache.org/jira/browse/IGNITE-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs resolved IGNITE-4878.
Resolution: Duplicate
> IgniteH2Indexing can throw java.util.ConcurrentModificationException
>
>
> Key: IGNITE-4878
> URL: https://issues.apache.org/jira/browse/IGNITE-4878
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> From the Collections#synchronizedCollection method:
> {noformat}
> * It is imperative that the user manually synchronize on the returned
> * collection when traversing it via {@link Iterator}, {@link Spliterator}
> * or {@link Stream}:
> *
> * Collection c = Collections.synchronizedCollection(myCollection);
> * ...
> * synchronized (c) {
> * Iterator i = c.iterator(); // Must be in the synchronized block
> * while (i.hasNext())
> * foo(i.next());
> * }
> *
> * Failure to follow this advice may result in non-deterministic behavior.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5783) LINQ queries should provide the ability to generate the SQL query plan
[
https://issues.apache.org/jira/browse/IGNITE-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-5783:
---
Affects Version/s: (was: 2.0)
2.1
> LINQ queries should provide the ability to generate the SQL query plan
> --
>
> Key: IGNITE-5783
> URL: https://issues.apache.org/jira/browse/IGNITE-5783
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Affects Versions: 2.1
>Reporter: Michael Griggs
>Priority: Minor
> Fix For: 2.2
>
>
> At present, the only way to see the query plan generated by a LINQ query in
> C# is to:
> # Call {{GetFieldsQuery()}}
> # Prepend the string {{"explain "}} to the resulting string
> # execute the query in the step above and retrieve the plan
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5785) C# QuerySqlField attribute should provide access to Order parameter
Michael Griggs created IGNITE-5785:
--
Summary: C# QuerySqlField attribute should provide access to Order
parameter
Key: IGNITE-5785
URL: https://issues.apache.org/jira/browse/IGNITE-5785
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 2.1
Reporter: Michael Griggs
Fix For: 2.2
https://apacheignite.readme.io/docs/indexes#section-group-indexes
{{order}} parameter should be accessible via Ignite.NET.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5783) LINQ queries should provide the ability to generate the SQL query plan
Michael Griggs created IGNITE-5783:
--
Summary: LINQ queries should provide the ability to generate the
SQL query plan
Key: IGNITE-5783
URL: https://issues.apache.org/jira/browse/IGNITE-5783
Project: Ignite
Issue Type: New Feature
Components: platforms
Affects Versions: 2.0
Reporter: Michael Griggs
Priority: Minor
Fix For: 2.2
At present, the only way to see the query plan generated by a LINQ query in C#
is to:
# Call {{GetFieldsQuery()}}
# Prepend the string {{"explain "}} to the resulting string
# execute the query in the step above and retrieve the plan
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[ https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074927#comment-16074927 ] Michael Griggs commented on IGNITE-5697: [~anovikov] mgriggs@ubuntu-16:~$ nodejs -v v6.11.0 > Web Console should be configurable for IPv4 connections > --- > > Key: IGNITE-5697 > URL: https://issues.apache.org/jira/browse/IGNITE-5697 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.0 >Reporter: Michael Griggs >Assignee: Michael Griggs > Fix For: 2.1 > > > When an IPv6 network interface is available, NodeJS will always prefer that > to an IPv4 interface. This causes problems if IPv6 is not fully operational > on the network. > This fix will add the ability to specify that IPv4 should be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-1774) REST API should be implemented using Jersey
[ https://issues.apache.org/jira/browse/IGNITE-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs reassigned IGNITE-1774: -- Assignee: (was: Michael Griggs) > REST API should be implemented using Jersey > --- > > Key: IGNITE-1774 > URL: https://issues.apache.org/jira/browse/IGNITE-1774 > Project: Ignite > Issue Type: Improvement >Affects Versions: ignite-1.4 >Reporter: Michael Griggs > > Jersey+Jetty is a well established method for implementing RESTful > interfaces. > The REST API should implement non-modifying cache methods (e.g., get()) via > HTTP GET methods, and modifying cache methods (e.g., put(), replace()) via > HTTP POST methods. This allows the JSON data to be correctly formatted in > the body of the message, instead of needing to be URL-encoded on the URI. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[
https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074366#comment-16074366
]
Michael Griggs edited comment on IGNITE-5697 at 7/5/17 7:44 AM:
There appears to be a bug in NodeJS such that when \[1\] is called, a Server
object is returned by when \[2\] is called a null value is returned.
Therefore a workaround will be necessary when passing the server object to the
"onListening" function.
\[1\]: {{server.listen(3000);}}
\[2\]: {{server.listen(3000,'0.0.0.0');}}
was (Author: michael.gri...@gridgain.com):
There appears to be a bug in NodeJS such that when \[1\] is called, a Server
object is returned by when \[2\] is called a null value is returned.
\[1\]: {{server.listen(3000);}}
\[2\]: {{server.listen(3000,'0.0.0.0');}}
> Web Console should be configurable for IPv4 connections
> ---
>
> Key: IGNITE-5697
> URL: https://issues.apache.org/jira/browse/IGNITE-5697
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 2.0
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 2.1
>
>
> When an IPv6 network interface is available, NodeJS will always prefer that
> to an IPv4 interface. This causes problems if IPv6 is not fully operational
> on the network.
> This fix will add the ability to specify that IPv4 should be used.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[
https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074366#comment-16074366
]
Michael Griggs commented on IGNITE-5697:
There appears to be a bug in NodeJS such that when \[1\] is called, a Server
object is returned by when \[2\] is called a null value is returned.
\[1\]: {{server.listen(3000);}}
\[2\]: {{server.listen(3000,'0.0.0.0');}}
> Web Console should be configurable for IPv4 connections
> ---
>
> Key: IGNITE-5697
> URL: https://issues.apache.org/jira/browse/IGNITE-5697
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 2.0
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 2.1
>
>
> When an IPv6 network interface is available, NodeJS will always prefer that
> to an IPv4 interface. This causes problems if IPv6 is not fully operational
> on the network.
> This fix will add the ability to specify that IPv4 should be used.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[ https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074358#comment-16074358 ] Michael Griggs commented on IGNITE-5697: For the implementation we can either 1. Make an IPv4/IPv6 flag in configuration. or 2. Allow the host parameter to be configured, so that the server can be bound to any specific IP address on the machine. > Web Console should be configurable for IPv4 connections > --- > > Key: IGNITE-5697 > URL: https://issues.apache.org/jira/browse/IGNITE-5697 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.0 >Reporter: Michael Griggs >Assignee: Michael Griggs > Fix For: 2.1 > > > When an IPv6 network interface is available, NodeJS will always prefer that > to an IPv4 interface. This causes problems if IPv6 is not fully operational > on the network. > This fix will add the ability to specify that IPv4 should be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5697) Web Console should be configurable for IPv4 connections
[ https://issues.apache.org/jira/browse/IGNITE-5697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs reassigned IGNITE-5697: -- Assignee: Michael Griggs > Web Console should be configurable for IPv4 connections > --- > > Key: IGNITE-5697 > URL: https://issues.apache.org/jira/browse/IGNITE-5697 > Project: Ignite > Issue Type: Bug > Components: UI >Affects Versions: 2.0 >Reporter: Michael Griggs >Assignee: Michael Griggs > Fix For: 2.1 > > > When an IPv6 network interface is available, NodeJS will always prefer that > to an IPv4 interface. This causes problems if IPv6 is not fully operational > on the network. > This fix will add the ability to specify that IPv4 should be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5697) Web Console should be configurable for IPv4 connections
Michael Griggs created IGNITE-5697: -- Summary: Web Console should be configurable for IPv4 connections Key: IGNITE-5697 URL: https://issues.apache.org/jira/browse/IGNITE-5697 Project: Ignite Issue Type: Bug Components: UI Affects Versions: 2.0 Reporter: Michael Griggs Fix For: 2.1 When an IPv6 network interface is available, NodeJS will always prefer that to an IPv4 interface. This causes problems if IPv6 is not fully operational on the network. This fix will add the ability to specify that IPv4 should be used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5416) KafkaStreamer: add a helper function for single tuple streaming
Michael Griggs created IGNITE-5416: -- Summary: KafkaStreamer: add a helper function for single tuple streaming Key: IGNITE-5416 URL: https://issues.apache.org/jira/browse/IGNITE-5416 Project: Ignite Issue Type: Improvement Components: streaming Affects Versions: 2.0 Reporter: Michael Griggs Assignee: Michael Griggs Priority: Minor Fix For: 2.1 Link to Ignite dev thread: http://apache-ignite-developers.2346864.n4.nabble.com/Writing-a-helper-for-KafkaStreamer-tp18511.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4828) Improve the distribution of keys within partitions
[
https://issues.apache.org/jira/browse/IGNITE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15961127#comment-15961127
]
Michael Griggs commented on IGNITE-4828:
[~yzhdanov], thank you for your helpful input. My answers are below:
1. Good point, I will look in to that. Can we guarantee that such an adapter
implementation would be early-bound, and not give us any runtime performance
impact?
2. Using an enum combined with a switch statement is the highest performing
implementation, as Java will (or should) emit a jump table in bytecode if it
sees a switch with constants. It will not do that for an if-else. Given that
the branch taken will likely be different for every cache, I don't know how
well the CPU branch-predictor will cope; if it cannot cope, then the CPU
pipeline will be flushed for every misprediction.
However, to be completely transparent, this is absolutely a micro-optimisation:
in my testing of a 3-branch if-else versus a 3 case switch, the difference was
of the order of nanoseconds per operation.
3. Can we mathematically guarantee that no key.hashCode(), when XOR with h>>>16
will return a negative value?
> Improve the distribution of keys within partitions
> --
>
> Key: IGNITE-4828
> URL: https://issues.apache.org/jira/browse/IGNITE-4828
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Labels: important
> Fix For: 2.0
>
>
> An issue has been found when inserting several million string keys in to a
> cache. Each string key was approximately 22-characters in length. When I
> exported the partition counts (via GG Visor) I was able to see an unusual
> periodicity in the number of keys allocated to partitions. I charted this in
> Excel (1).
> After further investigation, it appears that there is a relationship
> between the number of keys being inserted, the number of partitions
> assigned to the cache and amount of apparent periodicity: a small number of
> partitions will cause periodicity to appear with a lower number of keys.
> The {{RendezvousAffinityFunction#partition}} function performs a simple
> calculation of key hashcode modulo partition-count:
> {{U.safeAbs(key.hashCode() % parts)}}
> Digging further I was led to the fact that this is how the Java HashMap
> *used* to behave (2), but was upgraded around Java 1.4 to perform the
> following:
> {{key.hashCode() & (parts - 1)}}
> which performs more efficiently. It was then updated further to do the
> following:
> {{((h = key.hashCode()) ^ (h >>> 16) & (parts - 1));}}
> with the bit-shift performed to
> bq. incorporate impact of the highest bits that would otherwise never be used
> in index calculations because of table bounds
> When using this function, rather than our
> {{RendezvousAffinityFunction#partition}} implementation, I also saw a
> significant decrease in the periodicity and a better distribution of keys
> amongst partitions (3).
> (1): https://i.imgur.com/0FtCZ2A.png
> (2):
> https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
> (3): https://i.imgur.com/8ZuCSA3.png
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException
[
https://issues.apache.org/jira/browse/IGNITE-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950637#comment-15950637
]
Michael Griggs commented on IGNITE-4878:
https://github.com/apache/ignite/pull/1692
> IgniteH2Indexing can throw java.util.ConcurrentModificationException
>
>
> Key: IGNITE-4878
> URL: https://issues.apache.org/jira/browse/IGNITE-4878
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> From the Collections#synchronizedCollection method:
> {noformat}
> * It is imperative that the user manually synchronize on the returned
> * collection when traversing it via {@link Iterator}, {@link Spliterator}
> * or {@link Stream}:
> *
> * Collection c = Collections.synchronizedCollection(myCollection);
> * ...
> * synchronized (c) {
> * Iterator i = c.iterator(); // Must be in the synchronized block
> * while (i.hasNext())
> * foo(i.next());
> * }
> *
> * Failure to follow this advice may result in non-deterministic behavior.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Issue Comment Deleted] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException
[
https://issues.apache.org/jira/browse/IGNITE-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-4878:
---
Comment: was deleted
(was: https://github.com/apache/ignite/pull/1692)
> IgniteH2Indexing can throw java.util.ConcurrentModificationException
>
>
> Key: IGNITE-4878
> URL: https://issues.apache.org/jira/browse/IGNITE-4878
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> From the Collections#synchronizedCollection method:
> {noformat}
> * It is imperative that the user manually synchronize on the returned
> * collection when traversing it via {@link Iterator}, {@link Spliterator}
> * or {@link Stream}:
> *
> * Collection c = Collections.synchronizedCollection(myCollection);
> * ...
> * synchronized (c) {
> * Iterator i = c.iterator(); // Must be in the synchronized block
> * while (i.hasNext())
> * foo(i.next());
> * }
> *
> * Failure to follow this advice may result in non-deterministic behavior.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException
[
https://issues.apache.org/jira/browse/IGNITE-4878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948624#comment-15948624
]
Michael Griggs commented on IGNITE-4878:
https://github.com/apache/ignite/pull/1692
> IgniteH2Indexing can throw java.util.ConcurrentModificationException
>
>
> Key: IGNITE-4878
> URL: https://issues.apache.org/jira/browse/IGNITE-4878
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>
> From the Collections#synchronizedCollection method:
> {noformat}
> * It is imperative that the user manually synchronize on the returned
> * collection when traversing it via {@link Iterator}, {@link Spliterator}
> * or {@link Stream}:
> *
> * Collection c = Collections.synchronizedCollection(myCollection);
> * ...
> * synchronized (c) {
> * Iterator i = c.iterator(); // Must be in the synchronized block
> * while (i.hasNext())
> * foo(i.next());
> * }
> *
> * Failure to follow this advice may result in non-deterministic behavior.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-4878) IgniteH2Indexing can throw java.util.ConcurrentModificationException
Michael Griggs created IGNITE-4878:
--
Summary: IgniteH2Indexing can throw
java.util.ConcurrentModificationException
Key: IGNITE-4878
URL: https://issues.apache.org/jira/browse/IGNITE-4878
Project: Ignite
Issue Type: Bug
Affects Versions: 1.9
Reporter: Michael Griggs
Assignee: Michael Griggs
>From the Collections#synchronizedCollection method:
{noformat}
* It is imperative that the user manually synchronize on the returned
* collection when traversing it via {@link Iterator}, {@link Spliterator}
* or {@link Stream}:
*
* Collection c = Collections.synchronizedCollection(myCollection);
* ...
* synchronized (c) {
* Iterator i = c.iterator(); // Must be in the synchronized block
* while (i.hasNext())
* foo(i.next());
* }
*
* Failure to follow this advice may result in non-deterministic behavior.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-4828) Improve the distribution of keys within partitions
[
https://issues.apache.org/jira/browse/IGNITE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-4828:
---
Labels: important (was: )
> Improve the distribution of keys within partitions
> --
>
> Key: IGNITE-4828
> URL: https://issues.apache.org/jira/browse/IGNITE-4828
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Labels: important
> Fix For: 2.0
>
>
> An issue has been found when inserting several million string keys in to a
> cache. Each string key was approximately 22-characters in length. When I
> exported the partition counts (via GG Visor) I was able to see an unusual
> periodicity in the number of keys allocated to partitions. I charted this in
> Excel (1).
> After further investigation, it appears that there is a relationship
> between the number of keys being inserted, the number of partitions
> assigned to the cache and amount of apparent periodicity: a small number of
> partitions will cause periodicity to appear with a lower number of keys.
> The {{RendezvousAffinityFunction#partition}} function performs a simple
> calculation of key hashcode modulo partition-count:
> {{U.safeAbs(key.hashCode() % parts)}}
> Digging further I was led to the fact that this is how the Java HashMap
> *used* to behave (2), but was upgraded around Java 1.4 to perform the
> following:
> {{key.hashCode() & (parts - 1)}}
> which performs more efficiently. It was then updated further to do the
> following:
> {{((h = key.hashCode()) ^ (h >>> 16) & (parts - 1));}}
> with the bit-shift performed to
> bq. incorporate impact of the highest bits that would otherwise never be used
> in index calculations because of table bounds
> When using this function, rather than our
> {{RendezvousAffinityFunction#partition}} implementation, I also saw a
> significant decrease in the periodicity and a better distribution of keys
> amongst partitions (3).
> (1): https://i.imgur.com/0FtCZ2A.png
> (2):
> https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
> (3): https://i.imgur.com/8ZuCSA3.png
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4847) Upgrade log4j2 to version 2.8.1
[ https://issues.apache.org/jira/browse/IGNITE-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs reassigned IGNITE-4847: -- Assignee: Michael Griggs > Upgrade log4j2 to version 2.8.1 > --- > > Key: IGNITE-4847 > URL: https://issues.apache.org/jira/browse/IGNITE-4847 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.9 >Reporter: Michael Griggs >Assignee: Michael Griggs >Priority: Minor > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4847) Upgrade log4j2 to version 2.8.1
[ https://issues.apache.org/jira/browse/IGNITE-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs updated IGNITE-4847: --- Summary: Upgrade log4j2 to version 2.8.1 (was: Upgrade log4j2 to version 2.8) > Upgrade log4j2 to version 2.8.1 > --- > > Key: IGNITE-4847 > URL: https://issues.apache.org/jira/browse/IGNITE-4847 > Project: Ignite > Issue Type: Improvement >Affects Versions: 1.9 >Reporter: Michael Griggs >Priority: Minor > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-4828) Improve the distribution of keys within partitions
[
https://issues.apache.org/jira/browse/IGNITE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-4828:
---
Description:
An issue has been found when inserting several million string keys in to a
cache. Each string key was approximately 22-characters in length. When I
exported the partition counts (via GG Visor) I was able to see an unusual
periodicity in the number of keys allocated to partitions. I charted this in
Excel (1).
After further investigation, it appears that there is a relationship
between the number of keys being inserted, the number of partitions
assigned to the cache and amount of apparent periodicity: a small number of
partitions will cause periodicity to appear with a lower number of keys.
The {{RendezvousAffinityFunction#partition}} function performs a simple
calculation of key hashcode modulo partition-count:
{{U.safeAbs(key.hashCode() % parts)}}
Digging further I was led to the fact that this is how the Java HashMap
*used* to behave (2), but was upgraded around Java 1.4 to perform the
following:
{{key.hashCode() & (parts - 1)}}
which performs more efficiently. It was then updated further to do the
following:
{{((h = key.hashCode()) ^ (h >>> 16) & (parts - 1));}}
with the bit-shift performed to
bq. incorporate impact of the highest bits that would otherwise never be used
in index calculations because of table bounds
When using this function, rather than our
{{RendezvousAffinityFunction#partition}} implementation, I also saw a
significant decrease in the periodicity and a better distribution of keys
amongst partitions (3).
(1): https://i.imgur.com/0FtCZ2A.png
(2):
https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
(3): https://i.imgur.com/8ZuCSA3.png
was:
An issue has been found when inserting several million string keys in to a
cache. Each string key was approximately 22-characters in length. When I
exported the partition counts (via GG Visor) I was able to see an unusual
periodicity in the number of keys allocated to partitions. I charted this in
Excel (1).
After further investigation, it appears that there is a relationship
between the number of keys being inserted, the number of partitions
assigned to the cache and amount of apparent periodicity: a small number
ofpartitions will cause periodicity to appear with a lower number of keys.
The {{RendezvousAffinityFunction#partition}} function performs a simple
calculation of key hashcode modulo partition-count:
{{U.safeAbs(key.hashCode() % parts)}}
Digging further I was led to the fact that this is how the Java HashMap
*used* to behave (2), but was upgraded around Java 1.4 to perform the
following:
{{key.hashCode() & (parts - 1)}}
which performs more efficiently. It was then updated further to do the
following:
{{(h = key.hashCode()) ^ (h >>> 16);}}
with the bit-shift performed to
bq. incorporate impact of the highest bits that would otherwise never be used
in index calculations because of table bounds
When using this function, rather than our
{{RendezvousAffinityFunction#partition}} implementation, I also saw a
significant decrease in the periodicity and a better distribution of keys
amongst partitions (3).
(1): https://i.imgur.com/0FtCZ2A.png
(2):
https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
(3): https://i.imgur.com/8ZuCSA3.png
> Improve the distribution of keys within partitions
> --
>
> Key: IGNITE-4828
> URL: https://issues.apache.org/jira/browse/IGNITE-4828
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 2.0
>
>
> An issue has been found when inserting several million string keys in to a
> cache. Each string key was approximately 22-characters in length. When I
> exported the partition counts (via GG Visor) I was able to see an unusual
> periodicity in the number of keys allocated to partitions. I charted this in
> Excel (1).
> After further investigation, it appears that there is a relationship
> between the number of keys being inserted, the number of partitions
> assigned to the cache and amount of apparent periodicity: a small number of
> partitions will cause periodicity to appear with a lower number of keys.
> The {{RendezvousAffinityFunction#partition}} function performs a simple
> calculation of key hashcode modulo partition-count:
> {{U.safeAbs(key.hashCode() % parts)}}
> Digging further I was led to the fact that this is how the Java HashMap
> *used* to behave (2), but was upgraded around Java 1.4 to perform the
> following:
> {{key.hashCode() & (parts - 1)}}
> which performs more efficiently. It was then updated further to do the
> following:
> {{((h =
[jira] [Assigned] (IGNITE-4828) Improve the distribution of keys within partitions
[
https://issues.apache.org/jira/browse/IGNITE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs reassigned IGNITE-4828:
--
Assignee: Michael Griggs (was: Michael Griggs)
> Improve the distribution of keys within partitions
> --
>
> Key: IGNITE-4828
> URL: https://issues.apache.org/jira/browse/IGNITE-4828
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 2.0
>
>
> An issue has been found when inserting several million string keys in to a
> cache. Each string key was approximately 22-characters in length. When I
> exported the partition counts (via GG Visor) I was able to see an unusual
> periodicity in the number of keys allocated to partitions. I charted this in
> Excel (1).
> After further investigation, it appears that there is a relationship
> between the number of keys being inserted, the number of partitions
> assigned to the cache and amount of apparent periodicity: a small number
> ofpartitions will cause periodicity to appear with a lower number of keys.
> The {{RendezvousAffinityFunction#partition}} function performs a simple
> calculation of key hashcode modulo partition-count:
> {{U.safeAbs(key.hashCode() % parts)}}
> Digging further I was led to the fact that this is how the Java HashMap
> *used* to behave (2), but was upgraded around Java 1.4 to perform the
> following:
> {{key.hashCode() & (parts - 1)}}
> which performs more efficiently. It was then updated further to do the
> following:
> {{(h = key.hashCode()) ^ (h >>> 16);}}
> with the bit-shift performed to
> bq. incorporate impact of the highest bits that would otherwise never be used
> in index calculations because of table bounds
> When using this function, rather than our
> {{RendezvousAffinityFunction#partition}} implementation, I also saw a
> significant decrease in the periodicity and a better distribution of keys
> amongst partitions (3).
> (1): https://i.imgur.com/0FtCZ2A.png
> (2):
> https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
> (3): https://i.imgur.com/8ZuCSA3.png
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4828) Improve the distribution of keys within partitions
[
https://issues.apache.org/jira/browse/IGNITE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926456#comment-15926456
]
Michael Griggs edited comment on IGNITE-4828 at 3/15/17 5:52 PM:
-
Performance testing:
After 50 iterations, for 10,000,000 calculations per iteration
|| Hash Type || Min (ms) || Max (ms) || Mean (ms) ||
| Old | 166 | 216 | 189 |
| New | 162 | 198 | 180 |
was (Author: michael.gri...@gridgain.com):
Performance testing:
After 50 iterations, for 10,000,000 calculations per iteration
|| Hash Type || Min || Max || Mean ||
| Old | 166 | 216 | 189 |
| New | 162 | 198 | 180 |
> Improve the distribution of keys within partitions
> --
>
> Key: IGNITE-4828
> URL: https://issues.apache.org/jira/browse/IGNITE-4828
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Michael Griggs
> Fix For: 2.0
>
>
> An issue has been found when inserting several million string keys in to a
> cache. Each string key was approximately 22-characters in length. When I
> exported the partition counts (via GG Visor) I was able to see an unusual
> periodicity in the number of keys allocated to partitions. I charted this in
> Excel (1).
> After further investigation, it appears that there is a relationship
> between the number of keys being inserted, the number of partitions
> assigned to the cache and amount of apparent periodicity: a small number
> ofpartitions will cause periodicity to appear with a lower number of keys.
> The {{RendezvousAffinityFunction#partition}} function performs a simple
> calculation of key hashcode modulo partition-count:
> {{U.safeAbs(key.hashCode() % parts)}}
> Digging further I was led to the fact that this is how the Java HashMap
> *used* to behave (2), but was upgraded around Java 1.4 to perform the
> following:
> {{key.hashCode() & (parts - 1)}}
> which performs more efficiently. It was then updated further to do the
> following:
> {{(h = key.hashCode()) ^ (h >>> 16);}}
> with the bit-shift performed to
> bq. incorporate impact of the highest bits that would otherwise never be used
> in index calculations because of table bounds
> When using this function, rather than our
> {{RendezvousAffinityFunction#partition}} implementation, I also saw a
> significant decrease in the periodicity and a better distribution of keys
> amongst partitions (3).
> (1): https://i.imgur.com/0FtCZ2A.png
> (2):
> https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
> (3): https://i.imgur.com/8ZuCSA3.png
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4828) Improve the distribution of keys within partitions
[
https://issues.apache.org/jira/browse/IGNITE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926456#comment-15926456
]
Michael Griggs commented on IGNITE-4828:
Performance testing:
After 50 iterations, for 10,000,000 calculations per iteration
|| Hash Type || Min || Max || Mean ||
| Old | 166 | 216 | 189 |
| New | 162 | 198 | 180 |
> Improve the distribution of keys within partitions
> --
>
> Key: IGNITE-4828
> URL: https://issues.apache.org/jira/browse/IGNITE-4828
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Michael Griggs
> Fix For: 2.0
>
>
> An issue has been found when inserting several million string keys in to a
> cache. Each string key was approximately 22-characters in length. When I
> exported the partition counts (via GG Visor) I was able to see an unusual
> periodicity in the number of keys allocated to partitions. I charted this in
> Excel (1).
> After further investigation, it appears that there is a relationship
> between the number of keys being inserted, the number of partitions
> assigned to the cache and amount of apparent periodicity: a small number
> ofpartitions will cause periodicity to appear with a lower number of keys.
> The {{RendezvousAffinityFunction#partition}} function performs a simple
> calculation of key hashcode modulo partition-count:
> {{U.safeAbs(key.hashCode() % parts)}}
> Digging further I was led to the fact that this is how the Java HashMap
> *used* to behave (2), but was upgraded around Java 1.4 to perform the
> following:
> {{key.hashCode() & (parts - 1)}}
> which performs more efficiently. It was then updated further to do the
> following:
> {{(h = key.hashCode()) ^ (h >>> 16);}}
> with the bit-shift performed to
> bq. incorporate impact of the highest bits that would otherwise never be used
> in index calculations because of table bounds
> When using this function, rather than our
> {{RendezvousAffinityFunction#partition}} implementation, I also saw a
> significant decrease in the periodicity and a better distribution of keys
> amongst partitions (3).
> (1): https://i.imgur.com/0FtCZ2A.png
> (2):
> https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
> (3): https://i.imgur.com/8ZuCSA3.png
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-4828) Improve the distribution of keys within partitions
Michael Griggs created IGNITE-4828:
--
Summary: Improve the distribution of keys within partitions
Key: IGNITE-4828
URL: https://issues.apache.org/jira/browse/IGNITE-4828
Project: Ignite
Issue Type: Improvement
Affects Versions: 1.9
Reporter: Michael Griggs
Fix For: 2.0
An issue has been found when inserting several million string keys in to a
cache. Each string key was approximately 22-characters in length. When I
exported the partition counts (via GG Visor) I was able to see an unusual
periodicity in the number of keys allocated to partitions. I charted this in
Excel (1).
After further investigation, it appears that there is a relationship
between the number of keys being inserted, the number of partitions
assigned to the cache and amount of apparent periodicity: a small number
ofpartitions will cause periodicity to appear with a lower number of keys.
The {{RendezvousAffinityFunction#partition}} function performs a simple
calculation of key hashcode modulo partition-count:
{{U.safeAbs(key.hashCode() % parts)}}
Digging further I was led to the fact that this is how the Java HashMap
*used* to behave (2), but was upgraded around Java 1.4 to perform the
following:
{{key.hashCode() & (parts - 1)}}
which performs more efficiently. It was then updated further to do the
following:
{{(h = key.hashCode()) ^ (h >>> 16);}}
with the bit-shift performed to
bq. incorporate impact of the highest bits that would otherwise never be used
in index calculations because of table bounds
When using this function, rather than our
{{RendezvousAffinityFunction#partition}} implementation, I also saw a
significant decrease in the periodicity and a better distribution of keys
amongst partitions (3).
(1): https://i.imgur.com/0FtCZ2A.png
(2):
https://www.quora.com/Why-does-Java-use-a-mediocre-hashCode-implementation-for-strings
(3): https://i.imgur.com/8ZuCSA3.png
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.
[
https://issues.apache.org/jira/browse/IGNITE-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15823200#comment-15823200
]
Michael Griggs commented on IGNITE-3682:
[~dmagda] Denis, please assign this to me! Mike.
> 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
> Labels: important
> 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] [Commented] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182802#comment-15182802
]
Michael Griggs commented on IGNITE-1903:
Hi Denis,
Sadly I didn't get any response when I raised it on the dev list last November.
Having looked at the code, I think the following would be a good approach
1. Write new logic for serializing node discovery data for new client nodes -
currently the code is the same for both server and client nodes.
2. Make the serialization of the CacheStore optional for client nodes - so
make it a property of the CacheConfiguration.
Does that make sense?
Regards
Mike
> CacheStore implementation is serialised to grid clients whether they require
> it or not
> --
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 1.6
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173578#comment-15173578
]
Michael Griggs commented on IGNITE-1903:
Denis, I'd like to look in to how we can solve this problem. Do you have a
preferred approach?
> CacheStore implementation is serialised to grid clients whether they require
> it or not
> --
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 1.6
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-389) Integration with Spark: IgniteRDD
[
https://issues.apache.org/jira/browse/IGNITE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15074381#comment-15074381
]
Michael Griggs commented on IGNITE-389:
---
I agree Konstantin
> Integration with Spark: IgniteRDD
> -
>
> Key: IGNITE-389
> URL: https://issues.apache.org/jira/browse/IGNITE-389
> Project: Ignite
> Issue Type: New Feature
> Components: general
>Reporter: Dmitriy Setrakyan
>Assignee: Alexey Goncharuk
>Priority: Blocker
> Fix For: 1.6
>
>
> I think we should create an implementation of RDD for Ignite caches (either
> REPLICATED or PARTITIONED).
> Please create Spark project from GIT:
> https://github.com/apache/spark
> In core module for Scala you can find {{org.apache.spark.rdd.RDD}} class
> which is extensible. We should provide our own implementation of this class.
> This package has plenty of other examples on how to create RDD, e.g.
> HadoopRDD, JdbcRDD, etc.
> This integration should be done in ignite-spark module.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065330#comment-15065330
]
Michael Griggs commented on IGNITE-2169:
Tests passed
(http://204.14.53.153/viewLog.html?buildId=90327=buildResultsDiv=IgniteTests_IgniteDataGrid)
please review and commit/revert with comments.
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 1.5
>
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INFO_LIST(aType,aCode,aInt,aDate) VALUES(?,?,?,?)
> UPDATE null.INFO_LIST SET aInt=?,aDate=? WHERE (aType=? AND aCode=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-2173) Some log.debug() calls in CacheAbstractJdbcStore.java are not protected with if (log.isDebugEnabled())
[
https://issues.apache.org/jira/browse/IGNITE-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs resolved IGNITE-2173.
Resolution: Not A Problem
Already fixed
> Some log.debug() calls in CacheAbstractJdbcStore.java are not protected with
> if (log.isDebugEnabled())
> --
>
> Key: IGNITE-2173
> URL: https://issues.apache.org/jira/browse/IGNITE-2173
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>Priority: Minor
> Fix For: 1.6
>
>
> e.g., line 1029
> {code}
> log.debug("Write entries to db one by one using update and insert statements
> [cache name=" +
> {code}
> A side-effect of this is WARNing messages in your log file when these
> statements are executed:
> {code}
> 2015-12-15 16:19:26 WARN CacheJdbcPojoStore:463 - Logging at DEBUG level
> without checking if DEBUG level is enabled:
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2173) Some log.debug() calls in CacheAbstractJdbcStore.java are not protected with if (log.isDebugEnabled())
[
https://issues.apache.org/jira/browse/IGNITE-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs reassigned IGNITE-2173:
--
Assignee: Michael Griggs
> Some log.debug() calls in CacheAbstractJdbcStore.java are not protected with
> if (log.isDebugEnabled())
> --
>
> Key: IGNITE-2173
> URL: https://issues.apache.org/jira/browse/IGNITE-2173
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5
>Reporter: Michael Griggs
>Assignee: Michael Griggs
>Priority: Minor
> Fix For: 1.6
>
>
> e.g., line 1029
> {code}
> log.debug("Write entries to db one by one using update and insert statements
> [cache name=" +
> {code}
> A side-effect of this is WARNing messages in your log file when these
> statements are executed:
> {code}
> 2015-12-15 16:19:26 WARN CacheJdbcPojoStore:463 - Logging at DEBUG level
> without checking if DEBUG level is enabled:
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2173) Some log.debug() calls in CacheAbstractJdbcStore.java are not protected with if (log.isDebugEnabled())
Michael Griggs created IGNITE-2173:
--
Summary: Some log.debug() calls in CacheAbstractJdbcStore.java are
not protected with if (log.isDebugEnabled())
Key: IGNITE-2173
URL: https://issues.apache.org/jira/browse/IGNITE-2173
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.5
Reporter: Michael Griggs
Priority: Minor
e.g., line 1029
{code}
log.debug("Write entries to db one by one using update and insert statements
[cache name=" +
{code}
A side-effect of this is WARNing messages in your log file when these
statements are executed:
{code}
2015-12-15 16:19:26 WARN CacheJdbcPojoStore:463 - Logging at DEBUG level
without checking if DEBUG level is enabled:
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058282#comment-15058282
]
Michael Griggs commented on IGNITE-2169:
I am going to try and fix this before the 1.5 final is taken later this week.
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 1.5
>
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INFO_LIST(aType,aCode,aInt,aDate) VALUES(?,?,?,?)
> UPDATE null.INFO_LIST SET aInt=?,aDate=? WHERE (aType=? AND aCode=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-2169:
---
Fix Version/s: (was: 1.6)
1.5
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 1.5
>
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INFO_LIST(aType,aCode,aInt,aDate) VALUES(?,?,?,?)
> UPDATE null.INFO_LIST SET aInt=?,aDate=? WHERE (aType=? AND aCode=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs reassigned IGNITE-2169:
--
Assignee: Michael Griggs
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
>Assignee: Michael Griggs
> Fix For: 1.6
>
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INFO_LIST(aType,aCode,aInt,aDate) VALUES(?,?,?,?)
> UPDATE null.INFO_LIST SET aInt=?,aDate=? WHERE (aType=? AND aCode=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2173) Some log.debug() calls in CacheAbstractJdbcStore.java are not protected with if (log.isDebugEnabled())
[
https://issues.apache.org/jira/browse/IGNITE-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-2173:
---
Fix Version/s: 1.6
> Some log.debug() calls in CacheAbstractJdbcStore.java are not protected with
> if (log.isDebugEnabled())
> --
>
> Key: IGNITE-2173
> URL: https://issues.apache.org/jira/browse/IGNITE-2173
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5
>Reporter: Michael Griggs
>Priority: Minor
> Fix For: 1.6
>
>
> e.g., line 1029
> {code}
> log.debug("Write entries to db one by one using update and insert statements
> [cache name=" +
> {code}
> A side-effect of this is WARNing messages in your log file when these
> statements are executed:
> {code}
> 2015-12-15 16:19:26 WARN CacheJdbcPojoStore:463 - Logging at DEBUG level
> without checking if DEBUG level is enabled:
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-2169:
---
Fix Version/s: 1.6
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
> Fix For: 1.6
>
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INFO_LIST(aType,aCode,aInt,aDate) VALUES(?,?,?,?)
> UPDATE null.INFO_LIST SET aInt=?,aDate=? WHERE (aType=? AND aCode=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
Michael Griggs created IGNITE-2169:
--
Summary: Ignite-import-schema tool generates incorrect null schema
for JDBC
Key: IGNITE-2169
URL: https://issues.apache.org/jira/browse/IGNITE-2169
Project: Ignite
Issue Type: Bug
Components: wizards
Affects Versions: 1.5
Reporter: Michael Griggs
Given a SQLite database file that contains tables that are not inside a schema,
i.e.:
{{
sqlite> .schema
CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
aDate datetime, PRIMARY KEY(aType, aCode));
}}
The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
following schema:
{{
type.setDatabaseSchema("null");
}}
When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
performs the following check:
{{
fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
}}
and generates the following {{insQuery}} and {{updQuery}}
{{
INSERT INTO null.INTEREST_LIST(type,code,EAGER_LOAD,SUBSCRIBE_DATE)
VALUES(?,?,?,?)
UPDATE null.INTEREST_LIST SET EAGER_LOAD=?,SUBSCRIBE_DATE=? WHERE (type=? AND
code=?)
}}
This is incorrect, and the code generated in CacheConfig.java should be:
{{
type.setDatabaseSchema(null);
}}
i.e., *without* quotes. Then the {{ F#isEmpty(schema) }} call returns the
correct value.
Right now, the code generated by ignite-import-schema.sh is not usable without
finding this problem one's self, and fixing it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-2169:
---
Description:
Given a SQLite database file that contains tables that are not inside a schema,
i.e.:
{code}
sqlite> .schema
CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
aDate datetime, PRIMARY KEY(aType, aCode));
{code}
The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
following schema:
{code}
type.setDatabaseSchema("null");
{code}
When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
performs the following check:
{code}
fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
{code}
and generates the following {{insQuery}} and {{updQuery}}
{code}
INSERT INTO null.INTEREST_LIST(type,code,EAGER_LOAD,SUBSCRIBE_DATE)
VALUES(?,?,?,?)
UPDATE null.INTEREST_LIST SET EAGER_LOAD=?,SUBSCRIBE_DATE=? WHERE (type=? AND
code=?)
{code}
This is incorrect, and the code generated in CacheConfig.java should be:
{code}
type.setDatabaseSchema(null);
{code}
i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
correct value.
*Right now, the code generated by ignite-import-schema.sh is not usable without
finding this problem one's self, and fixing it.*
was:
Given a SQLite database file that contains tables that are not inside a schema,
i.e.:
{{
sqlite> .schema
CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
aDate datetime, PRIMARY KEY(aType, aCode));
}}
The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
following schema:
{{
type.setDatabaseSchema("null");
}}
When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
performs the following check:
{{
fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
}}
and generates the following {{insQuery}} and {{updQuery}}
{{
INSERT INTO null.INTEREST_LIST(type,code,EAGER_LOAD,SUBSCRIBE_DATE)
VALUES(?,?,?,?)
UPDATE null.INTEREST_LIST SET EAGER_LOAD=?,SUBSCRIBE_DATE=? WHERE (type=? AND
code=?)
}}
This is incorrect, and the code generated in CacheConfig.java should be:
{{
type.setDatabaseSchema(null);
}}
i.e., *without* quotes. Then the {{ F#isEmpty(schema) }} call returns the
correct value.
Right now, the code generated by ignite-import-schema.sh is not usable without
finding this problem one's self, and fixing it.
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INTEREST_LIST(type,code,EAGER_LOAD,SUBSCRIBE_DATE)
> VALUES(?,?,?,?)
> UPDATE null.INTEREST_LIST SET EAGER_LOAD=?,SUBSCRIBE_DATE=? WHERE (type=? AND
> code=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058201#comment-15058201
]
Michael Griggs commented on IGNITE-2169:
src/modules/schema-import/src/main/java/org/apache/ignite/schema/generator/CodeGenerator.java
line 609 requires a conditional check for null:
{code}
add2(src, "jdbcType.setDatabaseSchema(pojo. \"" + pojo.schema() + "\");");
{code}
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INTEREST_LIST(type,code,EAGER_LOAD,SUBSCRIBE_DATE)
> VALUES(?,?,?,?)
> UPDATE null.INTEREST_LIST SET EAGER_LOAD=?,SUBSCRIBE_DATE=? WHERE (type=? AND
> code=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2169) Ignite-import-schema tool generates incorrect null schema for JDBC
[
https://issues.apache.org/jira/browse/IGNITE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-2169:
---
Description:
Given a SQLite database file that contains tables that are not inside a schema,
i.e.:
{code}
sqlite> .schema
CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
aDate datetime, PRIMARY KEY(aType, aCode));
{code}
The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
following schema:
{code}
type.setDatabaseSchema("null");
{code}
When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
performs the following check:
{code}
fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
{code}
and generates the following {{insQuery}} and {{updQuery}}
{code}
INSERT INTO null.INFO_LIST(aType,aCode,aInt,aDate) VALUES(?,?,?,?)
UPDATE null.INFO_LIST SET aInt=?,aDate=? WHERE (aType=? AND aCode=?)
{code}
This is incorrect, and the code generated in CacheConfig.java should be:
{code}
type.setDatabaseSchema(null);
{code}
i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
correct value.
*Right now, the code generated by ignite-import-schema.sh is not usable without
finding this problem one's self, and fixing it.*
was:
Given a SQLite database file that contains tables that are not inside a schema,
i.e.:
{code}
sqlite> .schema
CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
aDate datetime, PRIMARY KEY(aType, aCode));
{code}
The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
following schema:
{code}
type.setDatabaseSchema("null");
{code}
When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
performs the following check:
{code}
fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
{code}
and generates the following {{insQuery}} and {{updQuery}}
{code}
INSERT INTO null.INTEREST_LIST(type,code,EAGER_LOAD,SUBSCRIBE_DATE)
VALUES(?,?,?,?)
UPDATE null.INTEREST_LIST SET EAGER_LOAD=?,SUBSCRIBE_DATE=? WHERE (type=? AND
code=?)
{code}
This is incorrect, and the code generated in CacheConfig.java should be:
{code}
type.setDatabaseSchema(null);
{code}
i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
correct value.
*Right now, the code generated by ignite-import-schema.sh is not usable without
finding this problem one's self, and fixing it.*
> Ignite-import-schema tool generates incorrect null schema for JDBC
> --
>
> Key: IGNITE-2169
> URL: https://issues.apache.org/jira/browse/IGNITE-2169
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 1.5
>Reporter: Michael Griggs
>
> Given a SQLite database file that contains tables that are not inside a
> schema, i.e.:
> {code}
> sqlite> .schema
> CREATE TABLE INFO_LIST(aType varchar(64), aCode varchar(128), aInt INTEGER,
> aDate datetime, PRIMARY KEY(aType, aCode));
> {code}
> The ignite-import-schema.sh tool generates a {{CacheConfig.java}} with the
> following schema:
> {code}
> type.setDatabaseSchema("null");
> {code}
> When the {{CacheAbstractJdbcStore#EntryMapping}} class is instantiated, it
> performs the following check:
> {code}
> fullTblName = F.isEmpty(schema) ? tblName : schema + "." + tblName;
> {code}
> and generates the following {{insQuery}} and {{updQuery}}
> {code}
> INSERT INTO null.INFO_LIST(aType,aCode,aInt,aDate) VALUES(?,?,?,?)
> UPDATE null.INFO_LIST SET aInt=?,aDate=? WHERE (aType=? AND aCode=?)
> {code}
> This is incorrect, and the code generated in CacheConfig.java should be:
> {code}
> type.setDatabaseSchema(null);
> {code}
> i.e., *without* quotes. Then the {{F#isEmpty(schema)}} call returns the
> correct value.
> *Right now, the code generated by ignite-import-schema.sh is not usable
> without finding this problem one's self, and fixing it.*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1876) Access to a non-existing entry produces events
[ https://issues.apache.org/jira/browse/IGNITE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs resolved IGNITE-1876. Resolution: Cannot Reproduce > Access to a non-existing entry produces events > -- > > Key: IGNITE-1876 > URL: https://issues.apache.org/jira/browse/IGNITE-1876 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Sergey Kozlov >Assignee: Michael Griggs >Priority: Minor > Fix For: 1.5 > > > Trying to get access to a non-existing entry produces following events: > for get operation: > CACHE_ENTRY_CREATED > CACHE_OBJECT_READ > for remove operation > CACHE_ENTRY_CREATED > CACHE_OBJECT_REMOVED > Such behavior should be either properly documented or fixed by following ways: > - do not generate event > - generate a new event (something named EVT_CACHE_NO_ENTRY) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1789) Data Snapshots for Ignite caches
[ https://issues.apache.org/jira/browse/IGNITE-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15048717#comment-15048717 ] Michael Griggs commented on IGNITE-1789: For my use-case, I would prefer to have the option to copy all in-memory objects and give them new keys that have the snapshot name added in some way, but remain in the same cache. So for example, Country:GB would get snapshotted and copied to Country:GB:snapshot1.0, and both Country:GB and Country:GB:snapshot1.0 would be stored in memory. > Data Snapshots for Ignite caches > > > Key: IGNITE-1789 > URL: https://issues.apache.org/jira/browse/IGNITE-1789 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Raúl Kripalani > > There was a discussion in the dev forum about Data Snapshots in Ignite as a > way to obtain a consistent and "frozen" view of one or multiple caches in > order to execute a set of SQL queries, distributed closures, map reduce, etc. > without having to worry about data slippage (or moving data). > The discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Data-Snapshots-in-Ignite-td4183.html > and we still need to mature the idea, but several users chimed in and > considered it interesting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-1903:
---
Description:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{ SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }}
where {{ c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
was:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
> CacheStore implementation is serialised to grid clients whether they require
> it or not
> --
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Michael Griggs
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
>
[jira] [Updated] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-1903:
---
Description:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
was:
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{ SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }}
where {{ c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite }} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
> CacheStore implementation is serialised to grid clients whether they require
> it or not
> --
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Michael Griggs
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
>
[jira] [Created] (IGNITE-1903) CacheStore implementation is serialised to grid clients whether they require it or not
Michael Griggs created IGNITE-1903:
--
Summary: CacheStore implementation is serialised to grid clients
whether they require it or not
Key: IGNITE-1903
URL: https://issues.apache.org/jira/browse/IGNITE-1903
Project: Ignite
Issue Type: Bug
Affects Versions: 1.5
Reporter: Michael Griggs
See User discussion thread:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
Brief summary: When a grid client joins the grid (clientMode=true) it receives
a message from the server node(s) on the grid that contains the serialized
CacheStore implementation object. If the client does not have this class on
its CLASSPATH (and there is no reason it should, as it is a client) then the
de-serialization of this message will fail, causing this exception:
{{SEVERE: Failed to unmarshal discovery data for component: 1
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@14dad5dc
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
at
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException:
c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}}
where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
implementation.
The ostensible reason for the CacheStore serialization is so that clients of a
TRANSACTIONAL cache can begin the transaction on the underlying store.
The only current solution to this is to add the grid node's CacheStore
implementation class definition to the CLASSPATH of the client. This creates
an *undesirable coupling* between server and client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1681) loadAll threshold is not configurable for CacheStoreBalancingWrapper
[
https://issues.apache.org/jira/browse/IGNITE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15000475#comment-15000475
]
Michael Griggs commented on IGNITE-1681:
Denis, please accept my apologies for having caused you extra work, and thank
you for cleaning up after me on this occasion. I will review the two patches
and make sure that my next submissions are cleaner and in line with coding
standards, javadoc, naming conventions, etc. Thanks again!
> loadAll threshold is not configurable for CacheStoreBalancingWrapper
>
>
> Key: IGNITE-1681
> URL: https://issues.apache.org/jira/browse/IGNITE-1681
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Assignee: Denis Magda
> Fix For: 1.5
>
> Attachments: ignite-1681-final.patch
>
>
> CacheStoreBalancingWrapper is created in cache store manager using default
> constructor. There is no way to override a default value for loadAllThreshold.
> We can add a cache configuration parameter named
> storeConcurrentLoadAllThreshold to control this:
> {code}
> CacheConfiguration {
> ...
> public int getStoreConcurrentLoadAllThreshold() {...}
> public void setStoreConcurrentLoadAllThreshold(int
> storeConcurrentLoadAllThreshold) {...}
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1681) loadAll threshold is not configurable for CacheStoreBalancingWrapper
[
https://issues.apache.org/jira/browse/IGNITE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14999582#comment-14999582
]
Michael Griggs commented on IGNITE-1681:
Please see PR https://github.com/apache/ignite/pull/218
If I have screwed something up with this PR please let me know, I am still
learning Git.
> loadAll threshold is not configurable for CacheStoreBalancingWrapper
>
>
> Key: IGNITE-1681
> URL: https://issues.apache.org/jira/browse/IGNITE-1681
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Assignee: Michael Griggs
> Fix For: 1.5
>
> Attachments: master_6844370_ignite-1681.patch
>
>
> CacheStoreBalancingWrapper is created in cache store manager using default
> constructor. There is no way to override a default value for loadAllThreshold.
> We can add a cache configuration parameter named
> storeConcurrentLoadAllThreshold to control this:
> {code}
> CacheConfiguration {
> ...
> public int getStoreConcurrentLoadAllThreshold() {...}
> public void setStoreConcurrentLoadAllThreshold(int
> storeConcurrentLoadAllThreshold) {...}
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-1681) loadAll threshold is not configurable for CacheStoreBalancingWrapper
[
https://issues.apache.org/jira/browse/IGNITE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-1681:
---
Comment: was deleted
(was: Please see PR https://github.com/apache/ignite/pull/217
This is my first (ever) Github pull request, so if I have screwed something up
please let me know.)
> loadAll threshold is not configurable for CacheStoreBalancingWrapper
>
>
> Key: IGNITE-1681
> URL: https://issues.apache.org/jira/browse/IGNITE-1681
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Assignee: Michael Griggs
> Fix For: 1.5
>
> Attachments: master_6844370_ignite-1681.patch
>
>
> CacheStoreBalancingWrapper is created in cache store manager using default
> constructor. There is no way to override a default value for loadAllThreshold.
> We can add a cache configuration parameter named
> storeConcurrentLoadAllThreshold to control this:
> {code}
> CacheConfiguration {
> ...
> public int getStoreConcurrentLoadAllThreshold() {...}
> public void setStoreConcurrentLoadAllThreshold(int
> storeConcurrentLoadAllThreshold) {...}
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1681) loadAll threshold is not configurable for CacheStoreBalancingWrapper
[
https://issues.apache.org/jira/browse/IGNITE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14999571#comment-14999571
]
Michael Griggs commented on IGNITE-1681:
Please see PR https://github.com/apache/ignite/pull/217
This is my first (ever) Github pull request, so if I have screwed something up
please let me know.
> loadAll threshold is not configurable for CacheStoreBalancingWrapper
>
>
> Key: IGNITE-1681
> URL: https://issues.apache.org/jira/browse/IGNITE-1681
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Assignee: Michael Griggs
> Fix For: 1.5
>
> Attachments: master_6844370_ignite-1681.patch
>
>
> CacheStoreBalancingWrapper is created in cache store manager using default
> constructor. There is no way to override a default value for loadAllThreshold.
> We can add a cache configuration parameter named
> storeConcurrentLoadAllThreshold to control this:
> {code}
> CacheConfiguration {
> ...
> public int getStoreConcurrentLoadAllThreshold() {...}
> public void setStoreConcurrentLoadAllThreshold(int
> storeConcurrentLoadAllThreshold) {...}
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1876) Access to a non-existing entry produces events
[ https://issues.apache.org/jira/browse/IGNITE-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs reassigned IGNITE-1876: -- Assignee: Michael Griggs (was: Yakov Zhdanov) > Access to a non-existing entry produces events > -- > > Key: IGNITE-1876 > URL: https://issues.apache.org/jira/browse/IGNITE-1876 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Sergey Kozlov >Assignee: Michael Griggs >Priority: Minor > Fix For: 1.6 > > > Trying to get access to a non-existing entry produces following events: > for get operation: > CACHE_ENTRY_CREATED > CACHE_OBJECT_READ > for remove operation > CACHE_ENTRY_CREATED > CACHE_OBJECT_REMOVED > Such behavior should be either properly documented or fixed by following ways: > - do not generate event > - generate a new event (something named EVT_CACHE_NO_ENTRY) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1774) REST API should be implemented using Jersey
[ https://issues.apache.org/jira/browse/IGNITE-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs reassigned IGNITE-1774: -- Assignee: Michael Griggs > REST API should be implemented using Jersey > --- > > Key: IGNITE-1774 > URL: https://issues.apache.org/jira/browse/IGNITE-1774 > Project: Ignite > Issue Type: Improvement >Affects Versions: ignite-1.4 >Reporter: Michael Griggs >Assignee: Michael Griggs > > Jersey+Jetty is a well established method for implementing RESTful > interfaces. > The REST API should implement non-modifying cache methods (e.g., get()) via > HTTP GET methods, and modifying cache methods (e.g., put(), replace()) via > HTTP POST methods. This allows the JSON data to be correctly formatted in > the body of the message, instead of needing to be URL-encoded on the URI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1773) replace(), put() or similar modifying operations cannot be made via the REST API
Michael Griggs created IGNITE-1773: -- Summary: replace(), put() or similar modifying operations cannot be made via the REST API Key: IGNITE-1773 URL: https://issues.apache.org/jira/browse/IGNITE-1773 Project: Ignite Issue Type: Bug Affects Versions: ignite-1.4 Reporter: Michael Griggs The replace() method requires a key and a newVal to be supplied, both of type String. If my newVal is of type JSON then I have to put this data on the URI, because replace() is an HTTP GET method. If this JSON has non-URI safe characters (very likely it will) then it has to be URL-encoded. However, it is not correctly decoded when retrieved from the cache. If I do ignite/?cmd=replace=mykey=[URL-encoded json-data]=c followed by ignite /?cmd=get=mykey then the data that is returned from the get() has all of the double quotes escaped with the "\" character. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1773) REST API should accept replace(), put() and other modifying calls via HTTP POST not HTTP GET
[ https://issues.apache.org/jira/browse/IGNITE-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Griggs updated IGNITE-1773: --- Summary: REST API should accept replace(), put() and other modifying calls via HTTP POST not HTTP GET (was: replace(), put() or similar modifying operations cannot be made via the REST API) > REST API should accept replace(), put() and other modifying calls via HTTP > POST not HTTP GET > > > Key: IGNITE-1773 > URL: https://issues.apache.org/jira/browse/IGNITE-1773 > Project: Ignite > Issue Type: Bug >Affects Versions: ignite-1.4 >Reporter: Michael Griggs > > The replace() method requires a key and a newVal to be supplied, both of type > String. If my newVal is of type JSON then I have to put this data on the URI, > because replace() is an HTTP GET method. If this JSON has non-URI safe > characters (very likely it will) then it has to be URL-encoded. However, it > is not correctly decoded when retrieved from the cache. > If I do > ignite/?cmd=replace=mykey=[URL-encoded json-data]=c > followed by > ignite /?cmd=get=mykey > then the data that is returned from the get() has all of the double quotes > escaped with the "\" character. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1774) REST API should be implemented using Jersey
Michael Griggs created IGNITE-1774: -- Summary: REST API should be implemented using Jersey Key: IGNITE-1774 URL: https://issues.apache.org/jira/browse/IGNITE-1774 Project: Ignite Issue Type: Improvement Affects Versions: ignite-1.4 Reporter: Michael Griggs Jersey+Jetty is a well established method for implementing RESTful interfaces. The REST API should implement non-modifying cache methods (e.g., get()) via HTTP GET methods, and modifying cache methods (e.g., put(), replace()) via HTTP POST methods. This allows the JSON data to be correctly formatted in the body of the message, instead of needing to be URL-encoded on the URI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1681) loadAll threshold is not configurable for CacheStoreBalancingWrapper
[
https://issues.apache.org/jira/browse/IGNITE-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Griggs updated IGNITE-1681:
---
Attachment: master_6844370_ignite-1681.patch
> loadAll threshold is not configurable for CacheStoreBalancingWrapper
>
>
> Key: IGNITE-1681
> URL: https://issues.apache.org/jira/browse/IGNITE-1681
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Assignee: Michael Griggs
> Fix For: 1.5
>
> Attachments: master_6844370_ignite-1681.patch
>
>
> CacheStoreBalancingWrapper is created in cache store manager using default
> constructor. There is no way to override a default value for loadAllThreshold.
> We can add a cache configuration parameter named
> storeConcurrentLoadAllThreshold to control this:
> {code}
> CacheConfiguration {
> ...
> public int getStoreConcurrentLoadAllThreshold() {...}
> public void setStoreConcurrentLoadAllThreshold(int
> storeConcurrentLoadAllThreshold) {...}
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
