[jira] [Commented] (IGNITE-1290) Build Failure with java version "1.8.0_40"
[
https://issues.apache.org/jira/browse/IGNITE-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709068#comment-14709068
]
Gianfranco Murador commented on IGNITE-1290:
It's a problem of ambiguity in imports. We can refers to this ticket:
https://issues.apache.org/jira/browse/IGNITE-1253. It's possible fix the
problem adding org.h2.expression.Parameter in GridSqlQueryParser.java import
section.
> Build Failure with java version "1.8.0_40"
> --
>
> Key: IGNITE-1290
> URL: https://issues.apache.org/jira/browse/IGNITE-1290
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Environment: 1: mac os
> 2: java
> java version "1.8.0_40"
> Java(TM) SE Runtime Environment (build 1.8.0_40-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
> 3: master branch
>Reporter: kcheng.mvp
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
> on project ignite-indexing: Compilation failure: Compilation failure:
> [ERROR]
> /Users/kcheng/sandbox/ignite/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sql/GridSqlQueryParser.java:[567,35]
> reference to Parameter is ambiguous
> [ERROR] both class java.lang.reflect.Parameter in java.lang.reflect and class
> org.h2.expression.Parameter in org.h2.expression match
> [ERROR]
> /Users/kcheng/sandbox/ignite/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sql/GridSqlQueryParser.java:[568,43]
> reference to Parameter is ambiguous
> [ERROR] both class java.lang.reflect.Parameter in java.lang.reflect and class
> org.h2.expression.Parameter in org.h2.expression match
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :ignite-indexing
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1290) Build Failure with java version "1.8.0_40"
[
https://issues.apache.org/jira/browse/IGNITE-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709068#comment-14709068
]
Gianfranco Murador edited comment on IGNITE-1290 at 8/24/15 10:36 AM:
--
It's a problem of ambiguity in imports. We can refer to this ticket:
https://issues.apache.org/jira/browse/IGNITE-1253. It's possible fix the
problem adding org.h2.expression.Parameter in GridSqlQueryParser.java import
section.
was (Author: glutters):
It's a problem of ambiguity in imports. We can refers to this ticket:
https://issues.apache.org/jira/browse/IGNITE-1253. It's possible fix the
problem adding org.h2.expression.Parameter in GridSqlQueryParser.java import
section.
> Build Failure with java version "1.8.0_40"
> --
>
> Key: IGNITE-1290
> URL: https://issues.apache.org/jira/browse/IGNITE-1290
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Environment: 1: mac os
> 2: java
> java version "1.8.0_40"
> Java(TM) SE Runtime Environment (build 1.8.0_40-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
> 3: master branch
>Reporter: kcheng.mvp
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
> on project ignite-indexing: Compilation failure: Compilation failure:
> [ERROR]
> /Users/kcheng/sandbox/ignite/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sql/GridSqlQueryParser.java:[567,35]
> reference to Parameter is ambiguous
> [ERROR] both class java.lang.reflect.Parameter in java.lang.reflect and class
> org.h2.expression.Parameter in org.h2.expression match
> [ERROR]
> /Users/kcheng/sandbox/ignite/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sql/GridSqlQueryParser.java:[568,43]
> reference to Parameter is ambiguous
> [ERROR] both class java.lang.reflect.Parameter in java.lang.reflect and class
> org.h2.expression.Parameter in org.h2.expression match
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :ignite-indexing
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715249#comment-14715249
]
Gianfranco Murador commented on IGNITE-429:
---
For the testing phase of an ETL subsystem , I need to know if there are updates
about the patch. Chandresh Please, can you give us some update? I can show you
an implementation that I'm doing about this topic. Let me know if you need
help, Thank you very much.
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1253) The indexing module breaks the build
[ https://issues.apache.org/jira/browse/IGNITE-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianfranco Murador closed IGNITE-1253. -- > The indexing module breaks the build > - > > Key: IGNITE-1253 > URL: https://issues.apache.org/jira/browse/IGNITE-1253 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.1.4 >Reporter: Gianfranco Murador >Assignee: Sergi Vladykin > Attachments: Screen Shot 2015-08-31 at 2.18.27 PM.png > > > ./incubator-ignite/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sql/GridSqlQueryParser.java:[568,43] > reference to Parameter is ambiguous. both class java.lang.reflect.Parameter > in java.lang.reflect and class org.h2.expression.Parameter in > org.h2.expression match -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742498#comment-14742498 ] Gianfranco Murador commented on IGNITE-708: --- >From what I could see, the refresh partition in case of timeout is >redundant, since each node has a refresh partition which runs at regular >intervals in the method body() of GridCachePartitionExchangeManager retrieved >from the background process ExchangeWorker. Thus eliminating the >refreshPartition event in class ResendTimeoutObject should not have any impact >on the operation, but an increase in performance in when we avoid sending >redundant message. I will proceed with the creation of a pull request. > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745419#comment-14745419
]
Gianfranco Murador commented on IGNITE-429:
---
Hi Chandresh,
I will commit my solution on my fork by this weekend , so you can verify the
two solutions.
Thank you for your contribution
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14877205#comment-14877205
]
Gianfranco Murador commented on IGNITE-429:
---
Hi Chandresh, Tomorrow, I will finish some implementations. Keep in mind some
test cases to be created on your own. https://github.com/murador/ignite
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14877480#comment-14877480
]
Gianfranco Murador commented on IGNITE-429:
---
Hello Chandresh,
how do you see the implementation is simple ( this is good ), but It does not
take into account of some aspects that may not work in Ignite. As we have done
in Kafka streamer is a good idea to create an ExecutorService to submit streams
from apache storm (This improves performance) . You have to rely to a naming
convention that must be declared with your solution, while it might be a good
idea to create our bolt to filter results. I will make a new branch with all
the changes, so you can make a new pull request. Still I am not very skilled
with git :).
Regards, Gianfranco
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14877480#comment-14877480
]
Gianfranco Murador edited comment on IGNITE-429 at 9/20/15 11:51 AM:
-
Hello Chandresh,
the implementation is simple ( this is good ), but It does not take into
account of some aspects that may not work in Ignite. As we have done in Kafka
streamer is a good idea to create an ExecutorService to submit streams from
apache storm (This improves performance) . You have to rely to a naming
convention that must be declared with your solution, while it might be a good
idea to create our bolt to filter results. I will make a new branch with all
the changes, so you can make a new pull request. Still I am not very skilled
with git :).
Regards, Gianfranco
was (Author: glutters):
Hello Chandresh,
how do you see the implementation is simple ( this is good ), but It does not
take into account of some aspects that may not work in Ignite. As we have done
in Kafka streamer is a good idea to create an ExecutorService to submit streams
from apache storm (This improves performance) . You have to rely to a naming
convention that must be declared with your solution, while it might be a good
idea to create our bolt to filter results. I will make a new branch with all
the changes, so you can make a new pull request. Still I am not very skilled
with git :).
Regards, Gianfranco
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14899944#comment-14899944
]
Gianfranco Murador commented on IGNITE-429:
---
Hi Chandresh,
please, look here
https://github.com/murador/ignite/tree/IGNITE-429/modules/storm/src. Now, We
need to create unit test.Let me know if you find problems with the proposed
solution .
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909691#comment-14909691
]
Gianfranco Murador commented on IGNITE-429:
---
The test was successful with the latest changes . The operation of the stream
is different compared to the one described in the guidelines because the
integration is via a Storm Bolt . I ask Chandresh provide documentation about
so that we can include in wiki .
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909691#comment-14909691
]
Gianfranco Murador edited comment on IGNITE-429 at 9/27/15 12:53 PM:
-
The test was successful with the latest changes . The operation of the stream
is different compared to the one described in the guidelines because the
integration is via a Storm Bolt . I ask to Chandresh to provide a simple
documentation about this topic so that we can include it in official dev wiki .
was (Author: glutters):
The test was successful with the latest changes . The operation of the stream
is different compared to the one described in the guidelines because the
integration is via a Storm Bolt . I ask Chandresh provide documentation about
so that we can include in wiki .
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909691#comment-14909691
]
Gianfranco Murador edited comment on IGNITE-429 at 9/27/15 2:19 PM:
The test was successful with the latest changes . The operation of the stream
is different compared to the one described in the guidelines because the
integration is via a Storm Bolt . I'd like to ask to Chandresh to provide a
simple documentation about this topic so that we can include it in official dev
wiki .
was (Author: glutters):
The test was successful with the latest changes . The operation of the stream
is different compared to the one described in the guidelines because the
integration is via a Storm Bolt . I ask to Chandresh to provide a simple
documentation about this topic so that we can include it in official dev wiki .
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-975) Peer deployment does not work for distributed services
[
https://issues.apache.org/jira/browse/IGNITE-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianfranco Murador reassigned IGNITE-975:
-
Assignee: Gianfranco Murador
> Peer deployment does not work for distributed services
> --
>
> Key: IGNITE-975
> URL: https://issues.apache.org/jira/browse/IGNITE-975
> Project: Ignite
> Issue Type: Bug
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>
> it seems that peer-deployment meta is not properly sent for utility cache.
> To reproduce start node with {{main(String[])}} method from module others
> than {{examples}} and run {{ServicesExample}}.
> Node output:
> {noformat}
> [13:43:41]__
> [13:43:41] / _/ ___/ |/ / _/_ __/ __/
> [13:43:41] _/ // (7 7// / / / / _/
> [13:43:41] /___/\___/_/|_/___/ /_/ /___/
> [13:43:41]
> [13:43:41] ver. 1.0.7-SNAPSHOT#19700101-sha1:DEV
> [13:43:41] 2015 Copyright(C) Apache Software Foundation
> [13:43:41]
> [13:43:41] Quiet mode.
> [13:43:41] ^-- Logging to file
> '/Users/yzhdanov/projects/incubator-ignite/work/log/ignite-cb8d4626.0.log'
> [13:43:41] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.{sh|bat}
> [13:43:41]
> [13:43:41] Initial heap size is 256MB (should be no less than 512MB, use
> -Xms512m -Xmx512m).
> [13:43:41] Configured plugins:
> [13:43:41] ^-- None
> [13:43:41]
> [13:43:43] Performance suggestions for grid (fix if possible)
> [13:43:43] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [13:43:43] ^-- Disable peer class loading (set 'peerClassLoadingEnabled' to
> false)
> [13:43:43]
> [13:43:43] To start Console Management & Monitoring run
> ignitevisorcmd.{sh|bat}
> [13:43:43]
> [13:43:43] Ignite node started OK (id=cb8d4626)
> [13:43:43] Topology snapshot [ver=1, nodes=1, CPUs=8, heap=3.6GB]
> [13:43:51] New version is available at ignite.incubator.apache.org: 1.1.0
> [13:44:02] Topology snapshot [ver=2, nodes=2, CPUs=8, heap=7.1GB]
> [13:44:03,512][SEVERE][ignite-#73%utility-null%][GridDhtTxLocal] Heuristic
> transaction failure.
> class
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
> Failed to locally write to cache (all transaction entries will be
> invalidated, however there was a window when entries for this transaction
> were visible to others): GridNearTxLocal [nearLocallyMapped=false,
> colocatedLocallyMapped=true, mappings=[cb8d4626-14c8-4b01-af80-861e45c824f3],
> super=GridDhtTxLocalAdapter [mapped=true, dhtThreadId=95,
> needsCompletedVers=true, nearNodes=[],
> dhtNodes=[afd28cea-8fed-4b90-8b81-cfad048c502a], explicitLock=false,
> super=IgniteTxLocalAdapter [txMap={IgniteTxKey [key=KeyCacheObjectImpl
> [val=GridServiceAssignmentsKey [name=myClusterSingletonService],
> hasValBytes=true], cacheId=-2100569601]=IgniteTxEntry [key=KeyCacheObjectImpl
> [val=GridServiceAssignmentsKey [name=myClusterSingletonService],
> hasValBytes=true], cacheId=-2100569601, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [val=GridServiceAssignmentsKey
> [name=myClusterSingletonService], hasValBytes=true], cacheId=-2100569601],
> val=[op=CREATE, val=UserCacheObjectImpl [val=GridServiceAssignments
> [nodeId=afd28cea-8fed-4b90-8b81-cfad048c502a, topVer=2,
> cfg=ServiceConfiguration [name=myClusterSingletonService, totalCnt=1,
> maxPerNodeCnt=1, cacheName=null, svcCls=SimpleMapServiceImpl,
> nodeFilterCls=AttributeFilter],
> assigns={cb8d4626-14c8-4b01-af80-861e45c824f3=1}], hasValBytes=true]],
> prevVal=[op=CREATE, val=UserCacheObjectImpl [val=GridServiceAssignments
> [nodeId=afd28cea-8fed-4b90-8b81-cfad048c502a, topVer=2,
> cfg=ServiceConfiguration [name=myClusterSingletonService, totalCnt=1,
> maxPerNodeCnt=1, cacheName=null, svcCls=SimpleMapServiceImpl,
> nodeFilterCls=AttributeFilter],
> assigns={cb8d4626-14c8-4b01-af80-861e45c824f3=1}], hasValBytes=true]],
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
> explicitVer=null, dhtVer=GridCacheVersion [topVer=44718225, nodeOrderDrId=1,
> globalTime=1433238243492, order=1433238242461], filters=[],
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=28,
> mapPubSize=0, rmvQueue=GridCircularBuffer [sizeMask=127, idxGen=0],
> state=OWNING, reservations=0, empty=false, createTime=06/02/2015 13:43:43,
> mapPubSize=0], super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [val=GridServiceAssignmentsKey
> [name=myClusterSingletonService], hasValBytes=true], val=null,
> startVer=1433238242460, ver=GridCacheVersion [topVer=44718225,
> nodeOrderDrId=1, globalTime=1433238243478, order=1433238242460],
> hash=212792313, extras=GridCacheMvccEntryExtra
[jira] [Assigned] (IGNITE-888) Web interface to monitoring cluster state.
[ https://issues.apache.org/jira/browse/IGNITE-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianfranco Murador reassigned IGNITE-888: - Assignee: Gianfranco Murador (was: Sergey Evdokimov) > Web interface to monitoring cluster state. > -- > > Key: IGNITE-888 > URL: https://issues.apache.org/jira/browse/IGNITE-888 > Project: Ignite > Issue Type: Task >Reporter: Sergey Evdokimov >Assignee: Gianfranco Murador > > Ignite node should start Jetty server with small web application to > monitoring node state. > Web application should has at least 3 pages: > 1.) Node information: hardware configuration, metrics, node attributes > 2.) Cluster state: list of available nodes. > 3.) Caches: list of caches, SQL console, object browser. > Web application should be packed as Ignite plugin to avoid reference to jetty > from Ignite core. > Technologies: > - JSP, JSTL, sitemesh > - Bootstrap, Google Charts -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-417) removeAll() throws IllegalStateException if remote node stops during removeAll() execution
[ https://issues.apache.org/jira/browse/IGNITE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianfranco Murador reassigned IGNITE-417: - Assignee: Gianfranco Murador (was: Sergey Evdokimov) > removeAll() throws IllegalStateException if remote node stops during > removeAll() execution > -- > > Key: IGNITE-417 > URL: https://issues.apache.org/jira/browse/IGNITE-417 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Evdokimov >Assignee: Gianfranco Murador > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-888) Web interface to monitoring cluster state.
[ https://issues.apache.org/jira/browse/IGNITE-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936871#comment-14936871 ] Gianfranco Murador commented on IGNITE-888: --- Sergey, I'd like to ask you if this issue is open yet, or It has been resolved in previous release. Thank you, Gianfranco > Web interface to monitoring cluster state. > -- > > Key: IGNITE-888 > URL: https://issues.apache.org/jira/browse/IGNITE-888 > Project: Ignite > Issue Type: Task >Reporter: Sergey Evdokimov >Assignee: Gianfranco Murador > > Ignite node should start Jetty server with small web application to > monitoring node state. > Web application should has at least 3 pages: > 1.) Node information: hardware configuration, metrics, node attributes > 2.) Cluster state: list of available nodes. > 3.) Caches: list of caches, SQL console, object browser. > Web application should be packed as Ignite plugin to avoid reference to jetty > from Ignite core. > Technologies: > - JSP, JSTL, sitemesh > - Bootstrap, Google Charts -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14939679#comment-14939679
]
Gianfranco Murador commented on IGNITE-429:
---
Chan,
As the ticket is assigned to you, you can make any changes in your own branch
on your fork and make a pull request , you can start with all the changes that
you see in my fork.
Anton, thanks for the tips.
Regards, Gianfranco
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14939679#comment-14939679
]
Gianfranco Murador edited comment on IGNITE-429 at 10/2/15 9:35 AM:
Chan,
As the ticket is assigned to you, you can make any changes in your own branch
on your fork and make a pull request , you can start with all changes that you
see in my fork.
Anton, thanks for the tips.
Regards, Gianfranco
was (Author: glutters):
Chan,
As the ticket is assigned to you, you can make any changes in your own branch
on your fork and make a pull request , you can start with all the changes that
you see in my fork.
Anton, thanks for the tips.
Regards, Gianfranco
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianfranco Murador updated IGNITE-429:
--
Comment: was deleted
(was: Hello Chandresh,
the code has been written correctly,
can you please check these tips described by Anton ?
Regards, Gianfranco
2) Redundant newlines should be removed. At code and imports.
3) Newlines should be added where it necessary:
for example:
Map res = process(tuple);
collector.emit(new Values(res));
5) @Override should be located according to Coding Guidelines.
6) Javadoc sentences should be finished with dot.
)
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942617#comment-14942617
]
Gianfranco Murador commented on IGNITE-429:
---
Hello Chandresh,
the code has been written correctly,
can you please check these tips described by Anton ?
Regards, Gianfranco
2) Redundant newlines should be removed. At code and imports.
3) Newlines should be added where it necessary:
for example:
Map res = process(tuple);
collector.emit(new Values(res));
5) @Override should be located according to Coding Guidelines.
6) Javadoc sentences should be finished with dot.
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942618#comment-14942618
]
Gianfranco Murador commented on IGNITE-429:
---
Hello Chandresh,
the code has been written correctly,
can you please check these tips described by Anton ?
Regards, Gianfranco
2) Redundant newlines should be removed. At code and imports.
3) Newlines should be added where it necessary:
for example:
Map res = process(tuple);
collector.emit(new Values(res));
5) @Override should be located according to Coding Guidelines.
6) Javadoc sentences should be finished with dot.
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14945044#comment-14945044 ] Gianfranco Murador commented on IGNITE-708: --- Hello Yakov, now I understand the situation and I can best approach the issue . I would ask anyway information about how to catch the local changes, if it's possible. Thank to you. > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: ignite-1.5, ignite-1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950055#comment-14950055
]
Gianfranco Murador commented on IGNITE-429:
---
Hi Chandresh,
I think that the test is more complex, in my opinion,
You should start another node , insert data into the grid with the streamer and
then retrieve the same grid and ensure that the same data were included. From
the moment the single node is stopped we also lose the data entered in the grid.
I think it's difficult to get the test within 5 sec.
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956711#comment-14956711 ] Gianfranco Murador commented on IGNITE-708: --- Thanks Anton, I'll wait the end of the resolution of the ticket. > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: 1.5, 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956715#comment-14956715
]
Gianfranco Murador commented on IGNITE-429:
---
Hello Chan, I saw the changes to your unit test file. To check the data entered
by the streamers you have to boot a node ( see the example in examples
folder), after the topology and finally check if the grid has the same data
that we included with the streamer.
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14962481#comment-14962481
]
Gianfranco Murador commented on IGNITE-429:
---
Hello Chandresh,
to solve that problem simply assign a different cache in the configuration
file :
However I believe that it is almost impossible to take a test within 5 seconds.
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963113#comment-14963113
]
Gianfranco Murador commented on IGNITE-429:
---
Hello Chan,
in the configuration file that you specified (examples / config /
example-ignite.xml) or in defautl-config.xml in configuration folder.
Regards, Gianfranco
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-429) Implement IgniteStormStreamer to stream data from Apache Storm
[
https://issues.apache.org/jira/browse/IGNITE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963308#comment-14963308
]
Gianfranco Murador commented on IGNITE-429:
---
Chan , could you post the stack trace of the error ? Also are you sure you're
using the same config to start two different instance of ignite ?
> Implement IgniteStormStreamer to stream data from Apache Storm
> --
>
> Key: IGNITE-429
> URL: https://issues.apache.org/jira/browse/IGNITE-429
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [Apache Storm|https://storm.apache.org/] for more information.
> We should create {{IgniteStormStreamer}} which will consume tuples from Storm
> and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> - Convert/Intercept Storm tuples to Ignite data using an optional pluggable
> converter.
> - Specify the cache name for the Ignite cache to load data into.
> - Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018632#comment-15018632 ] Gianfranco Murador commented on IGNITE-708: --- Hi Anton, yes. Sorry for the late reply. > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: 1.5, 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030510#comment-15030510 ] Gianfranco Murador commented on IGNITE-708: --- Hello Anton, for reasons of time, it might be helpful to provide a draft of the change that you want to set up. Could you show me a first pull request? > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: 1.5, 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032125#comment-15032125 ] Gianfranco Murador commented on IGNITE-708: --- Hello Anton , I mean if I could have some sample code for IGNITE-708. > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: 1.5, 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033975#comment-15033975 ] Gianfranco Murador commented on IGNITE-708: --- Hello Anton , I'm starting to work on it , It's an interesting task , but that could take some time . > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: 1.5, 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1038) Integration of Apache Ignite with Drools and JBPM.
[ https://issues.apache.org/jira/browse/IGNITE-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianfranco Murador updated IGNITE-1038: --- Description: It would manage the integration of Apache ignite with Drools and JBPM. it is possible investigate the following issues and provide an application design and its implementation. 1) JBPM: store a process in the grid. A same instance of a process (in a second stage) could be stored in different nodes and It'll be synchronized because of the principle of locality of data. It's desirable to store only the description of the process with some information at runtime ( status of the process , owner and last operations as well). The main issue is finding an efficient algorithm to rehydrate and freeze the process 2) Drools: explore the possibility of launching distributed computations to increase the efficiency of evaluations of huge business rules. Ref to infinispan implementations: https://github.com/droolsjbpm/droolsjbpm-integration/ Use this repo : https://github.com/apacheignite/drools-ignite.git was: It would manage the integration of Apache ignite with Drools and JBPM. it is possible investigate the following issues and provide an application design and its implementation. 1) JBPM: store a process in the grid. A same instance of a process (in a second stage) could be stored in different nodes and It'll be synchronized because of the principle of locality of data. It's desirable to store only the description of the process with some information at runtime ( status of the process , owner and last operations as well). The main issue is finding an efficient algorithm to rehydrate and freeze the process 2) Drools: explore the possibility of launching distributed computations to increase the efficiency of evaluations of huge business rules. Ref to infinispan implementations: https://github.com/droolsjbpm/droolsjbpm-integration/ > Integration of Apache Ignite with Drools and JBPM. > --- > > Key: IGNITE-1038 > URL: https://issues.apache.org/jira/browse/IGNITE-1038 > Project: Ignite > Issue Type: Task > Components: general > Environment: All hardware >Reporter: Gianfranco Murador >Assignee: Gianfranco Murador > Labels: features > > It would manage the integration of Apache ignite with Drools and JBPM. > it is possible investigate the following issues and provide an application > design and its implementation. > 1) JBPM: store a process in the grid. A same instance of a process (in a > second stage) could be stored in different nodes and It'll be synchronized > because of the principle of locality of data. It's desirable to store only > the description of the process with some information at runtime ( status of > the process , owner and last operations as well). The main issue is finding > an efficient algorithm to rehydrate and freeze the process > 2) Drools: explore the possibility of launching distributed computations to > increase the efficiency of evaluations of huge business rules. > Ref to infinispan implementations: > https://github.com/droolsjbpm/droolsjbpm-integration/ > Use this repo : https://github.com/apacheignite/drools-ignite.git -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[
https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080465#comment-15080465
]
Gianfranco Murador commented on IGNITE-708:
---
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
return false;
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
> Need to remove background partition exchange
>
>
> Key: IGNITE-708
> URL: https://issues.apache.org/jira/browse/IGNITE-708
> Project: Ignite
> Issue Type: Task
>Affects Versions: ignite-1.4
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>Priority: Blocker
> Labels: datagrid
> Fix For: 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the
> oldest node in topology) and coordinator spreads full partition map to every
> node in topology. This happens for each cache separately. This seems to take
> place even if there were no changes to local partition maps. Given we
> guarantee communication message delivery this background process seems to be
> an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount
> of live caches at some point of app lifecycle and app may suffer from
> background exchange which is obviously not a requirement (and may be never
> has been the one).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-708) Need to remove background partition exchange
[
https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080465#comment-15080465
]
Gianfranco Murador edited comment on IGNITE-708 at 1/3/16 4:27 PM:
---
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
return false;
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
The idea is create an history of the state of the local partitions, to check if
the status is changed before sending the message to the oldest node.
was (Author: glutters):
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
return false;
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
> Need to remove background partition exchange
>
>
> Key: IGNITE-708
> URL: https://issues.apache.org/jira/browse/IGNITE-708
> Project: Ignite
> Issue Type: Task
>Affects Versions: ignite-1.4
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>Priority: Blocker
> Labels: datagrid
> Fix For: 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the
> oldest node in topology) and coordinator spreads full partition map to every
> node in topology. This happens for each cache separately. This seems to take
> place even if there were no changes to local partition maps. Given we
> guarantee communication message delivery this background process seems to be
> an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount
> of live caches at some point of app lifecycle and app may suffer from
> background exchange which is obviously not a requirement (and may be never
> has been the one).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-708) Need to remove background partition exchange
[
https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080465#comment-15080465
]
Gianfranco Murador edited comment on IGNITE-708 at 1/3/16 4:28 PM:
---
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
// TODO
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
The idea is create an history of the state of the local partitions, to check if
the status is changed before sending the message to the oldest node.
was (Author: glutters):
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
return false;
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
The idea is create an history of the state of the local partitions, to check if
the status is changed before sending the message to the oldest node.
> Need to remove background partition exchange
>
>
> Key: IGNITE-708
> URL: https://issues.apache.org/jira/browse/IGNITE-708
> Project: Ignite
> Issue Type: Task
>Affects Versions: ignite-1.4
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>Priority: Blocker
> Labels: datagrid
> Fix For: 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the
> oldest node in topology) and coordinator spreads full partition map to every
> node in topology. This happens for each cache separately. This seems to take
> place even if there were no changes to local partition maps. Given we
> guarantee communication message delivery this background process seems to be
> an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount
> of live caches at some point of app lifecycle and app may suffer from
> background exchange which is obviously not a requirement (and may be never
> has been the one).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-708) Need to remove background partition exchange
[
https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080465#comment-15080465
]
Gianfranco Murador edited comment on IGNITE-708 at 1/3/16 4:28 PM:
---
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
/* TODO **/
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
The idea is create an history of the state of the local partitions, to check if
the status is changed before sending the message to the oldest node.
was (Author: glutters):
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
// TODO
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
The idea is create an history of the state of the local partitions, to check if
the status is changed before sending the message to the oldest node.
> Need to remove background partition exchange
>
>
> Key: IGNITE-708
> URL: https://issues.apache.org/jira/browse/IGNITE-708
> Project: Ignite
> Issue Type: Task
>Affects Versions: ignite-1.4
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>Priority: Blocker
> Labels: datagrid
> Fix For: 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the
> oldest node in topology) and coordinator spreads full partition map to every
> node in topology. This happens for each cache separately. This seems to take
> place even if there were no changes to local partition maps. Given we
> guarantee communication message delivery this background process seems to be
> an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount
> of live caches at some point of app lifecycle and app may suffer from
> background exchange which is obviously not a requirement (and may be never
> has been the one).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-708) Need to remove background partition exchange
[
https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080465#comment-15080465
]
Gianfranco Murador edited comment on IGNITE-708 at 1/3/16 4:46 PM:
---
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
public boolean isStateChanged(long current) {
/* TODO **/
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
The idea is create an history of the state of the local partitions, to check if
the status is changed before sending the message to the oldest node.
was (Author: glutters):
Hello everyone, I'm currently working on this ticket. I wanted to ask on which
scenario is used riservation of a local partition. I ask this because in the
class GridDhtLocalPartition we use the stamps of the state of the partition as
reservations.
BTW, I'm editing the GridDhtLocalPartition class inserting two new methods:
/**
* check is the state is changed in the nearest moment
* of the argument value
* @param current the current moment timestamp
* @return true if changed, false otherwise
*/
private boolean isStateChanged(long current) {
/* TODO **/
}
/**
* Add the current state at the history.
* @param currentTime moment
* @param state reference to state
*/
private void addStateToHistory ( long currentTime, GridDhtPartitionState
state){
statesHistory.put(currentTime, state);
}
The idea is create an history of the state of the local partitions, to check if
the status is changed before sending the message to the oldest node.
> Need to remove background partition exchange
>
>
> Key: IGNITE-708
> URL: https://issues.apache.org/jira/browse/IGNITE-708
> Project: Ignite
> Issue Type: Task
>Affects Versions: ignite-1.4
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>Priority: Blocker
> Labels: datagrid
> Fix For: 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the
> oldest node in topology) and coordinator spreads full partition map to every
> node in topology. This happens for each cache separately. This seems to take
> place even if there were no changes to local partition maps. Given we
> guarantee communication message delivery this background process seems to be
> an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount
> of live caches at some point of app lifecycle and app may suffer from
> background exchange which is obviously not a requirement (and may be never
> has been the one).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1038) Integration of Apache Ignite with Drools and JBPM.
[ https://issues.apache.org/jira/browse/IGNITE-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianfranco Murador updated IGNITE-1038: --- Description: It would manage the integration of Apache ignite with Drools and JBPM. it is possible investigate the following issues and provide an application design and its implementation. 1) JBPM: store a process in the grid. A same instance of a process (in a second stage) could be stored in different nodes and It'll be synchronized because of the principle of locality of data. It's desirable to store only the description of the process with some information at runtime ( status of the process , owner and last operations as well). 2) Drools: explore the possibility of launching distributed computations to increase the efficiency of evaluations of huge business rules. Ref to infinispan implementations: https://github.com/droolsjbpm/droolsjbpm-integration/ Use this repo : https://github.com/apacheignite/drools-ignite.git was: It would manage the integration of Apache ignite with Drools and JBPM. it is possible investigate the following issues and provide an application design and its implementation. 1) JBPM: store a process in the grid. A same instance of a process (in a second stage) could be stored in different nodes and It'll be synchronized because of the principle of locality of data. It's desirable to store only the description of the process with some information at runtime ( status of the process , owner and last operations as well). The main issue is finding an efficient algorithm to rehydrate and freeze the process 2) Drools: explore the possibility of launching distributed computations to increase the efficiency of evaluations of huge business rules. Ref to infinispan implementations: https://github.com/droolsjbpm/droolsjbpm-integration/ Use this repo : https://github.com/apacheignite/drools-ignite.git > Integration of Apache Ignite with Drools and JBPM. > --- > > Key: IGNITE-1038 > URL: https://issues.apache.org/jira/browse/IGNITE-1038 > Project: Ignite > Issue Type: Task > Components: general > Environment: All hardware >Reporter: Gianfranco Murador >Assignee: Gianfranco Murador > Labels: features > > It would manage the integration of Apache ignite with Drools and JBPM. > it is possible investigate the following issues and provide an application > design and its implementation. > 1) JBPM: store a process in the grid. A same instance of a process (in a > second stage) could be stored in different nodes and It'll be synchronized > because of the principle of locality of data. It's desirable to store only > the description of the process with some information at runtime ( status of > the process , owner and last operations as well). > 2) Drools: explore the possibility of launching distributed computations to > increase the efficiency of evaluations of huge business rules. > Ref to infinispan implementations: > https://github.com/droolsjbpm/droolsjbpm-integration/ > Use this repo : https://github.com/apacheignite/drools-ignite.git -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15182232#comment-15182232 ] Gianfranco Murador commented on IGNITE-708: --- I think it is too delicate to touch this mechanism without providing a huge amount of non-regression tests. I do not think I can accomplish this task in the limited time that I can devote to Ignite. Sorry for that :(. The ticket can be reassigned if necessary. > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
