[jira] [Updated] (IGNITE-1595) Web Console chart improvements
[ https://issues.apache.org/jira/browse/IGNITE-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov updated IGNITE-1595: --- Fix Version/s: (was: 1.5) ignite-1.5 > Web Console chart improvements > -- > > Key: IGNITE-1595 > URL: https://issues.apache.org/jira/browse/IGNITE-1595 > Project: Ignite > Issue Type: Sub-task > Components: UI >Reporter: Dmitriy Setrakyan >Assignee: Andrey Novikov > Fix For: ignite-1.5 > > > Refresh functionality is not working correctly: > * There should be no blinking > * Axises should not refresh, only data > * Graphs that do not support refresh, should have a message saying: Refresh > is not supported for Bar (icon) charts, use Line (icon) or Area (icon) charts. > Multi-line graphs are not working correctly: > * multiple lines are not shown -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1596) Web console agent improvements
[ https://issues.apache.org/jira/browse/IGNITE-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov updated IGNITE-1596: --- Fix Version/s: (was: 1.5) ignite-1.5 > Web console agent improvements > -- > > Key: IGNITE-1596 > URL: https://issues.apache.org/jira/browse/IGNITE-1596 > Project: Ignite > Issue Type: Sub-task > Components: UI >Reporter: Dmitriy Setrakyan >Assignee: Andrey Novikov > Fix For: ignite-1.5 > > > * Help message should state if the parameter is optional. Ideally default > values should be provided on the next line. > * Default value for config-path should be provided. Text should say: Path to > agent property file > * When started without parameters, web agent should start with defaults > instead of printing help message. > * When started (with or without parameters), agent should print out values > for all the configuration settings. > * We should have a suggestion saying: To start web-agent in test-drive mode, > pass "-tm" and "-ts" parameters > * Before prompting for token, agent should say: > Security token is required to establish connection to the web console. > It is available on the Profile page: https://URL > Enter security token: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1547) NPE if using HTTP REST
[
https://issues.apache.org/jira/browse/IGNITE-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov resolved IGNITE-1547.
Resolution: Fixed
Assignee: Pavel Konstantinov (was: Andrey Novikov)
Please retest in ignite-843 branch
> NPE if using HTTP REST
> --
>
> Key: IGNITE-1547
> URL: https://issues.apache.org/jira/browse/IGNITE-1547
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: ignite-1.5
>
>
> I'm tested Ignite Console SQL feature and got NPE on node start if web agent
> trying to get cache information at this moment
> To reproduce:
> 1) open Ignite web console (console.gridgain.com)
> 2) open SQL page
> 3) start the grid (you need to build 843 branch or you can get master if 843
> already merged into it)
> 4) refresh SQL page during node start
> {code}
> [13:25:56,761][SEVERE][qtp79785210-70][GridJettyRestProtocol] Failed to
> process HTTP request [action=/ignite, req=(GET
> /ignite?cmd=top&attr=true&mtr=false)@1215478528
> org.eclipse.jetty.server.Request@
> 4872bb00]
> class org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.createNodeBean(GridTopologyCommandHandler.java:208)
> at
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.handleAsync(GridTopologyCommandHandler.java:107)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:226)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:79)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:133)
> ... 4 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1547) NPE if using HTTP REST
[
https://issues.apache.org/jira/browse/IGNITE-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948147#comment-14948147
]
Andrey Novikov commented on IGNITE-1547:
Fix was implemented in ignite-1168 and merged into ignite-843.
> NPE if using HTTP REST
> --
>
> Key: IGNITE-1547
> URL: https://issues.apache.org/jira/browse/IGNITE-1547
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Affects Versions: ignite-1.4
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
> Fix For: ignite-1.5
>
>
> I'm tested Ignite Console SQL feature and got NPE on node start if web agent
> trying to get cache information at this moment
> To reproduce:
> 1) open Ignite web console (console.gridgain.com)
> 2) open SQL page
> 3) start the grid (you need to build 843 branch or you can get master if 843
> already merged into it)
> 4) refresh SQL page during node start
> {code}
> [13:25:56,761][SEVERE][qtp79785210-70][GridJettyRestProtocol] Failed to
> process HTTP request [action=/ignite, req=(GET
> /ignite?cmd=top&attr=true&mtr=false)@1215478528
> org.eclipse.jetty.server.Request@
> 4872bb00]
> class org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:6979)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.createNodeBean(GridTopologyCommandHandler.java:208)
> at
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.handleAsync(GridTopologyCommandHandler.java:107)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:226)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:79)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:133)
> ... 4 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1485) Improve loading metadata from DB
[ https://issues.apache.org/jira/browse/IGNITE-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948030#comment-14948030 ] Pavel Konstantinov edited comment on IGNITE-1485 at 10/8/15 4:44 AM: - 1) Doesn't work properly in case when Ethernet is unplugged - popup doesn't appear. 2) Do not show error message after user already clicked Home 3) Need to make instruction in poopup more clear and detailed (e.g. add info about security token) was (Author: pkonstantinov): 1) Doesn't work properly in case when Ethernet is unplugged - popup doesn't appear. 2) Do not show error message after user already clicked Home > Improve loading metadata from DB > > > Key: IGNITE-1485 > URL: https://issues.apache.org/jira/browse/IGNITE-1485 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > Fix For: ignite-1.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1485) Improve loading metadata from DB
[ https://issues.apache.org/jira/browse/IGNITE-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948030#comment-14948030 ] Pavel Konstantinov edited comment on IGNITE-1485 at 10/8/15 4:24 AM: - 1) Doesn't work properly in case when Ethernet is unplugged - popup doesn't appear. 2) Do not show error message after user already clicked Home was (Author: pkonstantinov): Doesn't work properly in case when Ethernet is unplugged - popup doesn't appear. > Improve loading metadata from DB > > > Key: IGNITE-1485 > URL: https://issues.apache.org/jira/browse/IGNITE-1485 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > Fix For: ignite-1.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (IGNITE-1485) Improve loading metadata from DB
[ https://issues.apache.org/jira/browse/IGNITE-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-1485: Assignee: Vasiliy Sisko (was: Pavel Konstantinov) Doesn't work properly in case when Ethernet is unplugged - popup doesn't appear. > Improve loading metadata from DB > > > Key: IGNITE-1485 > URL: https://issues.apache.org/jira/browse/IGNITE-1485 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > Fix For: ignite-1.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1633) We need to fix agent file name in docs (readme) from 'ignite-control-center-agent' to 'ignite-web-agent'
Pavel Konstantinov created IGNITE-1633: -- Summary: We need to fix agent file name in docs (readme) from 'ignite-control-center-agent' to 'ignite-web-agent' Key: IGNITE-1633 URL: https://issues.apache.org/jira/browse/IGNITE-1633 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov Assignee: Vasiliy Sisko Some time ago we renamed agent to to 'ignite-web-agent', but in 'readme' and may be in others docs it still has old name 'ignite-control-center-agent' -- 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] [Updated] (IGNITE-1590) IGFS: update & create operations should be truly thread-safe.
[ https://issues.apache.org/jira/browse/IGNITE-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Veselovsky updated IGNITE-1590: Assignee: Vladimir Ozerov (was: Ivan Veselovsky) > IGFS: update & create operations should be truly thread-safe. > - > > Key: IGNITE-1590 > URL: https://issues.apache.org/jira/browse/IGNITE-1590 > Project: Ignite > Issue Type: Bug >Affects Versions: ignite-1.4 >Reporter: Ivan Veselovsky >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Fix #create() operation & revise #update(). > Currently the tests with many concurrent operations (involving > delete/rename/nkdirs/create) reveal concurrency problems -- some tree entries > get "lost". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1632) IGFS: many operations in DUAL modes fail if IGFS block size is small
Ivan Veselovsky created IGNITE-1632:
---
Summary: IGFS: many operations in DUAL modes fail if IGFS block
size is small
Key: IGNITE-1632
URL: https://issues.apache.org/jira/browse/IGNITE-1632
Project: Ignite
Issue Type: Bug
Components: hadoop
Affects Versions: ignite-1.4
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
Fix For: ignite-1.5
Currently
org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest#IGFS_BLOCK_SIZE
= 512 * 1024;
Set it to a small value, e.g. = 31 and run dual mode tests, e.g.
IgfsDualSyncSelfTest .
Many failures with exception like the following will be observed:
{code}
java.lang.AssertionError: Chunk #0 was not read fully: read=31, expected=128
at
org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.checkFileContent(IgfsAbstractSelfTest.java:2895)
at
org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.checkFile(IgfsAbstractSelfTest.java:2828)
at
org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest.testAppendParentMissing(IgfsDualAbstractSelfTest.java:1383)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1665)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1631) IGFS: append fails to create a new file in DUAL modes
Ivan Veselovsky created IGNITE-1631: --- Summary: IGFS: append fails to create a new file in DUAL modes Key: IGNITE-1631 URL: https://issues.apache.org/jira/browse/IGNITE-1631 Project: Ignite Issue Type: Bug Components: hadoop Affects Versions: ignite-1.4 Reporter: Ivan Veselovsky Assignee: Ivan Veselovsky Fix For: ignite-1.5 An attempt to create a new file using IGFS#append() method with "create" flag being 'true' constantly fails with the below exception. Fix that and cover with tests. Caused by: class org.apache.ignite.IgniteCheckedException: Failed to append to the file due to secondary file system exception: /dir/subdir/file2 at org.apache.ignite.internal.processors.igfs.IgfsMetaManager$6.onFailure(IgfsMetaManager.java:2332) at org.apache.ignite.internal.processors.igfs.IgfsMetaManager$6.onFailure(IgfsMetaManager.java:2284) at org.apache.ignite.internal.processors.igfs.IgfsMetaManager.synchronizeAndExecute(IgfsMetaManager.java:3065) at org.apache.ignite.internal.processors.igfs.IgfsMetaManager.synchronizeAndExecute(IgfsMetaManager.java:2860) at org.apache.ignite.internal.processors.igfs.IgfsMetaManager.appendDual(IgfsMetaManager.java:2337) at org.apache.ignite.internal.processors.igfs.IgfsImpl$16.call(IgfsImpl.java:1119) at org.apache.ignite.internal.processors.igfs.IgfsImpl$16.call(IgfsImpl.java:1104) at org.apache.ignite.internal.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:2014) ... 11 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to create path locally due to secondary file system exception: /dir at org.apache.ignite.internal.processors.igfs.IgfsMetaManager.synchronize(IgfsMetaManager.java:2814) at org.apache.ignite.internal.processors.igfs.IgfsMetaManager.synchronizeAndExecute(IgfsMetaManager.java:3018) ... 16 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1093) Rebalancing with default parameters is very slow
[ https://issues.apache.org/jira/browse/IGNITE-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947196#comment-14947196 ] Anton Vinogradov commented on IGNITE-1093: -- I've implemented new version of rebalancing, testing and benchmarking now. Found really weird thing: I see that in case when new node join topology at the end of rebalancing at supply node happens big GC pause (not stop the world). 249.920: [GC249.920: [ParNew: 130944K->0K(131008K), 0.3429600 secs] 6010351K->5945518K(15728576K), 0.3431210 secs] [Times: user=1.98 sys=0.01, real=0.35 secs] In case failureDetectionTimeout less than 300 ms this node left topology. Same happens at both new and old rebalancing implementation. Going to make heapdumps at the end of rebalancing to fix this issue. In case someone know possible reasons please feel free to post ideas. > Rebalancing with default parameters is very slow > > > Key: IGNITE-1093 > URL: https://issues.apache.org/jira/browse/IGNITE-1093 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: sprint-7 >Reporter: Pavel Konstantinov >Assignee: Anton Vinogradov >Priority: Critical > Fix For: ignite-1.5 > > Attachments: Plot_ThroughputLatencyProbe_01.png, rebalancing.zip > > > # Start one node with partitioned cache with one backup. > # Load into the cache 40billions of keys using DataStreamer > # Start second node on the same host -- 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&focusedCommentId=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] [Commented] (IGNITE-1509) .Net: User must operate on IEnumerable in events API rather than on arrays.
[ https://issues.apache.org/jira/browse/IGNITE-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947086#comment-14947086 ] ASF GitHub Bot commented on IGNITE-1509: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/140 IGNITE-1509 .Net: User must operate on IEnumerable in events API rather than on arrays. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1509 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/140.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #140 commit 3e05f48bb1e92f5bc6f3d349337a3d1f1b63dd81 Author: ptupitsyn Date: 2015-10-07T14:55:39Z IGNITE-1509 .Net: User must operate on IEnumerable in events API rather than on arrays. commit 4d4e0809323a7126adc492c07d2b0c99edce5ced Author: ptupitsyn Date: 2015-10-07T15:01:27Z EventType fix done commit f569c79c25214252a90460c078c64a2040ef4e59 Author: ptupitsyn Date: 2015-10-07T15:17:28Z wip commit ac8f9fc1d19186f0fcee0dbeee622bfb75da24a4 Author: ptupitsyn Date: 2015-10-07T15:34:30Z wip commit 5038fe079d2e0db712934dbb85ada40d10e8297d Author: ptupitsyn Date: 2015-10-07T15:43:39Z wip commit 7a1e34374543c3c04f972600fcfe00927234ca03 Author: ptupitsyn Date: 2015-10-07T15:51:00Z Iface done commit a4b967582cc1fd719568129325fa521078035ce7 Author: ptupitsyn Date: 2015-10-07T15:52:35Z wip commit df6a4f3df21d9a46c45c88f202f4d80f882993d0 Author: ptupitsyn Date: 2015-10-07T15:58:19Z Compilation fixed commit fecdb2bc78d28ffdb54f5d019bc74d621731f22a Author: ptupitsyn Date: 2015-10-07T16:02:26Z done > .Net: User must operate on IEnumerable in events API rather than on arrays. > --- > > Key: IGNITE-1509 > URL: https://issues.apache.org/jira/browse/IGNITE-1509 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: ignite-1.5 > > > Currently we expose arrays for event groups. As they are mutable, we have to > copy them every time user use them. > To avoid this we should switch to IEnumerables and leave shortcut methods > with "params[]" for convenience. -- 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=14946950#comment-14946950
]
Roman Shtykh commented on IGNITE-429:
-
Default timeout is 5000 ms.
> 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=14946948#comment-14946948
]
Roman Shtykh commented on IGNITE-429:
-
Chandresh,
I cannot run your code right now and not sure where you get a timeout, but if
it is related to TEST-TIMEOUT-MS of the topology, see
CompleteTopologyParam's setTimeoutMs()
I think it is implemented in Storm 0.10.0. In earlier versions this test
parameter is not accessible from Java.
So changing Storm version and checking completeTopologyParam.setTimeoutMs(...)
may help.
> 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-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946895#comment-14946895
]
Andrey Gura commented on IGNITE-1526:
-
Ok. Fixed.
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: ignite-1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException:
> org.apache.ignite.internal.util.lang.G
> ridFunc$38; local class incompatible: stream classdesc serialVersionUID =
> -55433
> 49853748590486, local class serialVersionUID = -5664060422647374863
> at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:617)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:162
> 2)
> at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream
[jira] [Commented] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946887#comment-14946887
]
Denis Magda commented on IGNITE-1526:
-
In general the changes look good.
The only minor comment is to set {{USE_DFLT_SUID}} property to {{true}} by
default in order to preserve backward compatibility with an already running
cluster.
For those who may use the heterogeneous configuration we should document the
usage of this property.
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: ignite-1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException:
> org.apache.ignite.internal.util.lang.G
> ridFunc$38; local class incompatible: stream classdesc serialVersionUID =
> -55433
> 49853748590486, local class serialVersionUID = -5664060422647374863
> at java.io.ObjectStreamClass.initNon
[jira] [Assigned] (IGNITE-1509) .Net: User must operate on IEnumerable in events API rather than on arrays.
[ https://issues.apache.org/jira/browse/IGNITE-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1509: --- Assignee: Pavel Tupitsyn > .Net: User must operate on IEnumerable in events API rather than on arrays. > --- > > Key: IGNITE-1509 > URL: https://issues.apache.org/jira/browse/IGNITE-1509 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > Fix For: ignite-1.5 > > > Currently we expose arrays for event groups. As they are mutable, we have to > copy them every time user use them. > To avoid this we should switch to IEnumerables and leave shortcut methods > with "params[]" for convenience. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1514) Platform .Net: Implement IIgnite.DestroyCache
[ https://issues.apache.org/jira/browse/IGNITE-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1514: --- Assignee: (was: Pavel Tupitsyn) > Platform .Net: Implement IIgnite.DestroyCache > - > > Key: IGNITE-1514 > URL: https://issues.apache.org/jira/browse/IGNITE-1514 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.5 >Reporter: Pavel Tupitsyn > > Add and implement IIgnite.DestroyCache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1608) Platform .Net: Optimize PortableWriterImpl.WritePrimitive
[ https://issues.apache.org/jira/browse/IGNITE-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1608: --- Assignee: (was: Pavel Tupitsyn) > Platform .Net: Optimize PortableWriterImpl.WritePrimitive > - > > Key: IGNITE-1608 > URL: https://issues.apache.org/jira/browse/IGNITE-1608 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.5 >Reporter: Pavel Tupitsyn > Fix For: ignite-1.5 > > > Huge "if" tree can be replaced with dynamic dispatch. > Need to investigate if performance can be improved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1480) Platform .Net: IClusterNode.IsClient
[ https://issues.apache.org/jira/browse/IGNITE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1480: --- Assignee: (was: Pavel Tupitsyn) > Platform .Net: IClusterNode.IsClient > > > Key: IGNITE-1480 > URL: https://issues.apache.org/jira/browse/IGNITE-1480 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.5 >Reporter: Pavel Tupitsyn > Fix For: ignite-1.5 > > > Ignite in Java has ClusterNode.isClient, need to implement in .Net. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1563) .Net: Implement "atomic" data structures.
[ https://issues.apache.org/jira/browse/IGNITE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1563: --- Assignee: (was: Pavel Tupitsyn) > .Net: Implement "atomic" data structures. > - > > Key: IGNITE-1563 > URL: https://issues.apache.org/jira/browse/IGNITE-1563 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.5 >Reporter: Pavel Tupitsyn > Fix For: ignite-1.5 > > > This includes: > atomicSequence; > atomicStamped; > atomicReference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1567) Optimize portable object fields read/write in .Net.
[ https://issues.apache.org/jira/browse/IGNITE-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-1567: --- Assignee: (was: Pavel Tupitsyn) > Optimize portable object fields read/write in .Net. > --- > > Key: IGNITE-1567 > URL: https://issues.apache.org/jira/browse/IGNITE-1567 > Project: Ignite > Issue Type: Sub-task > Components: interop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Critical > > 1) Infer field length for primitive types > 2) Optimize Zero const writing > 3) ... -- 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=14946851#comment-14946851
]
Chandresh Pancholi commented on IGNITE-429:
---
Hi Roman/Gian,
I have pushed the code but tests are timing out.Can anyone of you help me out
here.
@Anton,
Please wait for this change. I will update pull request once this timeout issue
resolved.
Repo: https://github.com/chandresh-pancholi/ignite
Thanks
> 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-1625) .Net: Remove Types serialization from Continuous Queries
[ https://issues.apache.org/jira/browse/IGNITE-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946849#comment-14946849 ] ASF GitHub Bot commented on IGNITE-1625: GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/139 IGNITE-1625 .Net: Remove Types serialization from Continuous Queries You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-1625 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/139.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #139 commit df01989cfc70fcc8db4ce9bc4c65e7615968550b Author: ptupitsyn Date: 2015-10-07T13:15:08Z IGNITE-1625 .Net: Remove Types serialization from Continuous Queries commit e398c6667e79a750c6bd8b41025297942938003e Author: ptupitsyn Date: 2015-10-07T13:23:29Z Fix ctor type > .Net: Remove Types serialization from Continuous Queries > > > Key: IGNITE-1625 > URL: https://issues.apache.org/jira/browse/IGNITE-1625 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: ignite-1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: ignite-1.5 > > > See ContinuousQueryFilterHolder class: it serializes KeyType and ValueType, > but this is redundant, since user filter already carries type information. > * Remove type serialization > * Leverage DelegateTypeDescriptor to get rid of reflection in > UnmanagedCallbacks.ContinuousQueryFilterCreate -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1630) .Net: Create LINQ adapter for queries.
Vladimir Ozerov created IGNITE-1630: --- Summary: .Net: Create LINQ adapter for queries. Key: IGNITE-1630 URL: https://issues.apache.org/jira/browse/IGNITE-1630 Project: Ignite Issue Type: Task Components: interop Affects Versions: ignite-1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.6 *NOTE*: Is targeted for 1.6, but might be moved forward in case of tight release schedule. SQL queries are one of the most frequently used features in data grids. And .Net comes with a very nice LINQ concept. We need to investigate and idea of own LINQ adapter which will delegate to Ignite native query API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1629) .Net: Introduce native logging facility.
Vladimir Ozerov created IGNITE-1629: --- Summary: .Net: Introduce native logging facility. Key: IGNITE-1629 URL: https://issues.apache.org/jira/browse/IGNITE-1629 Project: Ignite Issue Type: Task Components: interop Affects Versions: ignite-1.4 Reporter: Vladimir Ozerov Priority: Blocker Fix For: ignite-1.6 This is pretty serious usability issue. Currently Ignite produces logs using Java "log4j" library. While naural for Java environment, this is somewhat alien for Windows users. We need to investigate ability to hack into normal .Net logging frameworks. This include both native Windows APIs (e.g. events), and widely-used .Net loggers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1628) .Net: Ensure that .Net works on Mono platform.
Vladimir Ozerov created IGNITE-1628: --- Summary: .Net: Ensure that .Net works on Mono platform. Key: IGNITE-1628 URL: https://issues.apache.org/jira/browse/IGNITE-1628 Project: Ignite Issue Type: Task Components: interop Affects Versions: ignite-1.4 Reporter: Vladimir Ozerov Priority: Critical Fix For: ignite-1.6 *NOTE*: Targeted for 1.6, but could be moved even further in case of tight release schedule. *Goal* As Microsoft is moving .Net towards open standards, Mono receives more an more attention. We need to ensure that our product works fine on this platform. This includes both Windows, Linux and (possibly) Mac environments. *Tasks* - Ensure that Ignite works with Mono on Windows. This is the easiest task because we only need to re-compile .Net part. - Ensure that Ignite works with Mono on Linux. This will require alternate build procedure because CPP recompilation will be required as well. - Create relevant TC builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946819#comment-14946819
]
tc_commenter commented on IGNITE-1272:
--
There was triggered next test builds for last attached patch-file:
01. http://204.14.53.153/viewQueued.html?itemId=109331 - Ignite AOP
02. http://204.14.53.153/viewQueued.html?itemId=109332 - Ignite Basic
03. http://204.14.53.153/viewQueued.html?itemId=109333 - Ignite Cache
04. http://204.14.53.153/viewQueued.html?itemId=109334 - Ignite Cache 2
05. http://204.14.53.153/viewQueued.html?itemId=109335 - Ignite Cache 3
06. http://204.14.53.153/viewQueued.html?itemId=109336 - Ignite Cache 4
07. http://204.14.53.153/viewQueued.html?itemId=109337 - Ignite Cache Expiry
Policy
08. http://204.14.53.153/viewQueued.html?itemId=109338 - Ignite Cache Failover
09. http://204.14.53.153/viewQueued.html?itemId=109339 - Ignite Cache Failover
Multi JVM
10. http://204.14.53.153/viewQueued.html?itemId=109340 - Ignite Cache Failover2
11. http://204.14.53.153/viewQueued.html?itemId=109341 - Ignite Cache Full API
12. http://204.14.53.153/viewQueued.html?itemId=109342 - Ignite Cache Full API
Multi JVM
13. http://204.14.53.153/viewQueued.html?itemId=109343 - Ignite Cache Full API
Portable
14. http://204.14.53.153/viewQueued.html?itemId=109344 - Ignite Cache Portable
15. http://204.14.53.153/viewQueued.html?itemId=109345 - Ignite Cache Query
Portable
16. http://204.14.53.153/viewQueued.html?itemId=109346 - Ignite Cache Restarts
17. http://204.14.53.153/viewQueued.html?itemId=109347 - Ignite Cache Tx
Recovery
18. http://204.14.53.153/viewQueued.html?itemId=109348 - Ignite Cloud
19. http://204.14.53.153/viewQueued.html?itemId=109349 - Ignite Compute Grid
20. http://204.14.53.153/viewQueued.html?itemId=109350 - Ignite Data Strucutures
21. http://204.14.53.153/viewQueued.html?itemId=109351 - Ignite Examples
22. http://204.14.53.153/viewQueued.html?itemId=109352 - Ignite GCE
23. http://204.14.53.153/viewQueued.html?itemId=109353 - Ignite Geospacial
Indexing
24. http://204.14.53.153/viewQueued.html?itemId=109354 - Ignite H2 Indexing
25. http://204.14.53.153/viewQueued.html?itemId=109355 - Ignite Hadoop
26. http://204.14.53.153/viewQueued.html?itemId=109356 - Ignite Hibernate
27. http://204.14.53.153/viewQueued.html?itemId=109357 - Ignite IGFS
28. http://204.14.53.153/viewQueued.html?itemId=109358 - Ignite IGFS Examples
29. http://204.14.53.153/viewQueued.html?itemId=109359 - Ignite IGFS Linux and
MacOS
30. http://204.14.53.153/viewQueued.html?itemId=109360 - Ignite Java Client
31. http://204.14.53.153/viewQueued.html?itemId=109361 - Ignite JDBC Driver
32. http://204.14.53.153/viewQueued.html?itemId=109362 - Ignite JTA
33. http://204.14.53.153/viewQueued.html?itemId=109363 - Ignite Logging
34. http://204.14.53.153/viewQueued.html?itemId=109364 - Ignite Portables Basic
35. http://204.14.53.153/viewQueued.html?itemId=109365 - Ignite Queries
36. http://204.14.53.153/viewQueued.html?itemId=109366 - Ignite Scalar Examples
37. http://204.14.53.153/viewQueued.html?itemId=109367 - Ignite SPI
38. http://204.14.53.153/viewQueued.html?itemId=109368 - Ignite Spring
39. http://204.14.53.153/viewQueued.html?itemId=109369 - Ignite Start Nodes
40. http://204.14.53.153/viewQueued.html?itemId=109370 - Ignite URI Deploy SPI
41. http://204.14.53.153/viewQueued.html?itemId=109371 - Ignite Visor Console
42. http://204.14.53.153/viewQueued.html?itemId=109372 - Ignite WebSessions
43. http://204.14.53.153/viewQueued.html?itemId=109373 - JCache TCK
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: ignite-1.5
>
> Attachments: ignite-1272.patch, ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1272:
Attachment: ignite-1272.patch
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: ignite-1.5
>
> Attachments: ignite-1272.patch, ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1627) .Net: Consistent product naming.
Vladimir Ozerov created IGNITE-1627: --- Summary: .Net: Consistent product naming. Key: IGNITE-1627 URL: https://issues.apache.org/jira/browse/IGNITE-1627 Project: Ignite Issue Type: Task Components: interop Affects Versions: ignite-1.4 Reporter: Vladimir Ozerov Priority: Blocker Fix For: ignite-1.5 We need to look through all docs and READMEs and ensure that our product is named consistently: "Apache Ignite.NET". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1626) .Net: Create NuGet package.
Vladimir Ozerov created IGNITE-1626: --- Summary: .Net: Create NuGet package. Key: IGNITE-1626 URL: https://issues.apache.org/jira/browse/IGNITE-1626 Project: Ignite Issue Type: Task Components: interop Affects Versions: ignite-1.5 Reporter: Vladimir Ozerov Priority: Blocker Fix For: ignite-1.5 *Overview* To boost usage of the product we need to distribute it using NuGet, which is tightly integrated with Visual Studio. To achieve this several technical, infrastructure and marketing tasks must be completed. *Technical tasks* - Apache Ignite.NET heavily depends on relative positions of compiled Java classes. We must be able to apply different classpath search strategies depending on packaging. This includes normal search in exploded build directory, search in NuGet package, search in local Maven repo. - We need a way to select classpath search strategy. E.g. we can add special marker resource to NuGet package so that DLL understands that it is NuGet-based. More investigation here is reuqired. - Minimal set of required JARs should be defined. Currently we have over >100Mb of Java libraries shipped with Ignite build. NuGet have limitation of 30Mb per package. Only vital subset of JARs should be shipped. *Infrastructure tasks* - INFRA team must be asked about a place where NuGet package could be stored. - Separate build plan should be created, producing NuGet artifacts. *Marketing tasks* - We need to produce clean, selling and intriguing header and description for our package and attach logo. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1625) .Net: Remove Types serialization from Continuous Queries
Pavel Tupitsyn created IGNITE-1625: --- Summary: .Net: Remove Types serialization from Continuous Queries Key: IGNITE-1625 URL: https://issues.apache.org/jira/browse/IGNITE-1625 Project: Ignite Issue Type: Improvement Components: interop Affects Versions: ignite-1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: ignite-1.5 See ContinuousQueryFilterHolder class: it serializes KeyType and ValueType, but this is redundant, since user filter already carries type information. * Remove type serialization * Leverage DelegateTypeDescriptor to get rid of reflection in UnmanagedCallbacks.ContinuousQueryFilterCreate -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1619) Platform .Net: Generic type is lost during array/collection serialization
[ https://issues.apache.org/jira/browse/IGNITE-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946778#comment-14946778 ] Pavel Tupitsyn commented on IGNITE-1619: - Done. Removed generic collection support in PortableBuilder (exception is thrown). Xmldoc updated (only non-generic collections, primitive arrays and object arrays can be used for interop). > Platform .Net: Generic type is lost during array/collection serialization > - > > Key: IGNITE-1619 > URL: https://issues.apache.org/jira/browse/IGNITE-1619 > Project: Ignite > Issue Type: Bug > Components: interop >Affects Versions: ignite-1.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: ignite-1.5 > > > We do not serialize collection/array element type, so on deserialization we > can not recreate original collection. So generic arrays/collections can't be > used in job arguments, service arguments, etc. > * We should keep current format for non-generic collections, arrays of > primitives, and arrays of objects > * Generic collections and arrays should be written with new TypeIds (not > compatible with other platforms) and include type information -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1613) Platform .Net: Investigate Guid/DateTime/String interoperability with Java
[ https://issues.apache.org/jira/browse/IGNITE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-1613. --- > Platform .Net: Investigate Guid/DateTime/String interoperability with Java > -- > > Key: IGNITE-1613 > URL: https://issues.apache.org/jira/browse/IGNITE-1613 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: ignite-1.5 >Reporter: Pavel Tupitsyn >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Currently in .Net we: > * write Guid and DateTime in Java format > * calculate string hash code for field names with Java algorithm on each call > Need to investigate if the following makes sense: > 1) In .Net always write Guid and DateTime in native .Net format as fast as > possible; Make Java understand that format. (Not every Guid written in .Net > will be read in Java, so we can win time). > 2) Cache string hashcodes somehow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1420) .Net: Optimize metadata write.
[ https://issues.apache.org/jira/browse/IGNITE-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-1420. - Resolution: Fixed > .Net: Optimize metadata write. > -- > > Key: IGNITE-1420 > URL: https://issues.apache.org/jira/browse/IGNITE-1420 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Currently we perform int dictionary lookup on each field write to track > metadata updates. This could be less than optimal because metadata updates > are very rare. > Several optimizations can be applied here: > 1) For types where we use reflection we can collect all metadata information > only once and write it when the first object of a type gets marshalled. > Nothing more is needed. > 2) For "marshal aware" types we never know whether new metadata is expected > or not. We can introduce tree-like structure. When serialization start we are > on the top of it. Then we go down as the fields are written. If we cannot > find the node for the given field ID - we are on the new path. Then we create > a copy of a tree and continue our path collecting updates. Finally, we flush > them to Java and update global tree with latest changes. > This can be highly optimized for the most common cases when there is one, at > most two paths for the given sequence: > - When there is only one known path, data can be stored as array. We simply > go through it and compare current field ID with expected. So this is just > int[]. > - When there are more paths in some places, we can have int[] + dispatch map. > For 2-4 paths its is just a binary switch. For more paths we can fallback to > normal dictionary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1420) .Net: Optimize metadata write.
[ https://issues.apache.org/jira/browse/IGNITE-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-1420. --- > .Net: Optimize metadata write. > -- > > Key: IGNITE-1420 > URL: https://issues.apache.org/jira/browse/IGNITE-1420 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Currently we perform int dictionary lookup on each field write to track > metadata updates. This could be less than optimal because metadata updates > are very rare. > Several optimizations can be applied here: > 1) For types where we use reflection we can collect all metadata information > only once and write it when the first object of a type gets marshalled. > Nothing more is needed. > 2) For "marshal aware" types we never know whether new metadata is expected > or not. We can introduce tree-like structure. When serialization start we are > on the top of it. Then we go down as the fields are written. If we cannot > find the node for the given field ID - we are on the new path. Then we create > a copy of a tree and continue our path collecting updates. Finally, we flush > them to Java and update global tree with latest changes. > This can be highly optimized for the most common cases when there is one, at > most two paths for the given sequence: > - When there is only one known path, data can be stored as array. We simply > go through it and compare current field ID with expected. So this is just > int[]. > - When there are more paths in some places, we can have int[] + dispatch map. > For 2-4 paths its is just a binary switch. For more paths we can fallback to > normal dictionary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1420) .Net: Optimize metadata write.
[ https://issues.apache.org/jira/browse/IGNITE-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946722#comment-14946722 ] Vladimir Ozerov commented on IGNITE-1420: - Implemented. Benchmark with "Address" entiry shows 10% throughput increase without metadata (saved on field ID calculation) and 100% increase with metadata (no field IDs, no metadata table lookups). > .Net: Optimize metadata write. > -- > > Key: IGNITE-1420 > URL: https://issues.apache.org/jira/browse/IGNITE-1420 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Currently we perform int dictionary lookup on each field write to track > metadata updates. This could be less than optimal because metadata updates > are very rare. > Several optimizations can be applied here: > 1) For types where we use reflection we can collect all metadata information > only once and write it when the first object of a type gets marshalled. > Nothing more is needed. > 2) For "marshal aware" types we never know whether new metadata is expected > or not. We can introduce tree-like structure. When serialization start we are > on the top of it. Then we go down as the fields are written. If we cannot > find the node for the given field ID - we are on the new path. Then we create > a copy of a tree and continue our path collecting updates. Finally, we flush > them to Java and update global tree with latest changes. > This can be highly optimized for the most common cases when there is one, at > most two paths for the given sequence: > - When there is only one known path, data can be stored as array. We simply > go through it and compare current field ID with expected. So this is just > int[]. > - When there are more paths in some places, we can have int[] + dispatch map. > For 2-4 paths its is just a binary switch. For more paths we can fallback to > normal dictionary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1420) .Net: Optimize metadata write.
[ https://issues.apache.org/jira/browse/IGNITE-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-1420: --- Assignee: Vladimir Ozerov > .Net: Optimize metadata write. > -- > > Key: IGNITE-1420 > URL: https://issues.apache.org/jira/browse/IGNITE-1420 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Currently we perform int dictionary lookup on each field write to track > metadata updates. This could be less than optimal because metadata updates > are very rare. > Several optimizations can be applied here: > 1) For types where we use reflection we can collect all metadata information > only once and write it when the first object of a type gets marshalled. > Nothing more is needed. > 2) For "marshal aware" types we never know whether new metadata is expected > or not. We can introduce tree-like structure. When serialization start we are > on the top of it. Then we go down as the fields are written. If we cannot > find the node for the given field ID - we are on the new path. Then we create > a copy of a tree and continue our path collecting updates. Finally, we flush > them to Java and update global tree with latest changes. > This can be highly optimized for the most common cases when there is one, at > most two paths for the given sequence: > - When there is only one known path, data can be stored as array. We simply > go through it and compare current field ID with expected. So this is just > int[]. > - When there are more paths in some places, we can have int[] + dispatch map. > For 2-4 paths its is just a binary switch. For more paths we can fallback to > normal dictionary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1425) .Net: Reflective serializer can cache field IDs.
[ https://issues.apache.org/jira/browse/IGNITE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-1425. --- > .Net: Reflective serializer can cache field IDs. > > > Key: IGNITE-1425 > URL: https://issues.apache.org/jira/browse/IGNITE-1425 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Instead of calculating field IDs on each run, reflective serializer can > calculate them once during initialization and then just write directly as > ints. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1420) .Net: Optimize metadata write.
[ https://issues.apache.org/jira/browse/IGNITE-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1420: Fix Version/s: ignite-1.5 > .Net: Optimize metadata write. > -- > > Key: IGNITE-1420 > URL: https://issues.apache.org/jira/browse/IGNITE-1420 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Currently we perform int dictionary lookup on each field write to track > metadata updates. This could be less than optimal because metadata updates > are very rare. > Several optimizations can be applied here: > 1) For types where we use reflection we can collect all metadata information > only once and write it when the first object of a type gets marshalled. > Nothing more is needed. > 2) For "marshal aware" types we never know whether new metadata is expected > or not. We can introduce tree-like structure. When serialization start we are > on the top of it. Then we go down as the fields are written. If we cannot > find the node for the given field ID - we are on the new path. Then we create > a copy of a tree and continue our path collecting updates. Finally, we flush > them to Java and update global tree with latest changes. > This can be highly optimized for the most common cases when there is one, at > most two paths for the given sequence: > - When there is only one known path, data can be stored as array. We simply > go through it and compare current field ID with expected. So this is just > int[]. > - When there are more paths in some places, we can have int[] + dispatch map. > For 2-4 paths its is just a binary switch. For more paths we can fallback to > normal dictionary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1425) .Net: Reflective serializer can cache field IDs.
[ https://issues.apache.org/jira/browse/IGNITE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-1425: --- Assignee: Vladimir Ozerov > .Net: Reflective serializer can cache field IDs. > > > Key: IGNITE-1425 > URL: https://issues.apache.org/jira/browse/IGNITE-1425 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: ignite-1.5 > > > Instead of calculating field IDs on each run, reflective serializer can > calculate them once during initialization and then just write directly as > ints. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1425) .Net: Reflective serializer can cache field IDs.
[ https://issues.apache.org/jira/browse/IGNITE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-1425. - Resolution: Won't Fix Fixed as a part of IGNITE-1420. > .Net: Reflective serializer can cache field IDs. > > > Key: IGNITE-1425 > URL: https://issues.apache.org/jira/browse/IGNITE-1425 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > > Instead of calculating field IDs on each run, reflective serializer can > calculate them once during initialization and then just write directly as > ints. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1425) .Net: Reflective serializer can cache field IDs.
[ https://issues.apache.org/jira/browse/IGNITE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1425: Fix Version/s: ignite-1.5 > .Net: Reflective serializer can cache field IDs. > > > Key: IGNITE-1425 > URL: https://issues.apache.org/jira/browse/IGNITE-1425 > Project: Ignite > Issue Type: Task > Components: interop >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Fix For: ignite-1.5 > > > Instead of calculating field IDs on each run, reflective serializer can > calculate them once during initialization and then just write directly as > ints. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1624) [Test failed] Ignite SPI: TcpClientDiscoverySpiSelfTest.testJoinError failed
Andrey Gura created IGNITE-1624:
---
Summary: [Test failed] Ignite SPI:
TcpClientDiscoverySpiSelfTest.testJoinError failed
Key: IGNITE-1624
URL: https://issues.apache.org/jira/browse/IGNITE-1624
Project: Ignite
Issue Type: Test
Reporter: Andrey Gura
Priority: Blocker
Fix For: ignite-1.5
The following test periodically fail on TC:
* {{TcpClientDiscoverySpiSelfTest.testJoinError}}
* {{TcpClientDiscoverySpiFailureTimeoutSelfTest.testJoinError}}
{noformat}
[18:07:52,332][ERROR][test-runner][IgniteKernal%client-0] Got exception while
starting (will rollback startup routine).
class org.apache.ignite.IgniteCheckedException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1488)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:724)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:708)
at
org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.startClientNodes(TcpClientDiscoverySpiSelfTest.java:1850)
at
org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testJoinError(TcpClientDiscoverySpiSelfTest.java:1085)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1665)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:111)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:1603)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI:
TcpDiscoverySpi [addrRslvr=null, sockTimeout=5000, ackTimeout=5000,
reconCnt=10, maxAckTimeout=60, forceSrvMode=false,
clientReconnectDisabled=false]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:255)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:666)
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1485)
... 17 more
Caused by: class org.apache.ignite.spi.IgniteSpiException: Join process timed
out, did not receive response for join request (consider increasing
'joinTimeout' configuration property) [joinTimeout=8000,
sock=Socket[addr=/127.0.0.1,port=47500,localport=43551]]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1324)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[18:07:52,357][ERROR][main][root] Test failed.
class org.apache.ignite.IgniteCheckedException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1488)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:526)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:724)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:708)
at
org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.startClientNodes(TcpClientDiscoverySpiSelfTest.java:1850)
at
org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testJoinError(TcpClientDiscoverySpiSelfTest.java:1085)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method
[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&focusedCommentId=14946608#comment-14946608 ] Vladimir Ozerov commented on IGNITE-1555: - While patch looks fine, I still have doubts about the name. "Accelerator" appears to be too broad term. And the whole mission of Ignite is to "accelerate" jobs, data access, Hadoop, etc.. :-) > 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] [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=14946605#comment-14946605
]
Roman Shtykh commented on IGNITE-429:
-
Chandresh,
It seems you start Storm topology in StormIgniteStreamerSelfTest.java but don't
check the streamed values against the cache.
> 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=14946606#comment-14946606
]
Anton Vinogradov commented on IGNITE-429:
-
Chandresh,
is https://github.com/apache/ignite/pull/138 ready to be reviewed?
> 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=14946561#comment-14946561
]
Anton Vinogradov commented on IGNITE-429:
-
Chandresh,
Next time please update existing pull request instead of creation new one.
> 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=14946541#comment-14946541
]
Chandresh Pancholi commented on IGNITE-429:
---
GitHub user chandresh-pancholi opened a pull request:
https://github.com/apache/ignite/pull/138
[Ignite-429] Implement IgniteStormStreamer to stream data from Apache Storm
Added java1.7 compatibility and javadoc in StormSpout class.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/chandresh-pancholi/ignite master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/138.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #138
commit 7fa633cfb0cfb8144e780d9572a3a4fbe518bbd4
Author: chandresh pancholi
Date: 2015-10-07T08:52:12Z
Adding javadoc in StormSpout class and make streamer compatible with java1.7
> 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=14946505#comment-14946505
]
Chandresh Pancholi commented on IGNITE-429:
---
[~glutters] Tests are continuously timing out for me. Can you please check
again?
> 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] [Updated] (IGNITE-1623) We need handle crashing of agent on every step of loading metadata from DB
[ https://issues.apache.org/jira/browse/IGNITE-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-1623: --- Assignee: Vasiliy Sisko > We need handle crashing of agent on every step of loading metadata from DB > -- > > Key: IGNITE-1623 > URL: https://issues.apache.org/jira/browse/IGNITE-1623 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > Fix For: ignite-1.5 > > > We need to verify connection state on every step including fetching info > about scheme and tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1623) We need handle crashing of agent on every step of loading metadata from DB
Pavel Konstantinov created IGNITE-1623: -- Summary: We need handle crashing of agent on every step of loading metadata from DB Key: IGNITE-1623 URL: https://issues.apache.org/jira/browse/IGNITE-1623 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov We need to verify connection state on every step including fetching info about scheme and tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
