[jira] [Commented] (IGNITE-5750) Format of uptime for metrics
[ https://issues.apache.org/jira/browse/IGNITE-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107512#comment-16107512 ] Konstantin Boudnik commented on IGNITE-5750: I am going to commit this today - the patch has fallen through the cracks. > Format of uptime for metrics > > > Key: IGNITE-5750 > URL: https://issues.apache.org/jira/browse/IGNITE-5750 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.0 >Reporter: Alexandr Kuramshin >Assignee: Yevgeniy Ignatyev >Priority: Trivial > Labels: newbie > Fix For: 2.2 > > > Metrics for local node shows uptime formatted as 00:00:00:000 > But the last colon should be changed to the dot. > Right format is 00:00:00.000 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5597) Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache
[
https://issues.apache.org/jira/browse/IGNITE-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16098981#comment-16098981
]
Konstantin Boudnik commented on IGNITE-5597:
Thanks for committing the patch, [~dkarachentsev]dkarachentsev!
Please note, that patches need to be applied with {{git am -s}} command to
preserve the original author's name in the interest of giving the credit where
is due.
> Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache
> ---
>
> Key: IGNITE-5597
> URL: https://issues.apache.org/jira/browse/IGNITE-5597
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Andrei Yakushin
> Labels: javadoc
> Fix For: 2.2
>
>
> RendezvousAffinityFunction.getPartitions() Javadoc says:
> {code:java}
> * Note that for fully replicated caches this method should always
> * return {@code 1}.
> {code}
> but it's not true, it works the same as PARTITIONED cache.
> Affinity.mapKeyToNode(K key) javadoc says:
> {code:java}
> *
> * For fully replicated caches first node ID returned by {@link
> AffinityFunction}
> * is returned.
> *
> * For partitioned caches, primary node for the given key is
> returned.
> {code}
> it looks confusing, while REPLICATED cache has primary nodes for keys as
> PRATITIONED.
> Also,
> {code:java}
> * Provides affinity information to detect which node is primary and which
> nodes are
> * backups for a partitioned cache.
> {code}
> Affinity matter for REPLICATED cache too.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-899) Add wrapper script to TC automation system
[ https://issues.apache.org/jira/browse/IGNITE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik resolved IGNITE-899. --- Resolution: Not A Problem Looks like this piece isn't demanded by anyone, so closing. > Add wrapper script to TC automation system > -- > > Key: IGNITE-899 > URL: https://issues.apache.org/jira/browse/IGNITE-899 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: sprint-4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Attachments: IGNITE-899.patch > > > To improve the UX of patch testing system introduced in IGNITE-620, gradle > wrapper script needs to be added -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-811) Bundle Ignite node with OSv microkernel
[ https://issues.apache.org/jira/browse/IGNITE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik resolved IGNITE-811. --- Resolution: Won't Fix I don't think this has any relevancy anymore. Besides, I have completely lost the interest into unikernels. > Bundle Ignite node with OSv microkernel > --- > > Key: IGNITE-811 > URL: https://issues.apache.org/jira/browse/IGNITE-811 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: sprint-2 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > > I'd like to experiment with bundling Ignite nodes with [OSv|http://osv.io/]. > The advantages of using OSv are multi fold, here are just some of them: > # significant network stack performance improvements. Compared to the > traditional TCP/IP stack you can see 150% better performance on your app. > network IO > # full isolation (unlike Docker) > # no kernel overhead, caused by context switching > # state-full transition of an application from one OSv instance to another > and many others. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
[
https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095287#comment-16095287
]
Konstantin Boudnik edited comment on IGNITE-5123 at 7/20/17 8:09 PM:
-
I am _not_ saying one is better than another (and the example you've provided
doesn't look that much ticket specific for me, really). I am saying that
splitting the discussion through the multiple sources makes it harder for
people to use later.
was (Author: cos):
I am saying one is better than another (and the example you've provided doesn't
look that much ticket specific for me, really). I am saying that splitting the
discussion through the multiple sources makes it harder for people to use later.
> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
[
https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095287#comment-16095287
]
Konstantin Boudnik commented on IGNITE-5123:
I am saying one is better than another (and the example you've provided doesn't
look that much ticket specific for me, really). I am saying that splitting the
discussion through the multiple sources makes it harder for people to use later.
> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5123) Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
[
https://issues.apache.org/jira/browse/IGNITE-5123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095262#comment-16095262
]
Konstantin Boudnik commented on IGNITE-5123:
Are we tracking the JIRA in two different places? It might create an
inconvenience if anyone would ever need to follow through the discussion. It
makes sense to keep the JIRA discussion on the ticket (or in the PR _if_ such
PR is named correctly and ASF Infra bot can publish the updates to the JIRA
automatically).
> Ignite.cache(String) returns null in PluginProvider.onIgniteStart()
> ---
>
> Key: IGNITE-5123
> URL: https://issues.apache.org/jira/browse/IGNITE-5123
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nick Pordash
>Assignee: Yevgeniy Ignatyev
> Fix For: 2.2
>
> Attachments: ignite-plugin-failure.zip
>
>
> Given an Ignite node that has pre-configured caches (via
> IgniteConfiguration.setCacheConfiguration) if you try to obtain a reference
> to the cache instance in PluginProvider.onIgniteStart() you'll get a null
> reference.
> @Override
> public void onIgniteStart() throws IgniteCheckedException {
> ignite.cacheNames().forEach(name -> {
> assert ignite.cache(name) != null : "Cache is null: " + name;
> });
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5750) Format of uptime for metrics
[ https://issues.apache.org/jira/browse/IGNITE-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094845#comment-16094845 ] Konstantin Boudnik commented on IGNITE-5750: [~ein], do you think it is ready for commit? Please let me know if I can help! > Format of uptime for metrics > > > Key: IGNITE-5750 > URL: https://issues.apache.org/jira/browse/IGNITE-5750 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.0 >Reporter: Alexandr Kuramshin >Assignee: Yevgeniy Ignatyev >Priority: Trivial > Labels: newbie > Fix For: 2.1 > > > Metrics for local node shows uptime formatted as 00:00:00:000 > But the last colon should be changed to the dot. > Right format is 00:00:00.000 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5473) Create ignite troubleshooting logger
[ https://issues.apache.org/jira/browse/IGNITE-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16093392#comment-16093392 ] Konstantin Boudnik commented on IGNITE-5473: Yup, that's actually better than what I offered ;)Thanks! > Create ignite troubleshooting logger > > > Key: IGNITE-5473 > URL: https://issues.apache.org/jira/browse/IGNITE-5473 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Priority: Critical > Labels: important, observability > Fix For: 2.2 > > > Currently, we have two extremes of logging - either INFO wich logs almost > nothing, or DEBUG, which will pollute logs with too verbose messages. > We should create a 'troubleshooting' logger, which should be easily enabled > (via a system property, for example) and log all stability-critical node and > cluster events: > * Connection events (both communication and discovery), handshake status > * ALL ignored messages and skipped actions (even those we assume are safe to > ignore) > * Partition exchange stages and timings > * Verbose discovery state changes (this should make it easy to understand > the reason for 'Node has not been connected to the topology') > * Transaction failover stages and actions > * All unlogged exceptions > * Responses that took more than N milliseconds when in normal they should > return right away > * Long discovery SPI messages processing times > * Managed service deployment stages > * Marshaller mappings registration and notification > * Binary metadata registration and notification > * Continuous query registration / notification > (add more) > The amount of logging should be chosen accurately so that it would be safe to > enable this logger in production clusters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5473) Create ignite troubleshooting logger
[ https://issues.apache.org/jira/browse/IGNITE-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16093342#comment-16093342 ] Konstantin Boudnik commented on IGNITE-5473: Looks like this has accidentally fixed IGNITE-5332 as well? If so, the other ticket needs to be marked properly as duplicate to avoid any confusion for new contributors. > Create ignite troubleshooting logger > > > Key: IGNITE-5473 > URL: https://issues.apache.org/jira/browse/IGNITE-5473 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Priority: Critical > Labels: important, observability > Fix For: 2.2 > > > Currently, we have two extremes of logging - either INFO wich logs almost > nothing, or DEBUG, which will pollute logs with too verbose messages. > We should create a 'troubleshooting' logger, which should be easily enabled > (via a system property, for example) and log all stability-critical node and > cluster events: > * Connection events (both communication and discovery), handshake status > * ALL ignored messages and skipped actions (even those we assume are safe to > ignore) > * Partition exchange stages and timings > * Verbose discovery state changes (this should make it easy to understand > the reason for 'Node has not been connected to the topology') > * Transaction failover stages and actions > * All unlogged exceptions > * Responses that took more than N milliseconds when in normal they should > return right away > * Long discovery SPI messages processing times > * Managed service deployment stages > * Marshaller mappings registration and notification > * Binary metadata registration and notification > * Continuous query registration / notification > (add more) > The amount of logging should be chosen accurately so that it would be safe to > enable this logger in production clusters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint
[ https://issues.apache.org/jira/browse/IGNITE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-5413: --- Attachment: 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch Even more explicit version of the patch. > Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint > - > > Key: IGNITE-5413 > URL: https://issues.apache.org/jira/browse/IGNITE-5413 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik >Priority: Blocker > Fix For: 2.1 > > Attachments: > 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch, > 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch > > > Apache Ignite is periodically accessing to > https://ignite.run/update_status_ignite-plain-text.php > It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but > of course it has been happening for a long time. > Corresponding code is > https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82 > Posting JVM env variable (or any other user's specific information) without > an explicit user's consent is a bad idea and should be disabled by default. > See > https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313 > for more details. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint
[ https://issues.apache.org/jira/browse/IGNITE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-5413: --- Attachment: 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch Here's the patch to turn this functionality off completely until the time we know what and how to deal with this. > Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint > - > > Key: IGNITE-5413 > URL: https://issues.apache.org/jira/browse/IGNITE-5413 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik >Priority: Blocker > Fix For: 2.1 > > Attachments: > 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch > > > Apache Ignite is periodically accessing to > https://ignite.run/update_status_ignite-plain-text.php > It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but > of course it has been happening for a long time. > Corresponding code is > https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82 > Posting JVM env variable (or any other user's specific information) without > an explicit user's consent is a bad idea and should be disabled by default. > See > https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313 > for more details. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint
[ https://issues.apache.org/jira/browse/IGNITE-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik reassigned IGNITE-5413: -- Assignee: Konstantin Boudnik > Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint > - > > Key: IGNITE-5413 > URL: https://issues.apache.org/jira/browse/IGNITE-5413 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik >Priority: Blocker > Fix For: 2.1 > > > Apache Ignite is periodically accessing to > https://ignite.run/update_status_ignite-plain-text.php > It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but > of course it has been happening for a long time. > Corresponding code is > https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82 > Posting JVM env variable (or any other user's specific information) without > an explicit user's consent is a bad idea and should be disabled by default. > See > https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313 > for more details. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint
Konstantin Boudnik created IGNITE-5413: -- Summary: Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint Key: IGNITE-5413 URL: https://issues.apache.org/jira/browse/IGNITE-5413 Project: Ignite Issue Type: Bug Components: general Affects Versions: 1.1.4 Reporter: Konstantin Boudnik Priority: Blocker Fix For: 2.1 Apache Ignite is periodically accessing to https://ignite.run/update_status_ignite-plain-text.php It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but of course it has been happening for a long time. Corresponding code is https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82 Posting JVM env variable (or any other user's specific information) without an explicit user's consent is a bad idea and should be disabled by default. See https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313 for more details. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5106) Website still contains links to to "incubator-ignite"
[ https://issues.apache.org/jira/browse/IGNITE-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15987509#comment-15987509 ] Konstantin Boudnik commented on IGNITE-5106: One of the spots is here - https://svn.apache.org/viewvc/ignite/site/trunk/features/streaming.html?view=markup > Website still contains links to to "incubator-ignite" > -- > > Key: IGNITE-5106 > URL: https://issues.apache.org/jira/browse/IGNITE-5106 > Project: Ignite > Issue Type: Bug > Components: website >Affects Versions: 1.1.4 >Reporter: Konstantin Boudnik > Fix For: 2.0 > > > At least some of the examples referred by the website pages are pointed to > "incubator-ignite" mirror on the github. Which were empty for a long time. > Let's get this fixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5106) Website still contains links to to "incubator-ignite"
Konstantin Boudnik created IGNITE-5106: -- Summary: Website still contains links to to "incubator-ignite" Key: IGNITE-5106 URL: https://issues.apache.org/jira/browse/IGNITE-5106 Project: Ignite Issue Type: Bug Components: website Affects Versions: 1.1.4 Reporter: Konstantin Boudnik Fix For: 2.0 At least some of the examples referred by the website pages are pointed to "incubator-ignite" mirror on the github. Which were empty for a long time. Let's get this fixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-1173) Hive over Ignite integration should be documented in public
[ https://issues.apache.org/jira/browse/IGNITE-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983344#comment-15983344 ] Konstantin Boudnik commented on IGNITE-1173: The referred URL does no longer exist, BTW > Hive over Ignite integration should be documented in public > --- > > Key: IGNITE-1173 > URL: https://issues.apache.org/jira/browse/IGNITE-1173 > Project: Ignite > Issue Type: Improvement > Components: hadoop >Affects Versions: sprint-7 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > Fix For: ignite-1.4 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-653) Add cache name to exception message
[
https://issues.apache.org/jira/browse/IGNITE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik reassigned IGNITE-653:
-
Assignee: Jeyhun Karimov
> Add cache name to exception message
> ---
>
> Key: IGNITE-653
> URL: https://issues.apache.org/jira/browse/IGNITE-653
> Project: Ignite
> Issue Type: Task
> Components: cache, UI
>Affects Versions: sprint-3
>Reporter: Pavel Konstantinov
>Assignee: Jeyhun Karimov
>Priority: Trivial
>
> {code}
> CacheServerNotFoundException: Failed to map keys for cache (all partition
> nodes left the grid)
> {code}
> {code}
> ClusterTopologyServerNotFoundException: Failed to map keys for cache (all
> partition nodes left the grid).
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-653) Add cache name to exception message
[
https://issues.apache.org/jira/browse/IGNITE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15879597#comment-15879597
]
Konstantin Boudnik commented on IGNITE-653:
---
Done
> Add cache name to exception message
> ---
>
> Key: IGNITE-653
> URL: https://issues.apache.org/jira/browse/IGNITE-653
> Project: Ignite
> Issue Type: Task
> Components: cache, UI
>Affects Versions: sprint-3
>Reporter: Pavel Konstantinov
>Assignee: Jeyhun Karimov
>Priority: Trivial
>
> {code}
> CacheServerNotFoundException: Failed to map keys for cache (all partition
> nodes left the grid)
> {code}
> {code}
> ClusterTopologyServerNotFoundException: Failed to map keys for cache (all
> partition nodes left the grid).
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-1656) Get rid of md5 and sha1 in favor of sha512
[ https://issues.apache.org/jira/browse/IGNITE-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15694152#comment-15694152 ] Konstantin Boudnik commented on IGNITE-1656: I stand against lowering the priority of this, because signing releases with a weak and proven insecure algorithm posses the risk of delivering malicious code to the users. > Get rid of md5 and sha1 in favor of sha512 > -- > > Key: IGNITE-1656 > URL: https://issues.apache.org/jira/browse/IGNITE-1656 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Ivan Veselovsky > Fix For: 2.0 > > > Description of the problem wrt sha1 is there: > https://sites.google.com/site/itstheshappening/ . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1656) Get rid of md5 and sha1 in favor of sha512
[ https://issues.apache.org/jira/browse/IGNITE-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1656: --- Priority: Major (was: Minor) > Get rid of md5 and sha1 in favor of sha512 > -- > > Key: IGNITE-1656 > URL: https://issues.apache.org/jira/browse/IGNITE-1656 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Ivan Veselovsky > Fix For: 2.0 > > > Description of the problem wrt sha1 is there: > https://sites.google.com/site/itstheshappening/ . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches
[ https://issues.apache.org/jira/browse/IGNITE-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-3933: --- Description: There is an issue with JDBC when trying to play with different types of caches using the same JDBC connection. *Example 1 - using simple JDBC connection URL* jdbc:ignite:cfg://file:///my-ignite-client-config.xm 1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* returns as many duplicates for each record as many nodes in an Ignite cluster. Same problem with *select count(\*) from my_replicated_cache* - it returns actual number of records multiplied by the number of Ignite nodes. 2) At the same time if traversing the cache using "for" loop and iterator, it returns exactly what's needed without any duplicates. *Example 2 - specifying replicated or partitioned cache in JDBC connection URL* jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm 1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from my_replicated_cache* return duplicates 2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates for the *select * from my_replicated_cache* query. At the same time it failed to execute simple queries like *select * from my_partitioned_cache* against *PARTITIONED* caches throwing this error: *java.lang.RuntimeException: javax.cache.CacheException: Queries running on replicated cache should not contain JOINs with partitioned tables [rCache=product, pCache=order]* The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* caches in one SQL query (using one JDBC connection) looks not very good. Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL for optimization purposes doesn't look good. It's better to utilize rather wide used "hits" approach, to provide optimization hints inside SQL query. Otherwise it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL queries. was: There is an issue with JDBC when trying to play with different types of caches using the same JDBC connection. *Example 1 - using simple JDBC connection URL* jdbc:ignite:cfg://file:///my-ignite-client-config.xm 1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* returns as many duplicates for each record as many nodes in an Ignite cluster. Same problem with *select count(*) from my_replicated_cache* - it returns actual number of records multiplied by the number of Ignite nodes. 2) At the same time if traversing the cache using "for" loop and iterator, it returns exactly what's needed without any duplicates. *Example 2 - specifying replicated or partitioned cache in JDBC connection URL* jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm 1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from my_replicated_cache* return duplicates 2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates for the *select * from my_replicated_cache* query. At the same time it failed to execute simple queries like *select * from my_partitioned_cache* against *PARTITIONED* caches throwing this error: *java.lang.RuntimeException: javax.cache.CacheException: Queries running on replicated cache should not contain JOINs with partitioned tables [rCache=product, pCache=order]* The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* caches in one SQL query (using one JDBC connection) looks not very good. Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL for optimization purposes doesn't look good. It's better to utilize rather wide used "hits" approach, to provide optimization hints inside SQL query. Otherwise it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL queries. > JDBC issue with Replicated & Partitioned caches > --- > > Key: IGNITE-3933 > URL: https://issues.apache.org/jira/browse/IGNITE-3933 > Project: Ignite > Issue Type: Bug > Components: jdbc-driver, odbc, SQL >Affects Versions: 1.8 >Reporter: Igor Rudyak >Priority: Critical > > There is an issue with JDBC when trying to play with different types of > caches using the same JDBC connection. > *Example 1 - using simple JDBC connection URL* > jdbc:ignite:cfg://file:///my-ignite-client-config.xm > 1) For *REPLICATED* caches SQL query like *select \* from > my_replicated_cache* returns as many duplicates for each record as many nodes > in an Ignite cluster. Same problem with *select count(\*) from > my_replicated_cache* - it returns actual number of records multiplied by the > number of Ignite nodes. > 2) At the same time if traversing the cache using "for" loop and iterator, it > returns
[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches
[ https://issues.apache.org/jira/browse/IGNITE-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-3933: --- Description: There is an issue with JDBC when trying to play with different types of caches using the same JDBC connection. *Example 1 - using simple JDBC connection URL* jdbc:ignite:cfg://file:///my-ignite-client-config.xm 1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* returns as many duplicates for each record as many nodes in an Ignite cluster. Same problem with *select count(*) from my_replicated_cache* - it returns actual number of records multiplied by the number of Ignite nodes. 2) At the same time if traversing the cache using "for" loop and iterator, it returns exactly what's needed without any duplicates. *Example 2 - specifying replicated or partitioned cache in JDBC connection URL* jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm 1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from my_replicated_cache* return duplicates 2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates for the *select * from my_replicated_cache* query. At the same time it failed to execute simple queries like *select * from my_partitioned_cache* against *PARTITIONED* caches throwing this error: *java.lang.RuntimeException: javax.cache.CacheException: Queries running on replicated cache should not contain JOINs with partitioned tables [rCache=product, pCache=order]* The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* caches in one SQL query (using one JDBC connection) looks not very good. Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL for optimization purposes doesn't look good. It's better to utilize rather wide used "hits" approach, to provide optimization hints inside SQL query. Otherwise it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL queries. was: There is an issue with JDBC when trying to play with different types of caches using the same JDBC connection. *Example 1 - using simple JDBC connection URL* jdbc:ignite:cfg://file:///my-ignite-client-config.xm 1) For *REPLICATED* caches SQL query like *select * from my_replicated_cache* returns as many duplicates for each record as many nodes in an Ignite cluster. Same problem with *select count(*) from my_replicated_cache* - it returns actual number of records multiplied by the number of Ignite nodes. 2) At the same time if traversing the cache using "for" loop and iterator, it returns exactly what's needed without any duplicates. *Example 2 - specifying replicated or partitioned cache in JDBC connection URL* jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm 1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from my_replicated_cache* return duplicates 2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates for the *select * from my_replicated_cache* query. At the same time it failed to execute simple queries like *select * from my_partitioned_cache* against *PARTITIONED* caches throwing this error: *java.lang.RuntimeException: javax.cache.CacheException: Queries running on replicated cache should not contain JOINs with partitioned tables [rCache=product, pCache=order]* The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* caches in one SQL query (using one JDBC connection) looks not very good. Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL for optimization purposes doesn't look good. It's better to utilize rather wide used "hits" approach, to provide optimization hints inside SQL query. Otherwise it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL queries. > JDBC issue with Replicated & Partitioned caches > --- > > Key: IGNITE-3933 > URL: https://issues.apache.org/jira/browse/IGNITE-3933 > Project: Ignite > Issue Type: Bug > Components: jdbc-driver, odbc, SQL >Affects Versions: 1.8 >Reporter: Igor Rudyak >Priority: Critical > > There is an issue with JDBC when trying to play with different types of > caches using the same JDBC connection. > *Example 1 - using simple JDBC connection URL* > jdbc:ignite:cfg://file:///my-ignite-client-config.xm > 1) For *REPLICATED* caches SQL query like *select \* from > my_replicated_cache* returns as many duplicates for each record as many nodes > in an Ignite cluster. Same problem with *select count(*) from > my_replicated_cache* - it returns actual number of records multiplied by the > number of Ignite nodes. > 2) At the same time if traversing the cache using "for" loop and iterator, it > returns
[jira] [Updated] (IGNITE-3242) JMX MBean for ignite-cassandra module
[ https://issues.apache.org/jira/browse/IGNITE-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-3242: --- Assignee: Eugene Kirin (was: Igor Rudyak) > JMX MBean for ignite-cassandra module > - > > Key: IGNITE-3242 > URL: https://issues.apache.org/jira/browse/IGNITE-3242 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Igor Rudyak >Assignee: Eugene Kirin > > Ignite-Cassandra module should contain JMX MBean, allowing to monitor such > custom metrics (for each Ignite cache and summary): > 1. Size of Cassandra sessions pool > 2. Number of times establishing/closing Cassandra sessions > 3. Number of: > * Records *READ* from Cassandra > * Records *WRITTEN* to Casandra > * Failed *READ* operations > * Failed *WRITE* operations > 4. Min/Max/Average number (and percentage) of attempts to retry failed > *READ/WRITE/DELETE* operation until it succeed > 5. Min/Max/Average/Summary sleep time until failed *READ/WRITE/DELETE* > operation succeed after several attempts > 6. Average time of *READ* operation > 7. Average time of *WRITE* operation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3293) AWS bootstrap scripts patch for Ignite-Cassandra
[ https://issues.apache.org/jira/browse/IGNITE-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-3293: --- Assignee: Igor Rudyak > AWS bootstrap scripts patch for Ignite-Cassandra > - > > Key: IGNITE-3293 > URL: https://issues.apache.org/jira/browse/IGNITE-3293 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6, 1.7 >Reporter: Igor Rudyak >Assignee: Igor Rudyak > Fix For: 1.8 > > Attachments: aws-linux-fail.zip, fail-03-08-cassandra-tests.zip, > logs-aws-linux-1307.zip, logs-aws-linux-fail-1407.zip, > logs-cassandra-ignite.zip, logs-gail-ignite-cass-0208.zip > > > New version of AWS bootstrap script having: > 1) Gaglia monitoring > 2) Allows to manually trigger tests execution multiple times on the same > ifstastructure -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3457) Active Store
[ https://issues.apache.org/jira/browse/IGNITE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15415835#comment-15415835 ] Konstantin Boudnik commented on IGNITE-3457: Just seen this video on Apache Flink's save-pointing [here|https://www.mapr.com/blog/savepoints-apache-flink-stream-processing-whiteboard-walkthrough], which reminded me quite a bit about this feature. > Active Store > > > Key: IGNITE-3457 > URL: https://issues.apache.org/jira/browse/IGNITE-3457 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Alexandre Boudnik >Assignee: Alexandre Boudnik > Attachments: Data Flow.png > > > h2. Purpose > To address missing features, such as backup/restore, snapshot, replication, > and continues export. > h2. How it works > All changes made to data in cache are passed to associated Active Store where > they stored in: > * Transaction Log, which contains the all history of changes made > * Snapshot - the instance of Key-Value store, which contains changes made > since last merge with Main Key-Value store > * Main Key-Value Store, which contains copy of cache's data at the moment > when snapshot has been created > Since cache has been backed by persistent store it should be configured with > *read-through* and *write-through* modes. To represent deleted key the > special constant *NAUGHT* stored as value together with that key. All data in > log, snapshots, and main are used the same serialization. Logs and snapshots > could be shipped to replicate or export data to other clusters or RDBMS > servers. > !Data Flow.png! > h4. New snapshot > At any time a new snapshot can be created and all subsequent changes will be > stored in it. The special record has been made in transaction log. Previous > snapshot stays in read-only mode and its content could be merged into main. > h4. Rollback > To rollback cache to the state when new snapshot was created, all keys in > snapshot should be invalidated in cache. Then snapshot deactivated. > h4. Roll forward > After rolling back the snapshot, all transaction from log could be filtered > and re-executed. > h4. Merge > Either periodically or by explicitly, content of Snapshot merged into Main. > To do so and do not interrupt normal cache operation, Active Store creates a > new snapshot, start storing changes into it, and copies the content of > previous snapshot to the main. After that the previous snapshot could be > either kept or reclaimed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3321) Address possible data corruption in Persistent Store implementations
[ https://issues.apache.org/jira/browse/IGNITE-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15404631#comment-15404631 ] Konstantin Boudnik commented on IGNITE-3321: I thought there was a bug opened for that, no? If not - it sure should be. > Address possible data corruption in Persistent Store implementations > > > Key: IGNITE-3321 > URL: https://issues.apache.org/jira/browse/IGNITE-3321 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.6 > Environment: any >Reporter: Alexandre Boudnik >Assignee: Alexandre Boudnik >Priority: Critical > Original Estimate: 504h > Remaining Estimate: 504h > > When records from partitions on different nodes are committed, each node uses > its own SQL connection. It is possible that one of DML statements will fail > on one of the connections, while others have committed successfully. > And we need to make a very hard decision: > - If we ignore fail then we will lose some changes. > - If we throw an exception we will make inconsistent changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15289494#comment-15289494 ] Konstantin Boudnik commented on IGNITE-1371: [~irudyak], could you please open new tickets for the work, so [~kuaw26] comments are addressed? Thanks everyone for making it happen! > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Fix For: 1.6 > > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15287945#comment-15287945 ] Konstantin Boudnik commented on IGNITE-1371: [~avinogradov] looks like the branch is ready to get merged, as I see it. It is rebased, reviewed and looks like no one is objecting the plan to address the serializer separation in the consequent JIRA. I can merge it in if you're dealing with other priorities. Would be happy to help. > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Fix For: 1.6 > > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284714#comment-15284714 ] Konstantin Boudnik commented on IGNITE-1371: I believe it is a very good idea! But..., I would suggest to have the separation done as a follow up JIRA. This is really an improvement to provide for the pluggable compression modules. Clearly, a feature could be improved endlessly, but in the interest of progressing forward and avoiding bit-rot it would make sense to make smaller, reservable steps. While it won't always be perfect, smaller consequent improvements are superior to a single feature, that accounts for everything at once. So, if current implementation is good, let's get it in and work on the compression separation in the next iteration. [~irudyak], could you please create a new ticket for that? Thanks! > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283844#comment-15283844 ] Konstantin Boudnik commented on IGNITE-1371: Looks lke this JIRA has been silent for almost a month now. And it seems to be waiting a feedback from the reviewer. Would be nice to have it get going through the final steps of the process and get committed to avoid bit-rotting. [~kuaw26], do you mind taking another look to see if all your comments were addressed? > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-899) Add wrapper script to TC automation system
[ https://issues.apache.org/jira/browse/IGNITE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15148671#comment-15148671 ] Konstantin Boudnik commented on IGNITE-899: --- I believe this ticket has to be closed, unless the wrapper is still desired. Any one in charge of TC can comment on it? > Add wrapper script to TC automation system > -- > > Key: IGNITE-899 > URL: https://issues.apache.org/jira/browse/IGNITE-899 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: sprint-4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Attachments: IGNITE-899.patch > > > To improve the UX of patch testing system introduced in IGNITE-620, gradle > wrapper script needs to be added -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2437) Zeppelin interperet doesn't import external dependencies
Konstantin Boudnik created IGNITE-2437:
--
Summary: Zeppelin interperet doesn't import external dependencies
Key: IGNITE-2437
URL: https://issues.apache.org/jira/browse/IGNITE-2437
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.5
Environment: zeppelin 0.5.5
ignite 1.5.0.final
Reporter: Konstantin Boudnik
After configuring Ignite's interpreter for Zeppelin, tried to run the following
{code}
%dep
z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")
%ignite
import io.company._
console>:23: error: object company is not a member of package io
import io.company._
{code}
same code works just fine in spark interpreter though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1181) Comparatively benchmark ordinary Hive vs. Hive over Ignited Hadoop.
[ https://issues.apache.org/jira/browse/IGNITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15092753#comment-15092753 ] Konstantin Boudnik commented on IGNITE-1181: Here's the link to some more micro-benchmarking compating Hive-on-YARN and Hive-on-Ignite http://drcos.boudnik.org/2015/10/lets-speed-up-apache-hive-with-apache.html > Comparatively benchmark ordinary Hive vs. Hive over Ignited Hadoop. > --- > > Key: IGNITE-1181 > URL: https://issues.apache.org/jira/browse/IGNITE-1181 > Project: Ignite > Issue Type: Task > Components: hadoop >Affects Versions: sprint-8 >Reporter: Ivan Veselovsky >Assignee: Ivan Veselovsky > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2318) Let's start providing more robust checksumming meshanism
[ https://issues.apache.org/jira/browse/IGNITE-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik resolved IGNITE-2318. Resolution: Duplicate Oops, missed the other one. > Let's start providing more robust checksumming meshanism > > > Key: IGNITE-2318 > URL: https://issues.apache.org/jira/browse/IGNITE-2318 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.1.4 >Reporter: Konstantin Boudnik > > md5 and sha1 aren't secure and are prone to all sorts of brutal force cracks. > Let's do better with providing some real checksumming for the release > artifacts to guarantee the authenticity of the PMC signed-off releases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1656) Get rid of md5 and sha1 in favor of sha512
[ https://issues.apache.org/jira/browse/IGNITE-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1656: --- Priority: Critical (was: Major) > Get rid of md5 and sha1 in favor of sha512 > -- > > Key: IGNITE-1656 > URL: https://issues.apache.org/jira/browse/IGNITE-1656 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Ivan Veselovsky >Priority: Critical > Fix For: 1.6 > > > Description of the problem wrt sha1 is there: > https://sites.google.com/site/itstheshappening/ . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1656) Get rid of md5 and sha1 in favor of sha512
[
https://issues.apache.org/jira/browse/IGNITE-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15074405#comment-15074405
]
Konstantin Boudnik commented on IGNITE-1656:
md5 and sha1 aren't recommended checksum'ing mechanisms
- https://www.apache.org/dev/release-signing.html#md5-security
- https://www.apache.org/dev/release-signing.html#sha1
The easiest way of solving this is to simply use gpg to calculate all checksums
feasible at once, including sha512
{{gpg --print-mds apache-ignite-src.zip > apache-ignite-src.zip.mds}}
which will produce something like this in case of the 1.5.0 release
{noformat}
apache-ignite-1.5.0.final-src.zip:MD5 = 57 49 4B FB 88 4A C7 36 70 F5 34 D9
E5 44 F1 D5
apache-ignite-1.5.0.final-src.zip: SHA1 = 860C FCD0 3A1C C4D0 8197 22DA D011
7FDC 2CAE 7F30
apache-ignite-1.5.0.final-src.zip: RMD160 = 0B1F BE1B C386 1406 C5F8 0FDA F2F1
EE51 D6DF 174B
apache-ignite-1.5.0.final-src.zip: SHA224 = 3600D9C3 A277CF1D C94ECAE7 CCBAFC47
51BA766F 4733EBC0 DB834074
apache-ignite-1.5.0.final-src.zip: SHA256 = 7E8ED37B 20C80461 81B7CF9A C7E1ABE0
1B6F8D3E BDB00EC6 1B6E9ABF 4440310C
apache-ignite-1.5.0.final-src.zip: SHA384 = 72F54390 F24E06A0 0AB04478 84FA5724
44FF8EE8 DBFDA895 D89E0F5D CC054BB6
38F81465 043B B799B309 16303E6C
apache-ignite-1.5.0.final-src.zip: SHA512 = 1719613A AF34DE7C 6D865201 BCAF5E56
1CFDBDD6 902AA796 3D3E51C6 0FC3CE23
57A9EA8E 8861AB84 71072F81 80BCB2BA
569866EB AF488478 09E5F982 082BC1B9
{noformat}
> Get rid of md5 and sha1 in favor of sha512
> --
>
> Key: IGNITE-1656
> URL: https://issues.apache.org/jira/browse/IGNITE-1656
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
>Priority: Critical
> Fix For: 1.6
>
>
> Description of the problem wrt sha1 is there:
> https://sites.google.com/site/itstheshappening/ .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik closed IGNITE-1555. -- > Combine ignite-hadoop and ignite-spark into signle assembly for downstream > consumption. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: 1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch, > IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1701) Bump Spark dependenency to 1.5.1 (the latest stable)
[
https://issues.apache.org/jira/browse/IGNITE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik closed IGNITE-1701.
--
> Bump Spark dependenency to 1.5.1 (the latest stable)
>
>
> Key: IGNITE-1701
> URL: https://issues.apache.org/jira/browse/IGNITE-1701
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1701.patch
>
>
> At the moment, {{ignite-spark}} module is built against spark 1.3.1 which is
> like 3 versions old already. Let's bump the version to 1.5.1, which is the
> latest stable.
> In the process, I'd like to add an ability to specify the version of Spark
> during the build time, like it is done for Hadoop now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2226) Replace dash in 1.5.0-final with dot 1.5.0.final
[ https://issues.apache.org/jira/browse/IGNITE-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15067700#comment-15067700 ] Konstantin Boudnik commented on IGNITE-2226: Yet another discussion will produce a very different result, I am sure ;) > Replace dash in 1.5.0-final with dot 1.5.0.final > > > Key: IGNITE-2226 > URL: https://issues.apache.org/jira/browse/IGNITE-2226 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Dmitriy Setrakyan >Assignee: Anton Vinogradov >Priority: Blocker > Fix For: 1.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2143) inner join produce wrong result and is very slow
[
https://issues.apache.org/jira/browse/IGNITE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15055115#comment-15055115
]
Konstantin Boudnik commented on IGNITE-2143:
I wonder if this is a performance (and code) regression?
> inner join produce wrong result and is very slow
>
>
> Key: IGNITE-2143
> URL: https://issues.apache.org/jira/browse/IGNITE-2143
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.5
> Environment: 3 nodes in docker containers.
>Reporter: Sergey Soldatov
>Priority: Critical
> Attachments: config.xml, ignite-cache-1.0.0.jar
>
>
> I have following query for gitarchive records processing.
> {code}
> select
> lang, count(distinct ForkTable.repo_url) as cnt
> from (
> select repo_url, lang from gitrecord where type = 'ForkEvent' and
> lang is not null group by lang, repo_url) as ForkTable
> inner join (
> select repo_url, html_url from gitrecord where type='PullRequestEvent'
>
> group by repo_url, html_url) as PullTable
> on
> ForkTable.repo_url = PullTable.repo_url
> group by lang
> order by cnt desc
> {code}
> And there are two major problems:
> 1. It produces an incorrect result if it's running in cluster mode.
> 2. It's really slow. for 200k rows it takes 500+ seconds comparing to 20 on
> Spark for the same query
> Steps to reproduce:
> 1. Download github archive for 1 day and put it to hdfs ("/Data" in my case):
> {code}wget http://data.githubarchive.org/2015-01-01-{0..23}.json.gz{code}
> 2. copy attached ignite-cache-1.0.0.jar to Ignite's lib dir
> 3. run ignite with attached config.xml
> 4. run spark-shell
> {code}
> spark-shell --packages org.apache.ignite:ignite-spark:1.5.0-b1 --repositories
> http://www.gridgainsystems.com/nexus/content/repositories/external --jars
> /usr/lib/ignite-hadoop/libs/ignite-cache-1.0.0.jar --master
> spark://{spark-master}:7077
> {code}
> 5. load data and execute the query:
> {code}
> import org.apache.ignite._
> import org.apache.ignite.configuration._
> import org.apache.ignite.cache.query._
> import org.apache.ignite.spark._
> import org.apache.ignite.lang.IgniteBiPredicate
> import io.dtk._
> val df = sqlContext.read.json("/Data/*.gz")
> Ignition.setClientMode(true)
> val cacheName = "gitrecords"
> val rdd = df.select("id", "repo.url",
> "payload.forkee.language","type","payload.pull_request.head.repo.html_url").map(row
> => (row.getString(0), new GitRecord(0,
> row.getString(1),row.getString(2),row.getString(3),row.getString(4
> val cfg = new
> CacheConfiguration[String,GitRecord]().setName(cacheName).setIndexedTypes(classOf[String],classOf[GitRecord]).setLoadPreviousValue(true)
> val ic = new IgniteContext[String,GitRecord](sc,
> "/usr/lib/ignite-hadoop/config/config.xml")
> val sharedRDD = ic.fromCache(cfg)
> sharedRDD.savePairs(rdd)
> sharedRDD.sql("select lang, count(distinct ForkTable.repo_url) as cnt from
> (select repo_url, lang from gitrecord where type = 'ForkEvent' and lang is
> not null group by lang, repo_url) as ForkTable inner join (select repo_url,
> html_url from gitrecord where type='PullRequestEvent' group by repo_url,
> html_url) as PullTable on ForkTable.repo_url = PullTable.repo_url group by
> lang order by cnt desc").show
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2143) inner join produce wrong result and is very slow
[
https://issues.apache.org/jira/browse/IGNITE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik updated IGNITE-2143:
---
Description:
I have following query for gitarchive records processing.
{code}
select
lang, count(distinct ForkTable.repo_url) as cnt
from (
select repo_url, lang from gitrecord where type = 'ForkEvent' and
lang is not null group by lang, repo_url) as ForkTable
inner join (
select repo_url, html_url from gitrecord where type='PullRequestEvent'
group by repo_url, html_url) as PullTable
on
ForkTable.repo_url = PullTable.repo_url
group by lang
order by cnt desc
{code}
And there are two major problems:
1. It produces an incorrect result if it's running in cluster mode.
2. It's really slow. for 200k rows it takes 500+ seconds comparing to 20 on
Spark for the same query
Steps to reproduce:
1. Download github archive for 1 day and put it to hdfs ("/Data" in my case):
{code}wget http://data.githubarchive.org/2015-01-01-{0..23}.json.gz{code}
2. copy attached ignite-cache-1.0.0.jar to Ignite's lib dir
3. run ignite with attached config.xml
4. run spark-shell
{code}
spark-shell --packages org.apache.ignite:ignite-spark:1.5.0-b1 --repositories
http://www.gridgainsystems.com/nexus/content/repositories/external --jars
/usr/lib/ignite-hadoop/libs/ignite-cache-1.0.0.jar --master
spark://{spark-master}:7077
{code}
5. load data and execute the query:
{code}
import org.apache.ignite._
import org.apache.ignite.configuration._
import org.apache.ignite.cache.query._
import org.apache.ignite.spark._
import org.apache.ignite.lang.IgniteBiPredicate
import io.dtk._
val df = sqlContext.read.json("/Data/*.gz")
Ignition.setClientMode(true)
val cacheName = "gitrecords"
val rdd = df.select("id", "repo.url",
"payload.forkee.language","type","payload.pull_request.head.repo.html_url").map(row
=> (row.getString(0), new GitRecord(0,
row.getString(1),row.getString(2),row.getString(3),row.getString(4
val cfg = new
CacheConfiguration[String,GitRecord]().setName(cacheName).setIndexedTypes(classOf[String],classOf[GitRecord]).setLoadPreviousValue(true)
val ic = new IgniteContext[String,GitRecord](sc,
"/usr/lib/ignite-hadoop/config/config.xml")
val sharedRDD = ic.fromCache(cfg)
sharedRDD.savePairs(rdd)
sharedRDD.sql("select lang, count(distinct ForkTable.repo_url) as cnt from
(select repo_url, lang from gitrecord where type = 'ForkEvent' and lang is not
null group by lang, repo_url) as ForkTable inner join (select repo_url,
html_url from gitrecord where type='PullRequestEvent' group by repo_url,
html_url) as PullTable on ForkTable.repo_url = PullTable.repo_url group by lang
order by cnt desc").show
{code}
was:
I have following query for gitarchive records processing.
{code}
select
lang, count(distinct ForkTable.repo_url) as cnt
from (
select repo_url, lang from gitrecord where type = 'ForkEvent' and
lang is not null group by lang, repo_url) as ForkTable
inner join (
select repo_url, html_url from gitrecord where type='PullRequestEvent'
group by repo_url, html_url) as PullTable
on
ForkTable.repo_url = PullTable.repo_url
group by lang
order by cnt desc
{code}
And there are two major problems:
1. It produces an incorrect result if it's running in cluster mode.
2. It's really slow. for 200k rows it takes 500+ seconds comparing to 20 on
Spark for the same query
Steps to reproduce:
1. Download github archive for 1 day and put it to hdfs ("/Data" in my case):
wget http://data.githubarchive.org/2015-01-01-{0..23}.json.gz
2. copy attached ignite-cache-1.0.0.jar to Ignite's lib dir
3. run ignite with attached config.xml
4. run spark-shell
{code}
spark-shell --packages org.apache.ignite:ignite-spark:1.5.0-b1 --repositories
http://www.gridgainsystems.com/nexus/content/repositories/external --jars
/usr/lib/ignite-hadoop/libs/ignite-cache-1.0.0.jar --master
spark://{spark-master}:7077
{code}
5. load data and execute the query:
{code}
import org.apache.ignite._
import org.apache.ignite.configuration._
import org.apache.ignite.cache.query._
import org.apache.ignite.spark._
import org.apache.ignite.lang.IgniteBiPredicate
import io.dtk._
val df = sqlContext.read.json("/Data/*.gz")
Ignition.setClientMode(true)
val cacheName = "gitrecords"
val rdd = df.select("id", "repo.url",
"payload.forkee.language","type","payload.pull_request.head.repo.html_url").map(row
=> (row.getString(0), new GitRecord(0,
row.getString(1),row.getString(2),row.getString(3),row.getString(4
val cfg = new
CacheConfiguration[String,GitRecord]().setName(cacheName).setIndexedTypes(classOf[String],classOf[GitRecord]).setLoadPreviousValue(true)
val ic = new IgniteContext[String,GitRecord](sc,
"/usr/lib/ignite-hadoop/config/config.xml")
val sharedRDD = ic.fromCache(cfg)
sharedRDD.savePairs(rdd)
sharedRDD.sql("select lang, count(distinct ForkTable.repo_url) as
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15055112#comment-15055112 ] Konstantin Boudnik commented on IGNITE-1371: I haven't looked into the patch yet, but is embedded Cassandra test is the only way to test new functionality? Because if there are other test coverage in there, embedding Cassandra could be done as a separate ticket. > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- 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=15051412#comment-15051412
]
Konstantin Boudnik commented on IGNITE-389:
---
I see the ticket is moved to 1.6. I will repeat the earlier question: would
community consider splitting the Python stuff into a separate new feature and
close this? IgniteRDD is there for 3 consequent releases, yet the ticket is
open.
> 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-2094) building the project with 'install' crashes on Mesos module
[
https://issues.apache.org/jira/browse/IGNITE-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15049676#comment-15049676
]
Konstantin Boudnik commented on IGNITE-2094:
I have exactly the same result on the clean m2. Which is actually irrelevant,
because the failure happens _before_ it gets to the point of installing
anything.
I know from another user, that the build fails similarly on different modules
sometimes.
It seems though, that's the problem is in the combination of {{package
install}} targets. If either is specified alone - everything works fine. Two
together is not go. That evidently a build issue, but is a minor one, because I
can simply skip {{package}} part and be done with it. Please feel free to close
the ticket as "Won't Fix" if no one feels like working on it ;) Thanks!
> building the project with 'install' crashes on Mesos module
> ---
>
> Key: IGNITE-2094
> URL: https://issues.apache.org/jira/browse/IGNITE-2094
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.5
>Reporter: Konstantin Boudnik
>Assignee: Anton Vinogradov
> Fix For: 1.5
>
>
> Attempting to do {{mvn install...}} on the latest {{-b1}} release and the
> build crashed on the Mesos module.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2094) building the project with 'install' crashes on Mesos module
Konstantin Boudnik created IGNITE-2094:
--
Summary: building the project with 'install' crashes on Mesos
module
Key: IGNITE-2094
URL: https://issues.apache.org/jira/browse/IGNITE-2094
Project: Ignite
Issue Type: Bug
Components: build
Affects Versions: 1.5
Reporter: Konstantin Boudnik
Attempting to do {{mvn install...}} on the latest {{-b1}} release and the build
crashed on the Mesos module.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1195) Released Ignite version 1.3.0 does not build with -Dhadoop.version=2.6.0
[ https://issues.apache.org/jira/browse/IGNITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030331#comment-15030331 ] Konstantin Boudnik commented on IGNITE-1195: Sorry, what do you mean it is fixed? Was committed anywhere or you can not reproduce it anymore? Also, are you trying to build Ignite 1.3 with the latest versions of Hadoop? Sorry, I am confused about this, because I don't see this issue with Ignite 1.4 nor 1.5 branch head... > Released Ignite version 1.3.0 does not build with -Dhadoop.version=2.6.0 > > > Key: IGNITE-1195 > URL: https://issues.apache.org/jira/browse/IGNITE-1195 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Veselovsky >Assignee: Nikolay Tikhonov > Fix For: 1.5 > > Attachments: ignite-1195.patch > > > Released version 1.3.0 > (http://archive.apache.org/dist/incubator/ignite/1.3.0//apache-ignite-1.3.0-incubating-src.zip, > > http://apache.osuosl.org/incubator/ignite/1.3.0//apache-ignite-1.3.0-incubating-src.zip) > does not build with argument > -Dhadoop.version=2.6.0 ( mvn clean package -DskipTests > -Dhadoop.version=2.6.0 -Dignite.edition=hadoop), > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /tmp/apache-ignite-1.3.0-incubating-src/modules/yarn/src/test/java/org/apache/ignite/yarn/IgniteApplicationMasterSelfTest.java:[368,9] > method does not override or implement a method from a supertype > [INFO] 1 error > [INFO] - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1195) Released Ignite version 1.3.0 does not build with -Dhadoop.version=2.6.0
[ https://issues.apache.org/jira/browse/IGNITE-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15025180#comment-15025180 ] Konstantin Boudnik commented on IGNITE-1195: Could you please share any error message or something? I've been building Ignite 1.5 RC with Hadoop 2.7.1 for some time now _without_ a glitch. > Released Ignite version 1.3.0 does not build with -Dhadoop.version=2.6.0 > > > Key: IGNITE-1195 > URL: https://issues.apache.org/jira/browse/IGNITE-1195 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Veselovsky >Assignee: Nikolay Tikhonov > Fix For: 1.5 > > Attachments: ignite-1195.patch > > > Released version 1.3.0 > (http://archive.apache.org/dist/incubator/ignite/1.3.0//apache-ignite-1.3.0-incubating-src.zip, > > http://apache.osuosl.org/incubator/ignite/1.3.0//apache-ignite-1.3.0-incubating-src.zip) > does not build with argument > -Dhadoop.version=2.6.0 ( mvn clean package -DskipTests > -Dhadoop.version=2.6.0 -Dignite.edition=hadoop), > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > /tmp/apache-ignite-1.3.0-incubating-src/modules/yarn/src/test/java/org/apache/ignite/yarn/IgniteApplicationMasterSelfTest.java:[368,9] > method does not override or implement a method from a supertype > [INFO] 1 error > [INFO] - -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1823) Peer class loading can produce ClassCastException with DeploymentMode.SHARED (default)
[
https://issues.apache.org/jira/browse/IGNITE-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik updated IGNITE-1823:
---
Affects Version/s: 1.5
ignite-1.4
> Peer class loading can produce ClassCastException with DeploymentMode.SHARED
> (default)
> --
>
> Key: IGNITE-1823
> URL: https://issues.apache.org/jira/browse/IGNITE-1823
> Project: Ignite
> Issue Type: Bug
> Components: 1.4
>Affects Versions: ignite-1.4, 1.5
>Reporter: Artem Shutak
> Attachments: client-run-1.log, client-run-2.log, server.log
>
>
> Peer class loading can produce ClassCastException with DeploymentMode.SHARED
> (default).
> Steps to reproduce (tested with 1.4 and 1.5-SNAPSHOT).
> - Build Ignite under java 7.
> - Run ignite.sh with default configuration and enabled peer class loading
> under Java 8
> - Run Test class under java8
> - Run Test class under java8 again. On second run you will get
> ClassCastException.
> Looks like the issue is Ignite use different classloaders for first and
> second run of Test (Task class deployed and undeployed each time).
> Workarounds:
> - Use another DeploymentMode. For example in this case Ignite works fine with
> CONTINUOUS deployment mode.
> - Don't use peer class loading and add jars with custom tasks to classpath of
> server nodes.
> Exception:
> {noformat}
> [19:56:03,013][SEVERE][ignite-#18%sys-null%][GridTaskWorker] Failed to obtain
> remote job result policy for result from ComputeTask.result(..) method (will
> fail the whole task): GridJobResultImpl [job=C2 [], sib=GridJobSiblingImpl
> [sesId=37a6da9b051-7d576228-e0e4-492c-a325-35ce4fc40ea0,
> jobId=47a6da9b051-cadb35ba-9bc8-4f05-b9ce-03344883743f,
> nodeId=cadb35ba-9bc8-4f05-b9ce-03344883743f, isJobDone=false],
> jobCtx=GridJobContextImpl
> [jobId=47a6da9b051-cadb35ba-9bc8-4f05-b9ce-03344883743f, timeoutObj=null,
> attrs={}], node=TcpDiscoveryNode [id=cadb35ba-9bc8-4f05-b9ce-03344883743f,
> addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 192.168.1.159],
> sockAddrs=[/192.168.1.159:47500, /0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500,
> /192.168.1.159:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1446224162137, loc=false, ver=1.5.0#20151029-sha1:91059ba8,
> isClient=false], ex=class o.a.i.IgniteException: mypackage.Task cannot be
> cast to mypackage.Task, hasRes=true, isCancelled=false, isOccupied=true]
> class org.apache.ignite.IgniteException: Remote job threw user exception
> (override or implement ComputeTask.result(..) method if you would like to
> have automatic failover for this exception).
> at
> org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:101)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker$3.apply(GridTaskWorker.java:903)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker$3.apply(GridTaskWorker.java:896)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6403)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:896)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:792)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:995)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: mypackage.Task cannot be
> cast to mypackage.Task
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1792)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6371)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:503)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:456)
> at
>
[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=14995102#comment-14995102
]
Konstantin Boudnik commented on IGNITE-389:
---
Any input on this?
> 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.5
>
>
> 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-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983078#comment-14983078 ] Konstantin Boudnik commented on IGNITE-1371: Yup, good point. Integration tests are tricky and shouldn't be unleashed without a good contemplation about the consequences. > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Dmitriy Setrakyan > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14968126#comment-14968126 ] Konstantin Boudnik commented on IGNITE-1371: bq. Ignite use JUnit3 in all tests Wow, it's like 1998 all over again. Shall we switch to JUnit4 (dependency wise, backward compatible with JUnit3) and start writing new tests in JUnit4 instead? Sticking to v3 seems a bit weird, honestly > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14959745#comment-14959745 ] Konstantin Boudnik commented on IGNITE-1555: I see a few [test failures|http://204.14.53.153/viewModification.html?modId=20692=false==vcsModificationTests] on that commit, but they are clearly unrelated to the change at hands. > Combine ignite-hadoop and ignite-spark into signle assembly for downstream > consumption. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: 1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch, > IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1701) Bump Spark dependenency to 1.5.1 (the latest stable)
Konstantin Boudnik created IGNITE-1701:
--
Summary: Bump Spark dependenency to 1.5.1 (the latest stable)
Key: IGNITE-1701
URL: https://issues.apache.org/jira/browse/IGNITE-1701
Project: Ignite
Issue Type: Improvement
Components: build
Affects Versions: ignite-1.4
Reporter: Konstantin Boudnik
Assignee: Konstantin Boudnik
Fix For: 1.5
At the moment, {{ignite-spark}} module is built against spark 1.3.1 which is
like 3 versions old already. Let's bump the version to 1.5.1, which is the
latest stable.
In the process, I'd like to add an ability to specify the version of Spark
during the build time, like it is done for Hadoop now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1701) Bump Spark dependenency to 1.5.1 (the latest stable)
[
https://issues.apache.org/jira/browse/IGNITE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik updated IGNITE-1701:
---
Attachment: IGNITE-1701.patch
Will start the usual CI chores shortly.
> Bump Spark dependenency to 1.5.1 (the latest stable)
>
>
> Key: IGNITE-1701
> URL: https://issues.apache.org/jira/browse/IGNITE-1701
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1701.patch
>
>
> At the moment, {{ignite-spark}} module is built against spark 1.3.1 which is
> like 3 versions old already. Let's bump the version to 1.5.1, which is the
> latest stable.
> In the process, I'd like to add an ability to specify the version of Spark
> during the build time, like it is done for Hadoop now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1371: --- Assignee: Igor Rudyak (was: Alexandre Boudnik) > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[
https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955725#comment-14955725
]
Konstantin Boudnik commented on IGNITE-1371:
[~irudyak], please take a look at
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Home which
will help you to find all the details about the development and contribution
process to the project. It might be a little bit dry and a bit too complex at
places, so please do not hesitate to subscribe to {{d...@ignite.apache.org}}
and ask questions. Thanks!
> Key-Value store (like Cassandra) as CacheStore
> --
>
> Key: IGNITE-1371
> URL: https://issues.apache.org/jira/browse/IGNITE-1371
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexandre Boudnik
>Assignee: Alexandre Boudnik
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> It will provide ability to map particular cache holding POJOs to Cassandra
> table. Later it would be generalized to support eventually any any Key-Value
> store.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1656) Get rid of md5 and sha1 in favor of sha512
[
https://issues.apache.org/jira/browse/IGNITE-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14953476#comment-14953476
]
Konstantin Boudnik commented on IGNITE-1656:
There's a simple way to deal with it once and for all (this is the HBase,
Hadoop approach). For all release artifacts you can run something like this:
{{for i in *.tar.gz; do echo $i; gpg --print-mds $i > $i.mds ; done}}
gpg produces a set of checksums, including all available SHA's and some others.
What's important is that gpg behaves the same way on all platforms, so
verification format issues will be non-existent.
> Get rid of md5 and sha1 in favor of sha512
> --
>
> Key: IGNITE-1656
> URL: https://issues.apache.org/jira/browse/IGNITE-1656
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Ivan Veselovsky
> Fix For: 1.5
>
>
> Description of the problem wrt sha1 is there:
> https://sites.google.com/site/itstheshappening/ .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14953555#comment-14953555 ] Konstantin Boudnik commented on IGNITE-1555: Honestly, for last 3 weeks I was trying to see the importance of the name and I failed. I personally don't envision anyone using a raw assembly being used to install on a cluster for filesystem caching or else. The assembly is going to be consumed by downstream projects in an automated fashion. And in such case name is a negligent matter. At any rate, here's the latest version of the patch which preserve the name and includes spark integration module into the binary assembly. I will commit this by the morrow unless I hear any objections on the approach. Thanks! > Combine ignite-hadoop and ignite-spark into signle assembly for downstream > consumption. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: 1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch, > IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1555: --- Attachment: IGNITE-1555.patch > Combine ignite-hadoop and ignite-spark into signle assembly for downstream > consumption. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: 1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch, > IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly.
[
https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951536#comment-14951536
]
Konstantin Boudnik commented on IGNITE-1555:
Here's an idea: these assemblies are mostly for the downstream consumption,
like Bigtop, etc. Let's call them {{ignite-integration}} and later on will be
adding other ecosystem adapters and plugins for things like Flink, etc. Does it
make sense?
> Combine ignite-hadoop and ignite-spark into signle ignite-accelerator
> assembly.
> ---
>
> Key: IGNITE-1555
> URL: https://issues.apache.org/jira/browse/IGNITE-1555
> Project: Ignite
> Issue Type: New Feature
> Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1555.patch, IGNITE-1555.patch
>
>
> Let's combine all nice things that Ignite provides for Hadoop and Spark into
> single assembly called ignite-accelerator. This will be advantageous for
> downstream integrators like Bigtop, where all bits can be packaged together,
> tested, and deployed with proper configurations and permissions to avoid
> interoperability issues. A typical is when spark-shell starts an Ignite node
> which crashes because user 'spark' isn't allowed to write into Ignite's
> work-dir, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1555: --- Summary: Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption. (was: Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly.) > Combine ignite-hadoop and ignite-spark into signle assembly for downstream > consumption. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: 1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1555: --- Attachment: IGNITE-1555.patch > Combine ignite-hadoop and ignite-spark into signle assembly for downstream > consumption. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: 1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[
https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Boudnik updated IGNITE-1555:
---
Attachment: IGNITE-1555.patch
Latest patch for the {{integration}} edition
> Combine ignite-hadoop and ignite-spark into signle assembly for downstream
> consumption.
> ---
>
> Key: IGNITE-1555
> URL: https://issues.apache.org/jira/browse/IGNITE-1555
> Project: Ignite
> Issue Type: New Feature
> Components: hadoop
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch
>
>
> Let's combine all nice things that Ignite provides for Hadoop and Spark into
> single assembly called ignite-accelerator. This will be advantageous for
> downstream integrators like Bigtop, where all bits can be packaged together,
> tested, and deployed with proper configurations and permissions to avoid
> interoperability issues. A typical is when spark-shell starts an Ignite node
> which crashes because user 'spark' isn't allowed to write into Ignite's
> work-dir, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle assembly for downstream consumption.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1555: --- Attachment: (was: IGNITE-1555.patch) > Combine ignite-hadoop and ignite-spark into signle assembly for downstream > consumption. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: 1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch, IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-495) REST API testing: nothing to do
[ https://issues.apache.org/jira/browse/IGNITE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik resolved IGNITE-495. --- Resolution: Won't Fix closing this test JIRA > REST API testing: nothing to do > --- > > Key: IGNITE-495 > URL: https://issues.apache.org/jira/browse/IGNITE-495 > Project: Ignite > Issue Type: Wish > Components: general >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik >Priority: Trivial > > This is a ticket created to do some CI functionality testing. > DO NOT ASSIGN to sprints. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14947145#comment-14947145 ] Konstantin Boudnik commented on IGNITE-1555: So, what do you suggest? > Combine ignite-hadoop and ignite-spark into signle ignite-accelerator > assembly. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: ignite-1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly.
Konstantin Boudnik created IGNITE-1555: -- Summary: Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly. Key: IGNITE-1555 URL: https://issues.apache.org/jira/browse/IGNITE-1555 Project: Ignite Issue Type: New Feature Components: hadoop Affects Versions: ignite-1.4 Reporter: Konstantin Boudnik Fix For: ignite-1.5 Let's combine all nice things that Ignite provides for Hadoop and Spark into single assembly called ignite-accelerator. This will be advantageous for downstream integrators like Bigtop, where all bits can be packaged together, tested, and deployed with proper configurations and permissions to avoid interoperability issues. A typical is when spark-shell starts an Ignite node which crashes because user 'spark' isn't allowed to write into Ignite's work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik reassigned IGNITE-1555: -- Assignee: Konstantin Boudnik > Combine ignite-hadoop and ignite-spark into signle ignite-accelerator > assembly. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik >Assignee: Konstantin Boudnik > Fix For: ignite-1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1555) Combine ignite-hadoop and ignite-spark into signle ignite-accelerator assembly.
[ https://issues.apache.org/jira/browse/IGNITE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Boudnik updated IGNITE-1555: --- Attachment: IGNITE-1555.patch Also, updated the top-level README file > Combine ignite-hadoop and ignite-spark into signle ignite-accelerator > assembly. > --- > > Key: IGNITE-1555 > URL: https://issues.apache.org/jira/browse/IGNITE-1555 > Project: Ignite > Issue Type: New Feature > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Konstantin Boudnik > Fix For: ignite-1.5 > > Attachments: IGNITE-1555.patch, IGNITE-1555.patch > > > Let's combine all nice things that Ignite provides for Hadoop and Spark into > single assembly called ignite-accelerator. This will be advantageous for > downstream integrators like Bigtop, where all bits can be packaged together, > tested, and deployed with proper configurations and permissions to avoid > interoperability issues. A typical is when spark-shell starts an Ignite node > which crashes because user 'spark' isn't allowed to write into Ignite's > work-dir, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1181) Comparatively benchmark ordinary Hive vs. Hive over Ignited Hadoop.
[
https://issues.apache.org/jira/browse/IGNITE-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14901596#comment-14901596
]
Konstantin Boudnik commented on IGNITE-1181:
I just did some quite and dirty benchmarking using a simple data sample and
running a query, producing a couple of map-reduce jobs, ie
{code}
select count(*) from batting where year > 1909 and year < 1998;
{code}
What I see is 5x performance improvement compare to the case of Hive over YARN.
> Comparatively benchmark ordinary Hive vs. Hive over Ignited Hadoop.
> ---
>
> Key: IGNITE-1181
> URL: https://issues.apache.org/jira/browse/IGNITE-1181
> Project: Ignite
> Issue Type: Task
> Components: hadoop
>Affects Versions: sprint-8
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: ignite-1.6
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
