[jira] [Created] (IGNITE-3308) IGFS: Introduce separate processor for "move" operation when parent is the same for source and destination.
Vladimir Ozerov created IGNITE-3308:
---
Summary: IGFS: Introduce separate processor for "move" operation
when parent is the same for source and destination.
Key: IGNITE-3308
URL: https://issues.apache.org/jira/browse/IGNITE-3308
Project: Ignite
Issue Type: Sub-task
Components: IGFS
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 1.7
Consider the following operation: {{move("/parent/a", "parent/b")}}.
In this case we will call two entry processors:
{{IgfsMetaDirectoryListingRemoveProcessor}} to unlink "a" and
{{IgfsMetaDirectoryListingAddProcessor}} to link "b".
Instead, we should call only a single processor as source and destination keys
are the same. This will save network traffic and possibly decrease number of
remote calls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3151) Using IgniteCountDownLatch sometimes drives to dead lock.
[ https://issues.apache.org/jira/browse/IGNITE-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329031#comment-15329031 ] ASF GitHub Bot commented on IGNITE-3151: Github user vldpyatkov closed the pull request at: https://github.com/apache/ignite/pull/768 > Using IgniteCountDownLatch sometimes drives to dead lock. > - > > Key: IGNITE-3151 > URL: https://issues.apache.org/jira/browse/IGNITE-3151 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov > Attachments: igniteBugShot.zip > > > Run several serve node (recoment use count of CPU - 1). > Wait update topology. > Run client > After some iteration exception will thrown (In my case it take place after > around 10K iteration). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3151) Using IgniteCountDownLatch sometimes drives to dead lock.
[ https://issues.apache.org/jira/browse/IGNITE-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329039#comment-15329039 ] ASF GitHub Bot commented on IGNITE-3151: GitHub user vldpyatkov opened a pull request: https://github.com/apache/ignite/pull/796 IGNITE-3151 I rework fixation, so that there was no deadlock. IGNITE-3151 Using IgniteCountDownLatch sometimes drives to dead lock. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vldpyatkov/ignite ignite-3151 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/796.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 #796 commit 9b96febaeaa3e7858827c1d14330dc774723e305 Author: vdpyatkov Date: 2016-06-14T07:43:12Z I rework fixation, so that there was no deadlock. > Using IgniteCountDownLatch sometimes drives to dead lock. > - > > Key: IGNITE-3151 > URL: https://issues.apache.org/jira/browse/IGNITE-3151 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov > Attachments: igniteBugShot.zip > > > Run several serve node (recoment use count of CPU - 1). > Wait update topology. > Run client > After some iteration exception will thrown (In my case it take place after > around 10K iteration). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3294) IGFS: Merge create routine for PRIMARY and DUAL modes.
[ https://issues.apache.org/jira/browse/IGNITE-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3294. - Resolution: Fixed > IGFS: Merge create routine for PRIMARY and DUAL modes. > -- > > Key: IGNITE-3294 > URL: https://issues.apache.org/jira/browse/IGNITE-3294 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.7 > > > Currently during secondary file system synchronization we request multiple > paths in a separate "idsForPaths()" requests. > Instead, it is better to get all required IDs in a single request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3294) IGFS: Merge create routine for PRIMARY and DUAL modes.
[ https://issues.apache.org/jira/browse/IGNITE-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3294. --- > IGFS: Merge create routine for PRIMARY and DUAL modes. > -- > > Key: IGNITE-3294 > URL: https://issues.apache.org/jira/browse/IGNITE-3294 > Project: Ignite > Issue Type: Sub-task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.7 > > > Currently during secondary file system synchronization we request multiple > paths in a separate "idsForPaths()" requests. > Instead, it is better to get all required IDs in a single request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3308) IGFS: Introduce separate processor for "move" operation when parent is the same for source and destination.
[
https://issues.apache.org/jira/browse/IGNITE-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-3308.
---
> IGFS: Introduce separate processor for "move" operation when parent is the
> same for source and destination.
> ---
>
> Key: IGNITE-3308
> URL: https://issues.apache.org/jira/browse/IGNITE-3308
> Project: Ignite
> Issue Type: Sub-task
> Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Consider the following operation: {{move("/parent/a", "parent/b")}}.
> In this case we will call two entry processors:
> {{IgfsMetaDirectoryListingRemoveProcessor}} to unlink "a" and
> {{IgfsMetaDirectoryListingAddProcessor}} to link "b".
> Instead, we should call only a single processor as source and destination
> keys are the same. This will save network traffic and possibly decrease
> number of remote calls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3308) IGFS: Introduce separate processor for "move" operation when parent is the same for source and destination.
[
https://issues.apache.org/jira/browse/IGNITE-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-3308.
-
Resolution: Fixed
> IGFS: Introduce separate processor for "move" operation when parent is the
> same for source and destination.
> ---
>
> Key: IGNITE-3308
> URL: https://issues.apache.org/jira/browse/IGNITE-3308
> Project: Ignite
> Issue Type: Sub-task
> Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.7
>
>
> Consider the following operation: {{move("/parent/a", "parent/b")}}.
> In this case we will call two entry processors:
> {{IgfsMetaDirectoryListingRemoveProcessor}} to unlink "a" and
> {{IgfsMetaDirectoryListingAddProcessor}} to link "b".
> Instead, we should call only a single processor as source and destination
> keys are the same. This will save network traffic and possibly decrease
> number of remote calls.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3309) Web console: incorrect validator
Pavel Konstantinov created IGNITE-3309: -- Summary: Web console: incorrect validator Key: IGNITE-3309 URL: https://issues.apache.org/jira/browse/IGNITE-3309 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Assignee: Dmitriyff # Clusters -> Communication -> Unacknowledged messages # set value = 1 # Save - error message appear but the fields is not with a red frame -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3309) Web console: incorrect validator
[ https://issues.apache.org/jira/browse/IGNITE-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-3309: --- Attachment: ig-3309.png > Web console: incorrect validator > > > Key: IGNITE-3309 > URL: https://issues.apache.org/jira/browse/IGNITE-3309 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Dmitriyff > Attachments: ig-3309.png > > > # Clusters -> Communication -> Unacknowledged messages > # set value = 1 > # Save - error message appear but the fields is not with a red frame -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3309) Web console: incorrect validator
[ https://issues.apache.org/jira/browse/IGNITE-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-3309: --- Description: # Clusters -> Communication -> Unacknowledged messages # set value = 1 # Save - error message appear but the fields is not with a red frame Also please verify the tooltip for this field was: # Clusters -> Communication -> Unacknowledged messages # set value = 1 # Save - error message appear but the fields is not with a red frame > Web console: incorrect validator > > > Key: IGNITE-3309 > URL: https://issues.apache.org/jira/browse/IGNITE-3309 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Dmitriyff > Attachments: ig-3309.png > > > # Clusters -> Communication -> Unacknowledged messages > # set value = 1 > # Save - error message appear but the fields is not with a red frame > Also please verify the tooltip for this field -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3310) Need to document Visor scripting capabilities
Valentin Kulichenko created IGNITE-3310: --- Summary: Need to document Visor scripting capabilities Key: IGNITE-3310 URL: https://issues.apache.org/jira/browse/IGNITE-3310 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 1.6 Reporter: Valentin Kulichenko Assignee: Alexey Kuznetsov Fix For: 1.7 The functionality was added in scope of IGNITE-185, but it's not documented yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3272) Memory consumption in ContinuousQueryHandler
[ https://issues.apache.org/jira/browse/IGNITE-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329282#comment-15329282 ] Semen Boikov commented on IGNITE-3272: -- Reviewed, I think 'isFiltered()' check is needed in CacheContinuousQueryEntry.writeTo. Why it was removed? Thanks > Memory consumption in ContinuousQueryHandler > > > Key: IGNITE-3272 > URL: https://issues.apache.org/jira/browse/IGNITE-3272 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolay Tikhonov >Assignee: Nikolay Tikhonov > Attachments: IgniteCacheContinuousQueryBackupQueueTest.java > > > On backup nodes events put in queue with value and key. For filtered events > need to store only update counter and partition. In attached test which > should pass with -Xmx2g -Xms2g -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3272) Memory consumption in ContinuousQueryHandler
[ https://issues.apache.org/jira/browse/IGNITE-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329293#comment-15329293 ] Nikolay Tikhonov commented on IGNITE-3272: -- Thank you for your review! Yes, you're right. This condition still useful for some cases. I'll recover these changes. > Memory consumption in ContinuousQueryHandler > > > Key: IGNITE-3272 > URL: https://issues.apache.org/jira/browse/IGNITE-3272 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolay Tikhonov >Assignee: Nikolay Tikhonov > Attachments: IgniteCacheContinuousQueryBackupQueueTest.java > > > On backup nodes events put in queue with value and key. For filtered events > need to store only update counter and partition. In attached test which > should pass with -Xmx2g -Xms2g -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3286) .NET: Remove static Logger class
[ https://issues.apache.org/jira/browse/IGNITE-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-3286. Resolution: Done > .NET: Remove static Logger class > > > Key: IGNITE-3286 > URL: https://issues.apache.org/jira/browse/IGNITE-3286 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > QueryEntity validation should be refactored to use new ILogger -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3286) .NET: Remove static Logger class
[ https://issues.apache.org/jira/browse/IGNITE-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-3286. -- > .NET: Remove static Logger class > > > Key: IGNITE-3286 > URL: https://issues.apache.org/jira/browse/IGNITE-3286 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > QueryEntity validation should be refactored to use new ILogger -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3284) .NET Composite Logger
[ https://issues.apache.org/jira/browse/IGNITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-3284. -- > .NET Composite Logger > - > > Key: IGNITE-3284 > URL: https://issues.apache.org/jira/browse/IGNITE-3284 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > Provide a way to combine multiple loggers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3284) .NET Composite Logger
[ https://issues.apache.org/jira/browse/IGNITE-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-3284. Resolution: Won't Fix This is barely needed, and very simple to implement by the user. Won't fix. > .NET Composite Logger > - > > Key: IGNITE-3284 > URL: https://issues.apache.org/jira/browse/IGNITE-3284 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > Provide a way to combine multiple loggers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.
[ https://issues.apache.org/jira/browse/IGNITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329580#comment-15329580 ] ASF GitHub Bot commented on IGNITE-1443: GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/800 IGNITE-1443: Implemented ContinuousQuery. You can merge this pull request into a Git repository by running: $ git pull https://github.com/isapego/ignite ignite-1443 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/800.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 #800 commit 2ecb8221992d2487509a57493fd40fb9bbd5a5f7 Author: isapego Date: 2016-06-08T15:12:29Z IGNITE-1443: Implemented CacheEntryEventListener and ContinuousQuery. commit c6bca10cdc0405aae9255d4c8b601d8db3bb51c1 Author: isapego Date: 2016-06-08T16:58:29Z IGNITE-1443: Added ContinuousQueryHandle. commit 633fa9af4fcde078fd962e464fbf28a4777b1799 Author: isapego Date: 2016-06-08T17:10:12Z IGNITE-1443: Mistake in the comment fixed. commit 798673bce4201027c514afa6f55cb3dcac46d159 Author: isapego Date: 2016-06-09T13:30:25Z IGNITE-1443: Implemented CacheEntryEvent. commit cb9f55cfc2c6598f0a88ddae0f9ecacf25f29acd Author: isapego Date: 2016-06-10T12:39:31Z IGNITE-1443: Added tests. commit 632b2d654aeb94e43f9c8aa331562e56adf839f2 Author: isapego Date: 2016-06-10T15:29:22Z IGNITE-1443: Test added. commit 6e31605b4b5e65ad04773cf0717fa5450d0a5b75 Author: isapego Date: 2016-06-10T15:30:52Z Merge branch 'master' into ignite-1443 commit 992331ecdea749884026fecfadceffde56131290 Author: isapego Date: 2016-06-10T19:37:59Z IGNITE-1443: Implemented initial query. commit 835f65cd1d808f6f0ee7a720537e8cadb0dff0af Author: isapego Date: 2016-06-14T11:41:54Z IGNITE-1443: Added tests for initial query. commit 22f526131168a3aafe6e10c2c461192f242a7385 Author: isapego Date: 2016-06-14T11:51:34Z IGNITE-1443: Minor refactoring for tests. commit 5e3a86e3f10306d969ea958087ec1c2c647c92f8 Author: isapego Date: 2016-06-14T12:00:46Z IGNITE-1443: Configuration simplyfied. commit 431e08dd9023db1dc39f8e517cb3c8f483fe5230 Author: isapego Date: 2016-06-14T12:08:41Z IGNITE-1443: Added tests for no-except version of functions. commit 5243a3212ab01c57c8d7e7149fff5938e06ad65b Author: isapego Date: 2016-06-14T12:13:58Z IGNITE-1443: Boost libraries cleanup. commit 7bdf0ef1835e5cc6ca6c0c54dbfc7c81742a30fc Author: isapego Date: 2016-06-14T14:25:29Z IGNITE-1443: Documentation and other minor fixes. > CPP: Implement cache continuous queries. > > > Key: IGNITE-1443 > URL: https://issues.apache.org/jira/browse/IGNITE-1443 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Critical > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2938) IgfsBackupsDualAsyncSelfTest.testAppendParentMissing and IgfsBackupsDualAsyncSelfTest.testAppendParentMissingPartially fail sometimes on master
[
https://issues.apache.org/jira/browse/IGNITE-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-2938.
-
Resolution: Fixed
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissing and
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissingPartially fail sometimes
> on master
> ---
>
> Key: IGNITE-2938
> URL: https://issues.apache.org/jira/browse/IGNITE-2938
> Project: Ignite
> Issue Type: Test
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 1.7
>
>
> Tests
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissing
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissingPartially
> fail from time to time on master -- need to investigate.
> It looks like that started to happen after fix
> https://issues.apache.org/jira/browse/IGNITE-1631 .
> The failure happens with probability ~1/50 :
> {code}
> [18:14:50,772][INFO ][main][root] >>> Starting test:
> IgfsBackupsDualAsyncSelfTest#testAppendParentMissingPartially <<<
> [18:14:50,792][ERROR][main][root] Test failed.
> java.io.IOException: Inconsistent file's data block (incorrectly written?)
> [path=/dir/subdir/file, blockIdx=0, blockSize=128, expectedBlockSize=256,
> fileBlockSize=524288, fileLen=256]
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.block(IgfsInputStreamImpl.java:485)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.blockFragmentizerSafe(IgfsInputStreamImpl.java:399)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.readFromStore(IgfsInputStreamImpl.java:373)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.readFully(IgfsInputStreamImpl.java:222)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.readFully(IgfsInputStreamImpl.java:216)
> at
> org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.checkFileContent(IgfsAbstractSelfTest.java:2999)
> at
> org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.checkFile(IgfsAbstractSelfTest.java:2969)
> at
> org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest.testAppendParentMissingPartially(IgfsDualAbstractSelfTest.java:1364)
> at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 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:1759)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1697)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2938) IgfsBackupsDualAsyncSelfTest.testAppendParentMissing and IgfsBackupsDualAsyncSelfTest.testAppendParentMissingPartially fail sometimes on master
[
https://issues.apache.org/jira/browse/IGNITE-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-2938.
---
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissing and
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissingPartially fail sometimes
> on master
> ---
>
> Key: IGNITE-2938
> URL: https://issues.apache.org/jira/browse/IGNITE-2938
> Project: Ignite
> Issue Type: Test
> Components: IGFS
>Affects Versions: 1.5.0.final
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 1.7
>
>
> Tests
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissing
> IgfsBackupsDualAsyncSelfTest.testAppendParentMissingPartially
> fail from time to time on master -- need to investigate.
> It looks like that started to happen after fix
> https://issues.apache.org/jira/browse/IGNITE-1631 .
> The failure happens with probability ~1/50 :
> {code}
> [18:14:50,772][INFO ][main][root] >>> Starting test:
> IgfsBackupsDualAsyncSelfTest#testAppendParentMissingPartially <<<
> [18:14:50,792][ERROR][main][root] Test failed.
> java.io.IOException: Inconsistent file's data block (incorrectly written?)
> [path=/dir/subdir/file, blockIdx=0, blockSize=128, expectedBlockSize=256,
> fileBlockSize=524288, fileLen=256]
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.block(IgfsInputStreamImpl.java:485)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.blockFragmentizerSafe(IgfsInputStreamImpl.java:399)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.readFromStore(IgfsInputStreamImpl.java:373)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.readFully(IgfsInputStreamImpl.java:222)
> at
> org.apache.ignite.internal.processors.igfs.IgfsInputStreamImpl.readFully(IgfsInputStreamImpl.java:216)
> at
> org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.checkFileContent(IgfsAbstractSelfTest.java:2999)
> at
> org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.checkFile(IgfsAbstractSelfTest.java:2969)
> at
> org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest.testAppendParentMissingPartially(IgfsDualAbstractSelfTest.java:1364)
> at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> 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:1759)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1697)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-1631) IGFS: append fails to create a new file in DUAL modes
[ https://issues.apache.org/jira/browse/IGNITE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Veselovsky resolved IGNITE-1631. - This problem is fixed in 1.7+ (master branch). It was not fixed in gg-7.5.26 . It can potentially be backported to those branches , but likely not alone but with a bunch of other IGFS fixes it depends on. > 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 > Labels: community > Fix For: 1.7 > > > 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] [Closed] (IGNITE-3302) .NET: Inject resources into user ILogger
[ https://issues.apache.org/jira/browse/IGNITE-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn closed IGNITE-3302. -- > .NET: Inject resources into user ILogger > > > Key: IGNITE-3302 > URL: https://issues.apache.org/jira/browse/IGNITE-3302 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3302) .NET: Inject resources into user ILogger
[ https://issues.apache.org/jira/browse/IGNITE-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-3302. Resolution: Done > .NET: Inject resources into user ILogger > > > Key: IGNITE-3302 > URL: https://issues.apache.org/jira/browse/IGNITE-3302 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.7 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3216) Need to deduplicate addresses registered in the IP finder
[
https://issues.apache.org/jira/browse/IGNITE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329646#comment-15329646
]
Valentin Kulichenko commented on IGNITE-3216:
-
{{viewSetReadOnly}} is not used anymore, so I would prefer to remove it
completely. Otherwise, looks good.
> Need to deduplicate addresses registered in the IP finder
> -
>
> Key: IGNITE-3216
> URL: https://issues.apache.org/jira/browse/IGNITE-3216
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> {{IgniteUtils.toSocketAddresses(...)}} method can produce the collection with
> duplicated addresses in some cases (e.g., if one of hostnames is provided as
> an IP). We should deduplicate the list before returning it (most likely we
> should simply use {{Set}} instead).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3152) Client node's addresses are registered in IP finder
[
https://issues.apache.org/jira/browse/IGNITE-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329667#comment-15329667
]
Valentin Kulichenko commented on IGNITE-3152:
-
Yes, you're right, but this means that one the places in the code is incorrect
:) Why we have the {{TcpDiscoveryIpFinderAdapter.discoveryClientMode()}} method
then?
I'm actually not sure that it's correct to return {{false}} from
{{ClusterNode.isClient()}} method in case it's actually a client, but with
forced server mode on discovery level.
Should this be discussed on dev@?
> Client node's addresses are registered in IP finder
> ---
>
> Key: IGNITE-3152
> URL: https://issues.apache.org/jira/browse/IGNITE-3152
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Labels: important
> Fix For: 1.7
>
> Attachments: Test.java
>
>
> Currently client node register its addresses in IP finder and never
> deregisters them. Also looks like coordinator address is also not removed.
> The simple test that shows this behavior is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1629) .Net: Introduce native logging facility.
[ https://issues.apache.org/jira/browse/IGNITE-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329678#comment-15329678 ] Pavel Tupitsyn commented on IGNITE-1629: Resulting implementation: * Java: PlatformLogger is set automatically if there is no logger configured * PlatformLogger delegates everything through JNI. isQuiet always returns false so that there is no console output in Java * .NET: Added an ILogger interface and a ConsoleLogger implementation that is used by default. * All custom logging (file, windows log, database, etc) is expected to be done via 3rd party integrations > .Net: Introduce native logging facility. > > > Key: IGNITE-1629 > URL: https://issues.apache.org/jira/browse/IGNITE-1629 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Pavel Tupitsyn >Priority: Blocker > > 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] [Closed] (IGNITE-3272) Memory consumption in ContinuousQueryHandler
[ https://issues.apache.org/jira/browse/IGNITE-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Tikhonov closed IGNITE-3272. > Memory consumption in ContinuousQueryHandler > > > Key: IGNITE-3272 > URL: https://issues.apache.org/jira/browse/IGNITE-3272 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolay Tikhonov >Assignee: Nikolay Tikhonov > Attachments: IgniteCacheContinuousQueryBackupQueueTest.java > > > On backup nodes events put in queue with value and key. For filtered events > need to store only update counter and partition. In attached test which > should pass with -Xmx2g -Xms2g -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3311) .NET: Include configuration schema in NuGet package
Pavel Tupitsyn created IGNITE-3311: -- Summary: .NET: Include configuration schema in NuGet package Key: IGNITE-3311 URL: https://issues.apache.org/jira/browse/IGNITE-3311 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 1.6 Reporter: Pavel Tupitsyn Fix For: 1.7 See how NLog does it with NLog.Schema package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3311) .NET: Include configuration schema in NuGet package
[ https://issues.apache.org/jira/browse/IGNITE-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-3311: --- Description: See how NLog does it with NLog.Schema package. Make sure IntelliSense picks it up for the user. (was: See how NLog does it with NLog.Schema package.) > .NET: Include configuration schema in NuGet package > --- > > Key: IGNITE-3311 > URL: https://issues.apache.org/jira/browse/IGNITE-3311 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn > Fix For: 1.7 > > > See how NLog does it with NLog.Schema package. Make sure IntelliSense picks > it up for the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3311) .NET: Include configuration schema in NuGet package
[ https://issues.apache.org/jira/browse/IGNITE-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-3311: -- Assignee: Pavel Tupitsyn > .NET: Include configuration schema in NuGet package > --- > > Key: IGNITE-3311 > URL: https://issues.apache.org/jira/browse/IGNITE-3311 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > See how NLog does it with NLog.Schema package. Make sure IntelliSense picks > it up for the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2680) Terminating running SQL queries
[
https://issues.apache.org/jira/browse/IGNITE-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329891#comment-15329891
]
Alexei Scherbakov commented on IGNITE-2680:
---
It looks like everything in place.
Scheduled TC run.
PR: https://github.com/apache/ignite/pull/802
> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
> Labels: important
>
> If to start a long running SQL query over a huge cache will millions of
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1443) CPP: Implement cache continuous queries.
[ https://issues.apache.org/jira/browse/IGNITE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-1443: Assignee: Vladimir Ozerov (was: Igor Sapego) > CPP: Implement cache continuous queries. > > > Key: IGNITE-1443 > URL: https://issues.apache.org/jira/browse/IGNITE-1443 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 1.7 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3311) .NET: Include configuration schema in NuGet package
[ https://issues.apache.org/jira/browse/IGNITE-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-3311: --- Description: See how NLog does it with NLog.Schema package. Make sure IntelliSense picks it up for the user. To avoid forcing extra content files on the user, separate NuGet package should be created. was:See how NLog does it with NLog.Schema package. Make sure IntelliSense picks it up for the user. > .NET: Include configuration schema in NuGet package > --- > > Key: IGNITE-3311 > URL: https://issues.apache.org/jira/browse/IGNITE-3311 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.7 > > > See how NLog does it with NLog.Schema package. Make sure IntelliSense picks > it up for the user. > To avoid forcing extra content files on the user, separate NuGet package > should be created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3312) [Test] HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution flakily fails.
Ivan Veselovsky created IGNITE-3312:
---
Summary: [Test]
HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution flakily
fails.
Key: IGNITE-3312
URL: https://issues.apache.org/jira/browse/IGNITE-3312
Project: Ignite
Issue Type: Bug
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution fails
with ~20% probability .
Failure cause is either the 1st or 2nd marked line in the following code
(org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create) :
{code}
// Check: can we overwrite it?
if (!overwrite)
throw new
IgfsPathAlreadyExistsException("Failed to create a file: " + path); // * #1
// Check if file already opened for write.
if (oldInfo.lockId() != null)
throw new IgfsException("File is already opened
for write: " + path); // * #2
{code}
Diagnostic shows that the same file really attempted to be created several
times on one thread.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3313) Make table name optional in Cassandra persistence descriptor
Igor Rudyak created IGNITE-3313: --- Summary: Make table name optional in Cassandra persistence descriptor Key: IGNITE-3313 URL: https://issues.apache.org/jira/browse/IGNITE-3313 Project: Ignite Issue Type: Sub-task Components: cache Reporter: Igor Rudyak Assignee: Igor Rudyak Priority: Minor Table name should be optional in Cassandra persistence descriptor. If table name is not specified lowercase of cache name should be used as a table name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3312) [Test] HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution flakily fails.
[
https://issues.apache.org/jira/browse/IGNITE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Veselovsky updated IGNITE-3312:
Labels: test (was: )
Component/s: IGFS
> [Test]
> HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution
> flakily fails.
> -
>
> Key: IGNITE-3312
> URL: https://issues.apache.org/jira/browse/IGNITE-3312
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Labels: test
>
> HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution fails
> with ~20% probability .
> Failure cause is either the 1st or 2nd marked line in the following code
> (org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create) :
> {code}
> // Check: can we overwrite it?
> if (!overwrite)
> throw new
> IgfsPathAlreadyExistsException("Failed to create a file: " + path); // *
> #1
> // Check if file already opened for write.
> if (oldInfo.lockId() != null)
> throw new IgfsException("File is already
> opened for write: " + path); // * #2
> {code}
> Diagnostic shows that the same file really attempted to be created several
> times on one thread.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3314) Implement Serializable in org.apache.ignite.cache.store.cassandra.datasource.DataSource
Igor Rudyak created IGNITE-3314: --- Summary: Implement Serializable in org.apache.ignite.cache.store.cassandra.datasource.DataSource Key: IGNITE-3314 URL: https://issues.apache.org/jira/browse/IGNITE-3314 Project: Ignite Issue Type: Sub-task Components: cache Reporter: Igor Rudyak Assignee: Igor Rudyak Priority: Minor Current implementation of org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource doesn't implement Serializable, thus for distributed Ignite clusters, CassandraCacheStoreFactory could only be setup through Spring XML file, but not from code. New version of org.apache.ignite.cache.store.cassandra.utils.datasource.DataSource should implement Serializable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3315) CPP: Add documentation for ContinuousQuery API
Igor Sapego created IGNITE-3315: --- Summary: CPP: Add documentation for ContinuousQuery API Key: IGNITE-3315 URL: https://issues.apache.org/jira/browse/IGNITE-3315 Project: Ignite Issue Type: Task Components: documentation, platforms Affects Versions: 1.6 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 1.7 We are going to add CountinuousQuery API to Ignite C++ with IGNITE-1443 so we also need to add documentation section to readme.io on this topic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3312) [Test] HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution flakily fails.
[
https://issues.apache.org/jira/browse/IGNITE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Veselovsky updated IGNITE-3312:
Description:
HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution fails
with ~20% probability .
Failure cause is either the 1st or 2nd marked line in the following code
(org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create) :
{code}
// Check: can we overwrite it?
if (!overwrite)
throw new
IgfsPathAlreadyExistsException("Failed to create a file: " + path); // * #1
// Check if file already opened for write.
if (oldInfo.lockId() != null)
throw new IgfsException("File is already opened
for write: " + path); // * #2
{code}
Diagnostic shows that the same file really attempted to be created several
times on one thread.
Situation #2 reproducible with the following stack when IGFS is used as a
secondary fs:
{code}
Hadoop-task-efea2ae1-09cb-4c49-9465-dcbbedee1835_1-REDUCE-2-0-#679%hadoop.HadoopMapReduceEmbeddedSelfTest2%@20675,
prio=5, in group 'ignite', status: 'RUNNING'
at
org.apache.ignite.internal.processors.igfs.IgfsMetaManager.create(IgfsMetaManager.java:2857)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1051)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:1823)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create0(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create(IgfsImpl.java:990)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:359)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:357)
at
org.apache.ignite.igfs.IgfsUserContext.doAs(IgfsUserContext.java:49)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc.create(HadoopIgfsInProc.java:357)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:258)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.withReconnectHandling(HadoopIgfsWrapper.java:310)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.create(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.create(IgniteHadoopFileSystem.java:632)
at
org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.create(IgniteHadoopIgfsSecondaryFileSystem.java:406)
at
org.apache.ignite.internal.processors.igfs.IgfsSecondaryFileSystemCreateContext.create(IgfsSecondaryFileSystemCreateContext.java:87)
at
org.apache.ignite.internal.processors.igfs.IgfsMetaManager.create(IgfsMetaManager.java:2922)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1051)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:1823)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create0(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create(IgfsImpl.java:990)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:359)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:357)
at
org.apache.ignite.igfs.IgfsUserContext.doAs(IgfsUserContext.java:54)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc.create(HadoopIgfsInProc.java:357)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:258)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.withReconnectHandling(HadoopIgfsWrapper.java:310)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.create(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.create(IgniteHadoopFileSystem.java:632)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:906)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:799)
at
org.apache.hadoop.mapred.TextOutputFormat.getReco
[jira] [Updated] (IGNITE-3312) [Test] HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution flakily fails.
[
https://issues.apache.org/jira/browse/IGNITE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Veselovsky updated IGNITE-3312:
Description:
HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution fails
with ~20% probability .
Failure cause is either the 1st or 2nd marked line in the following code
(org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create) :
{code}
// Check: can we overwrite it?
if (!overwrite)
throw new
IgfsPathAlreadyExistsException("Failed to create a file: " + path); // * #1
// Check if file already opened for write.
if (oldInfo.lockId() != null)
throw new IgfsException("File is already opened
for write: " + path); // * #2
{code}
Diagnostic shows that the same file really attempted to be created several
times on one thread.
Situation #2 reproducible with the following stack when IGFS is used as a
secondary fs:
{code}
Hadoop-task-efea2ae1-09cb-4c49-9465-dcbbedee1835_1-REDUCE-2-0-#679%hadoop.HadoopMapReduceEmbeddedSelfTest2%@20675,
prio=5, in group 'ignite', status: 'RUNNING'
at
org.apache.ignite.internal.processors.igfs.IgfsMetaManager.create(IgfsMetaManager.java:2857)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1051)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:1823)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create0(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create(IgfsImpl.java:990)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:359)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:357)
at
org.apache.ignite.igfs.IgfsUserContext.doAs(IgfsUserContext.java:49)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc.create(HadoopIgfsInProc.java:357)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:258)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.withReconnectHandling(HadoopIgfsWrapper.java:310)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.create(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.create(IgniteHadoopFileSystem.java:632)
at
org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.create(IgniteHadoopIgfsSecondaryFileSystem.java:406)
at
org.apache.ignite.internal.processors.igfs.IgfsSecondaryFileSystemCreateContext.create(IgfsSecondaryFileSystemCreateContext.java:87)
at
org.apache.ignite.internal.processors.igfs.IgfsMetaManager.create(IgfsMetaManager.java:2922)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1051)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:1823)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create0(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create(IgfsImpl.java:990)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:359)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:357)
at
org.apache.ignite.igfs.IgfsUserContext.doAs(IgfsUserContext.java:54)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc.create(HadoopIgfsInProc.java:357)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:258)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.withReconnectHandling(HadoopIgfsWrapper.java:310)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.create(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.create(IgniteHadoopFileSystem.java:632)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:906)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:799)
at
org.apache.hadoop.mapred.TextOutputFormat.getReco
[jira] [Updated] (IGNITE-3312) [Test] HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution flakily fails.
[
https://issues.apache.org/jira/browse/IGNITE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Veselovsky updated IGNITE-3312:
Description:
HadoopMapReduceEmbeddedSelfTest.testMultiReducerWholeMapReduceExecution fails
with ~20% probability .
Failure cause is either the 1st or 2nd marked line in the following code
(org.apache.ignite.internal.processors.igfs.IgfsMetaManager#create) :
{code}
// Check: can we overwrite it?
if (!overwrite)
throw new
IgfsPathAlreadyExistsException("Failed to create a file: " + path); // * #1
// Check if file already opened for write.
if (oldInfo.lockId() != null)
throw new IgfsException("File is already opened
for write: " + path); // * #2
{code}
Diagnostic shows that the same file really attempted to be created several
times on one thread.
Situation #2 reproducible with the following stack when IGFS is used as a
secondary fs:
{code}
Hadoop-task-efea2ae1-09cb-4c49-9465-dcbbedee1835_1-REDUCE-2-0-#679%hadoop.HadoopMapReduceEmbeddedSelfTest2%@20675,
prio=5, in group 'ignite', status: 'RUNNING'
at
org.apache.ignite.internal.processors.igfs.IgfsMetaManager.create(IgfsMetaManager.java:2857)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1051)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:1823)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create0(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create(IgfsImpl.java:990)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:359)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:357)
at
org.apache.ignite.igfs.IgfsUserContext.doAs(IgfsUserContext.java:49)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc.create(HadoopIgfsInProc.java:357)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:258)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.withReconnectHandling(HadoopIgfsWrapper.java:310)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.create(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.create(IgniteHadoopFileSystem.java:632)
at
org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.create(IgniteHadoopIgfsSecondaryFileSystem.java:406)
at
org.apache.ignite.internal.processors.igfs.IgfsSecondaryFileSystemCreateContext.create(IgfsSecondaryFileSystemCreateContext.java:87)
at
org.apache.ignite.internal.processors.igfs.IgfsMetaManager.create(IgfsMetaManager.java:2922)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1051)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl$15.call(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:1823)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create0(IgfsImpl.java:1019)
at
org.apache.ignite.internal.processors.igfs.IgfsImpl.create(IgfsImpl.java:990)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:359)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc$15.apply(HadoopIgfsInProc.java:357)
at
org.apache.ignite.igfs.IgfsUserContext.doAs(IgfsUserContext.java:54)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsInProc.create(HadoopIgfsInProc.java:357)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:258)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper$15.apply(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.withReconnectHandling(HadoopIgfsWrapper.java:310)
at
org.apache.ignite.internal.processors.hadoop.igfs.HadoopIgfsWrapper.create(HadoopIgfsWrapper.java:255)
at
org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.create(IgniteHadoopFileSystem.java:632)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:906)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:799)
at
org.apache.hadoop.mapred.TextOutputFormat.getReco
[jira] [Commented] (IGNITE-3239) "Failed to write class name to file xxxxx.classname" error when several clients and server are running at one host
[
https://issues.apache.org/jira/browse/IGNITE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330058#comment-15330058
]
Andrey Gura commented on IGNITE-3239:
-
I need more logs for problem analysis. But it seems that actually there are no
any deadlocks. In some cases OS makes wrong assumptions about deadlock
existance because tries to detect deadlock on processes (not threads) level. So
if different threads in one process lock some files and different threads in
other process trying to lock the same files it is possible that OS will detect
deadlock. See for example https://gist.github.com/harrah/4714661
As work around we can use {{tryLock}} method and repeat in case of fail instead
of using blocking {{lock}} method.
> "Failed to write class name to file x.classname" error when several
> clients and server are running at one host
> --
>
> Key: IGNITE-3239
> URL: https://issues.apache.org/jira/browse/IGNITE-3239
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Andrey Gura
>Priority: Minor
>
> During load test with 4 clients and 1 server per host (total 4 servers) the
> following errors occur on server and client sides:
> {noformat}
> [06:02:28,418][ERROR][marshaller-cache-#96%null%][MarshallerContextImpl]
> Failed to write class name to file [id=1023271795,
> clsName=o.a.i.yardstick.cache.load.model.key.Identifier,
> file=/home/gridgain/krybakova/opts-set-b-0-m-client-rev-3c3ed056-date-0206-060158/yardstick/work/marshaller/1023271795.classname]
> java.io.IOException: Resource deadlock avoided
> at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1052)
> at
> org.apache.ignite.internal.MarshallerContextImpl$ContinuousQueryListener.onUpdated(MarshallerContextImpl.java:236)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:769)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2167)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2250)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1644)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1484)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2945)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:129)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:260)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:258)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoMa
[jira] [Comment Edited] (IGNITE-3209) Need to wait for affinity assignment change during affinityCall failover
[
https://issues.apache.org/jira/browse/IGNITE-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329921#comment-15329921
]
Andrey Gura edited comment on IGNITE-3209 at 6/14/16 6:16 PM:
--
Fixed. TC looks good. Please review.
was (Author: agura):
Please review.
> Need to wait for affinity assignment change during affinityCall failover
>
>
> Key: IGNITE-3209
> URL: https://issues.apache.org/jira/browse/IGNITE-3209
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> {{AlwaysFailoverSpi.failover()}} method makes several attempts (5 by default)
> to get new primary node for the affinity key. Affinity assignment takes time,
> so there is a big chance to make all these attempts before new node is
> returned.
> We need to add discovery event that initiated failover to {{FailoverContext}}
> and wait for affinity is assigned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-3239) "Failed to write class name to file xxxxx.classname" error when several clients and server are running at one host
[
https://issues.apache.org/jira/browse/IGNITE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330058#comment-15330058
]
Andrey Gura edited comment on IGNITE-3239 at 6/14/16 6:22 PM:
--
I need more informaton for problem analysis. But it seems that actually there
are no any deadlocks. In some cases OS makes wrong assumptions about deadlock
existance because tries to detect deadlock on processes (not threads) level. So
if different threads in one process lock some files and different threads in
other process trying to lock the same files it is possible that OS will detect
deadlock. See for example https://gist.github.com/harrah/4714661
As work around we can use {{tryLock}} method and repeat in case of fail instead
of using blocking {{lock}} method.
was (Author: agura):
I need more logs for problem analysis. But it seems that actually there are no
any deadlocks. In some cases OS makes wrong assumptions about deadlock
existance because tries to detect deadlock on processes (not threads) level. So
if different threads in one process lock some files and different threads in
other process trying to lock the same files it is possible that OS will detect
deadlock. See for example https://gist.github.com/harrah/4714661
As work around we can use {{tryLock}} method and repeat in case of fail instead
of using blocking {{lock}} method.
> "Failed to write class name to file x.classname" error when several
> clients and server are running at one host
> --
>
> Key: IGNITE-3239
> URL: https://issues.apache.org/jira/browse/IGNITE-3239
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Ksenia Rybakova
>Assignee: Andrey Gura
>Priority: Minor
>
> During load test with 4 clients and 1 server per host (total 4 servers) the
> following errors occur on server and client sides:
> {noformat}
> [06:02:28,418][ERROR][marshaller-cache-#96%null%][MarshallerContextImpl]
> Failed to write class name to file [id=1023271795,
> clsName=o.a.i.yardstick.cache.load.model.key.Identifier,
> file=/home/gridgain/krybakova/opts-set-b-0-m-client-rev-3c3ed056-date-0206-060158/yardstick/work/marshaller/1023271795.classname]
> java.io.IOException: Resource deadlock avoided
> at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)
> at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1052)
> at
> org.apache.ignite.internal.MarshallerContextImpl$ContinuousQueryListener.onUpdated(MarshallerContextImpl.java:236)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:769)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2167)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2250)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1644)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1484)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2945)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:129)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:260)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:258)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
> at
> org.apache.ignite.internal.processors.cache
[jira] [Resolved] (IGNITE-3273) SQL query parse error on map query side
[
https://issues.apache.org/jira/browse/IGNITE-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergi Vladykin resolved IGNITE-3273.
Resolution: Fixed
merged to master
> SQL query parse error on map query side
> ---
>
> Key: IGNITE-3273
> URL: https://issues.apache.org/jira/browse/IGNITE-3273
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Alexei Scherbakov
> Fix For: 1.7
>
> Attachments: Example2.java
>
>
> Distributed SQL query cannot be parsed on map side if it contains left join.
> The same local query works without any error.
> Replacing left join with inner join removes the error.
> See the attachment for the reproducer.
> {noformat}
> [10:40:58,850][ERROR][main][GridMapQueryExecutor] Failed to execute local
> query: GridQueryRequest [reqId=1, pageSize=1024, space=P,
> qrys=[GridCacheSqlQuery [qry=SELECT
> PERSON._KEY __C0,
> PERSON._VAL __C1,
> PERSON.NAME __C2,
> PERSON.ID __C3,
> PERSON.DEPID __C4,
> DEP._KEY __C5,
> DEP._VAL __C6,
> DEP.NAME __C7,
> DEP.ID __C8,
> DEP.ORGID __C9,
> ORG._KEY __C10,
> ORG._VAL __C11,
> ORG.NAME __C12,
> ORG.ID __C13
> FROM P.PERSON
> INNER JOIN D.DEPARTMENT DEP
> LEFT OUTER JOIN O.ORG ORG
> ON ORG.ID = DEP.ORGID
> WHERE DEP.ID = P.PERSON.DEPID, params=[], paramIdxs=[], paramsSize=0,
> cols={__C0=GridSqlType [type=4, scale=0, precision=10, displaySize=11,
> sql=INTEGER], __C1=GridSqlType [type=19, scale=0, precision=2147483647,
> displaySize=2147483647, sql=OTHER], __C2=GridSqlType [type=13, scale=0,
> precision=2147483647, displaySize=2147483647, sql=VARCHAR], __C3=GridSqlType
> [type=4, scale=0, precision=10, displaySize=11, sql=INTEGER],
> __C4=GridSqlType [type=4, scale=0, precision=10, displaySize=11,
> sql=INTEGER], __C5=GridSqlType [type=4, scale=0, precision=10,
> displaySize=11, sql=INTEGER], __C6=GridSqlType [type=19, scale=0,
> precision=2147483647, displaySize=2147483647, sql=OTHER], __C7=GridSqlType
> [type=13, scale=0, precision=2147483647, displaySize=2147483647,
> sql=VARCHAR], __C8=GridSqlType [type=4, scale=0, precision=10,
> displaySize=11, sql=INTEGER], __C9=GridSqlType [type=4, scale=0,
> precision=10, displaySize=11, sql=INTEGER], __C10=GridSqlType [type=4,
> scale=0, precision=10, displaySize=11, sql=INTEGER], __C11=GridSqlType
> [type=19, scale=0, precision=2147483647, displaySize=2147483647, sql=OTHER],
> __C12=GridSqlType [type=13, scale=0, precision=2147483647,
> displaySize=2147483647, sql=VARCHAR], __C13=GridSqlType [type=4, scale=0,
> precision=10, displaySize=11, sql=INTEGER]}, alias=null]],
> topVer=AffinityTopologyVersion [topVer=1, minorTopVer=0], extraSpaces=[D, O],
> parts=null]
> class org.apache.ignite.IgniteCheckedException: Failed to parse SQL query:
> SELECT
> PERSON._KEY __C0,
> PERSON._VAL __C1,
> PERSON.NAME __C2,
> PERSON.ID __C3,
> PERSON.DEPID __C4,
> DEP._KEY __C5,
> DEP._VAL __C6,
> DEP.NAME __C7,
> DEP.ID __C8,
> DEP.ORGID __C9,
> ORG._KEY __C10,
> ORG._VAL __C11,
> ORG.NAME __C12,
> ORG.ID __C13
> FROM P.PERSON
> INNER JOIN D.DEPARTMENT DEP
> LEFT OUTER JOIN O.ORG ORG
> ON ORG.ID = DEP.ORGID
> WHERE DEP.ID = P.PERSON.DEPID
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:828)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:870)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:454)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:184)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1065)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:572)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$2.iterator(IgniteH2Indexing.java:971)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:61)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:73)
> at
> org.apache.ignite.internal.processors.cache.distributed.replicated.Example2.main(Example2.java:40)
> Caused by: org.h2.jdbc.JdbcSQLException: Column "DEP.ORGID" not found; SQL
> statement:
> SELECT
> PERSON._KEY __C0,
> PERSON._VAL __C1,
> PERSON.NAME __C2,
> PERSON.ID __C3,
> PERSON.DEPID __C4,
> DEP._KEY __C5,
> DEP._VAL __C6,
> DEP.NAME __C7,
> DEP.ID __C8,
> DEP.ORGID __C9,
> ORG._KEY __C10,
> ORG._VAL __C11,
> ORG.NAME __C12,
> ORG.ID __C13
> FROM P.PERSON
> INNER JOIN D.DEPARTMENT DEP
> LEFT OUTER JOIN O.ORG ORG
> ON ORG.
[jira] [Resolved] (IGNITE-3305) Ignite does not wait for dynamically created caches in SYNC rebalance mode
[
https://issues.apache.org/jira/browse/IGNITE-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk resolved IGNITE-3305.
--
Resolution: Fixed
> Ignite does not wait for dynamically created caches in SYNC rebalance mode
> --
>
> Key: IGNITE-3305
> URL: https://issues.apache.org/jira/browse/IGNITE-3305
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 1.7
>
>
> See GridCacheProcessor#onKernalStart():
> {code}
> // Wait for caches in SYNC preload mode.
> for (CacheConfiguration cfg : ctx.config().getCacheConfiguration()) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3305) Ignite does not wait for dynamically created caches in SYNC rebalance mode
[
https://issues.apache.org/jira/browse/IGNITE-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330939#comment-15330939
]
Alexey Goncharuk commented on IGNITE-3305:
--
TC passed, changes merged to master.
> Ignite does not wait for dynamically created caches in SYNC rebalance mode
> --
>
> Key: IGNITE-3305
> URL: https://issues.apache.org/jira/browse/IGNITE-3305
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 1.7
>
>
> See GridCacheProcessor#onKernalStart():
> {code}
> // Wait for caches in SYNC preload mode.
> for (CacheConfiguration cfg : ctx.config().getCacheConfiguration()) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3305) Ignite does not wait for dynamically created caches in SYNC rebalance mode
[
https://issues.apache.org/jira/browse/IGNITE-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk closed IGNITE-3305.
> Ignite does not wait for dynamically created caches in SYNC rebalance mode
> --
>
> Key: IGNITE-3305
> URL: https://issues.apache.org/jira/browse/IGNITE-3305
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Fix For: 1.7
>
>
> See GridCacheProcessor#onKernalStart():
> {code}
> // Wait for caches in SYNC preload mode.
> for (CacheConfiguration cfg : ctx.config().getCacheConfiguration()) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3316) Web console: we need to add 'milliseconds' to all appropriate field's tooltip
Pavel Konstantinov created IGNITE-3316: -- Summary: Web console: we need to add 'milliseconds' to all appropriate field's tooltip Key: IGNITE-3316 URL: https://issues.apache.org/jira/browse/IGNITE-3316 Project: Ignite Issue Type: Task Components: UI Reporter: Pavel Konstantinov Priority: Trivial For now many fields which value is measured in milliseconds has no 'milliseconds' in tooltip, e.g. Clusters > Discovery > Join timeout -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3310) Need to document Visor scripting capabilities
[ https://issues.apache.org/jira/browse/IGNITE-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-3310. -- Resolution: Fixed Val, please review: https://apacheignite.readme.io/docs/batch-mode > Need to document Visor scripting capabilities > - > > Key: IGNITE-3310 > URL: https://issues.apache.org/jira/browse/IGNITE-3310 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 1.6 >Reporter: Valentin Kulichenko >Assignee: Alexey Kuznetsov > Fix For: 1.7 > > > The functionality was added in scope of IGNITE-185, but it's not documented > yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-3310) Need to document Visor scripting capabilities
[ https://issues.apache.org/jira/browse/IGNITE-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-3310: Assignee: Valentin Kulichenko (was: Alexey Kuznetsov) > Need to document Visor scripting capabilities > - > > Key: IGNITE-3310 > URL: https://issues.apache.org/jira/browse/IGNITE-3310 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 1.6 >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko > Fix For: 1.7 > > > The functionality was added in scope of IGNITE-185, but it's not documented > yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3317) .NET: Improve error message when jvm.dll could not be loaded
Pavel Tupitsyn created IGNITE-3317:
--
Summary: .NET: Improve error message when jvm.dll could not be
loaded
Key: IGNITE-3317
URL: https://issues.apache.org/jira/browse/IGNITE-3317
Project: Ignite
Issue Type: Improvement
Components: community, platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 1.7
User got an unhelpful error message:
{code}
Failed to load jvm.dll:
[option=JAVA_HOME, path=C:\Program
Files\Java\jdk1.8.0_92\jre\bin\server\jvm.dll, errorCode=193]
[option=JAVA_HOME, path=C:\Program
Files\Java\jdk1.8.0_92\jre\bin\default\jvm.dll, errorCode=126]
{code}
Which turned out to be x64/x86 issue.
Provide more details in such case: what happened and how to fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
