[jira] [Commented] (IGNITE-2552) Eviction policy must consider either max size or max entries count
[ https://issues.apache.org/jira/browse/IGNITE-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906979#comment-15906979 ] ASF GitHub Bot commented on IGNITE-2552: Github user voipp closed the pull request at: https://github.com/apache/ignite/pull/1545 > Eviction policy must consider either max size or max entries count > -- > > Key: IGNITE-2552 > URL: https://issues.apache.org/jira/browse/IGNITE-2552 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.0 > > > Presently both max size and max entries number are considered by eviction > policy logic even if the only one is set by user explicitly. > This behavior must be reworked in a way that if one of the parameters is set > explicitly then only it will be used by eviction policy while the other one > will be ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4816) Issue with refresh rate on queries
Pavel Konstantinov created IGNITE-4816: -- Summary: Issue with refresh rate on queries Key: IGNITE-4816 URL: https://issues.apache.org/jira/browse/IGNITE-4816 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov Next query execution start before previous one is finished -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4816) Issue with refresh rate on queries
[ https://issues.apache.org/jira/browse/IGNITE-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-4816: - Assignee: Vasiliy Sisko > Issue with refresh rate on queries > -- > > Key: IGNITE-4816 > URL: https://issues.apache.org/jira/browse/IGNITE-4816 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > > Next query execution start before previous one is finished -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906995#comment-15906995 ] Vyacheslav Daradur commented on IGNITE-4211: [~avinogradov], tests look good. Please, review it again. Thanks. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907062#comment-15907062
]
Maksim Kozlov commented on IGNITE-533:
--
[~dmagda] I'm add documentation for
https://apacheignite-mix.readme.io/docs/zeromq-streamer and change
https://apacheignite-mix.readme.io/v1.8/docs/overview.
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * 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.15#6346)
[jira] [Assigned] (IGNITE-4473) Client should re-try connection attempt in case of concurrent network failure
[ https://issues.apache.org/jira/browse/IGNITE-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev reassigned IGNITE-4473: --- Assignee: Dmitry Karachentsev (was: Nikolay Tikhonov) > Client should re-try connection attempt in case of concurrent network failure > - > > Key: IGNITE-4473 > URL: https://issues.apache.org/jira/browse/IGNITE-4473 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.8 >Reporter: Vladimir Ozerov >Assignee: Dmitry Karachentsev > Fix For: 2.0 > > > *Problem* > Consider the following scenario: > 1) Client started, but there are no servers, so it hangs somewhere inside > start routine. > 2) Server appears, and discovery finishes successfully. > 3) Nodes start talking to each other through communication SPI to finish > start process (e.g. to complete exchange). > 4) But network glitch occurs and server becomes unreachable. > *Expected behavior* > Client disconnects and hangs waiting for reconnect. > *Actual behavior* > Client throws an exception and never tries to reconnect. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4814) GridQueryProcessor: improve type registration logic
[
https://issues.apache.org/jira/browse/IGNITE-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-4814.
-
Resolution: Fixed
> GridQueryProcessor: improve type registration logic
> ---
>
> Key: IGNITE-4814
> URL: https://issues.apache.org/jira/browse/IGNITE-4814
> Project: Ignite
> Issue Type: Task
> Components: SQL
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently registration of every type causes {{GridQueryIndexing}} state
> change which is not cleaned up properly in case of exception.
> Need to rework initialization routine to make sure that state is always clean
> and consistent.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4814) GridQueryProcessor: improve type registration logic
[
https://issues.apache.org/jira/browse/IGNITE-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907097#comment-15907097
]
ASF GitHub Bot commented on IGNITE-4814:
Github user devozerov closed the pull request at:
https://github.com/apache/ignite/pull/1612
> GridQueryProcessor: improve type registration logic
> ---
>
> Key: IGNITE-4814
> URL: https://issues.apache.org/jira/browse/IGNITE-4814
> Project: Ignite
> Issue Type: Task
> Components: SQL
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently registration of every type causes {{GridQueryIndexing}} state
> change which is not cleaned up properly in case of exception.
> Need to rework initialization routine to make sure that state is always clean
> and consistent.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4797) Need to expose offheap memory allocated size metric for internal data structures
[
https://issues.apache.org/jira/browse/IGNITE-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907129#comment-15907129
]
Andrey Gura commented on IGNITE-4797:
-
[~kay_jpr]
Yes, it will. It's right direction.
> Need to expose offheap memory allocated size metric for internal data
> structures
>
>
> Key: IGNITE-4797
> URL: https://issues.apache.org/jira/browse/IGNITE-4797
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Kartik Somani
> Labels: newbie
> Fix For: 2.0
>
>
> Offheap caches expose offheap memory allocated size via
> {{CacheMetricsMXBean.getOffHeapAllocatedSize()}}. But this metric doesn't
> take into account offheap memory that allocated for internal data structures
> (GridUnsafeMap and LRU eviction policy).
> However Ignite collects this metric (see
> GridUnsafeMemory.systemAllocatedSize() method).
> Need to expose this metric via {{CacheMetricsMXBean}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4816) Issue with refresh rate on queries
[ https://issues.apache.org/jira/browse/IGNITE-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907171#comment-15907171 ] Vasiliy Sisko commented on IGNITE-4816: --- Changed interval to timeout to run next query after specified period when last query executed. > Issue with refresh rate on queries > -- > > Key: IGNITE-4816 > URL: https://issues.apache.org/jira/browse/IGNITE-4816 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > > Next query execution start before previous one is finished -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (IGNITE-4816) Issue with refresh rate on queries
[ https://issues.apache.org/jira/browse/IGNITE-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-4816: -- Comment: was deleted (was: Changed interval to timeout to run next query after specified period when last query executed.) > Issue with refresh rate on queries > -- > > Key: IGNITE-4816 > URL: https://issues.apache.org/jira/browse/IGNITE-4816 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > > Next query execution start before previous one is finished -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4816) Issue with refresh rate on queries
[ https://issues.apache.org/jira/browse/IGNITE-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-4816: - Assignee: Andrey Novikov (was: Vasiliy Sisko) > Issue with refresh rate on queries > -- > > Key: IGNITE-4816 > URL: https://issues.apache.org/jira/browse/IGNITE-4816 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov > > Next query execution start before previous one is finished -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4816) Issue with refresh rate on queries
[ https://issues.apache.org/jira/browse/IGNITE-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907177#comment-15907177 ] Vasiliy Sisko commented on IGNITE-4816: --- Changed interval to invoke of timeout after last query executed. > Issue with refresh rate on queries > -- > > Key: IGNITE-4816 > URL: https://issues.apache.org/jira/browse/IGNITE-4816 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > > Next query execution start before previous one is finished -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4815) CollisionSPI.onCollision() method has a confusing javadoc
[ https://issues.apache.org/jira/browse/IGNITE-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907317#comment-15907317 ] Yakov Zhdanov commented on IGNITE-4815: --- Andrey, I think that javadoc should mention that this method is called also on metrics update (which was corrected by you) however, I would put all the cases into unordered list in the comment. Makes sense? > CollisionSPI.onCollision() method has a confusing javadoc > - > > Key: IGNITE-4815 > URL: https://issues.apache.org/jira/browse/IGNITE-4815 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Trivial > Fix For: 2.0 > > > CollisionSPI calls on every EVT_NODE_METRICS_UPDATED event. > It looks like CollisionSPI.onCollision() method has a confusing javadoc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4751) JVM crash while accessing Offheap entry.
[ https://issues.apache.org/jira/browse/IGNITE-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907355#comment-15907355 ] Andrew Mashenkov commented on IGNITE-4751: -- Possible, it is duplicate of IGNITE-19 > JVM crash while accessing Offheap entry. > > > Key: IGNITE-4751 > URL: https://issues.apache.org/jira/browse/IGNITE-4751 > Project: Ignite > Issue Type: Bug > Components: general, swap >Affects Versions: 1.7, 1.8 >Reporter: Andrew Mashenkov >Priority: Critical > Fix For: 2.0 > > Attachments: mm-rbp-server-err-pid8466.log > > > JVM crashed with SIGSEGV error while iterating over offheap entries on stable > topology. > PFA logs attached. > Partitioned OffHeap-Tiered cache with swap enabled has been configured. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907360#comment-15907360 ] Anton Vinogradov commented on IGNITE-4211: -- [~daradurvs], Do we need a special SpringCacheTest? How this test related to version change? > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907370#comment-15907370 ] Vyacheslav Daradur commented on IGNITE-4211: [~avinogradov], bq. Do we need a special SpringCacheTest? I think yes. All code shall be covered with tests. bq. How this test related to version change? I have to test the implementation of a new get-method. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.
[
https://issues.apache.org/jira/browse/IGNITE-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907373#comment-15907373
]
ASF GitHub Bot commented on IGNITE-3682:
GitHub user daradurvs opened a pull request:
https://github.com/apache/ignite/pull/1614
IGNITE-3682
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/daradurvs/ignite ignite-3682
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/1614.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 #1614
commit 1d91a26e668e6976bde1fed09b8dbb4e55af9350
Author: daradurvs
Date: 2017-03-08T21:40:07Z
ignite-3682: work in progress
commit 155c95e75090ab1f84c4d204e1ff315f170e4ae3
Author: Vyacheslav Daradur
Date: 2017-03-09T08:53:45Z
ignite-3682: move new classes to different package; change toString-methods
commit 063b16444a55fbc21143fbec43e03c05f6c94a32
Author: Vyacheslav Daradur
Date: 2017-03-09T08:56:14Z
ignite-3682: package-info was added
commit 5c2a56d50edd2f79d4ac3d0495cb144f1a67cf03
Author: Vyacheslav Daradur
Date: 2017-03-09T09:29:55Z
ignite-3682: work in progress
commit 84f311943e02e7178ae61865f163fc7c1d91564f
Author: Vyacheslav Daradur
Date: 2017-03-09T10:17:05Z
ignite-3682: work in progress
commit 577f1e2bc5533aac1fe17a7120eae34c66f7cb98
Author: Vyacheslav Daradur
Date: 2017-03-09T11:41:37Z
ignite-3682: anonymous classes defined in class level were extracted to top
level classes
commit 97e0a420851a801f8007106a482d1d59f51820ba
Author: Vyacheslav Daradur
Date: 2017-03-09T13:41:31Z
ignite-3682: work in progress
commit 719dec5a251102738d6efa40401db9cf13e1ca84
Author: Vyacheslav Daradur
Date: 2017-03-10T11:42:21Z
ignite-3682: work in progress
commit 54300f7f0e1fd1b6cb99a666515ade9bf9239701
Author: Vyacheslav Daradur
Date: 2017-03-10T16:09:45Z
ignite-3682: work in progress
commit 0947be7aa42e7655503da6770d5d4b10423f1347
Author: daradurvs
Date: 2017-03-11T20:12:48Z
ignite-3682: work in progress
commit a4aafa9253d5c5ca7bd8a99314b401b46a4b213d
Author: daradurvs
Date: 2017-03-12T09:15:34Z
ignite-3682: minor refactoring with anonymous class extraction
commit 843fd270005c7920bc3881d42323facd24430c67
Author: Vyacheslav Daradur
Date: 2017-03-13T09:46:25Z
ignite-3682: work in progress
commit 8ea18e36eb1263f34b327b02b3c313c994d85de6
Author: Vyacheslav Daradur
Date: 2017-03-13T11:39:47Z
ignite-3682: all anonymous classes were extracted
commit b5b11ead2a00bb01fd7c6104aae779035bdcb263
Author: Vyacheslav Daradur
Date: 2017-03-13T12:32:01Z
ignite-3682: minor changes
> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
> Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.
[
https://issues.apache.org/jira/browse/IGNITE-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907418#comment-15907418
]
Vyacheslav Daradur commented on IGNITE-3682:
[~vozerov]
Can I do some refactoring within this task? (to remove unused methods and code
duplicates)
> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
> Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-4802) Create separate thread pool for services
[ https://issues.apache.org/jira/browse/IGNITE-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko reassigned IGNITE-4802: --- Assignee: Valentin Kulichenko > Create separate thread pool for services > > > Key: IGNITE-4802 > URL: https://issues.apache.org/jira/browse/IGNITE-4802 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.9 >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko > Fix For: 2.0 > > > Currently if a service is invoked via service proxy, it will be executed on a > remote node in its public thread pool. This means that it's unsafe to execute > a compute job or closure from a service as it can cause starvation. > Need to create a separate pool for services to overcome this limitation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.
[
https://issues.apache.org/jira/browse/IGNITE-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907418#comment-15907418
]
Vyacheslav Daradur edited comment on IGNITE-3682 at 3/13/17 1:19 PM:
-
[~vozerov]
1) Can I do some refactoring within this task? (to remove unused methods and
code duplicates)
2) Should @Depricated be added to GridFunc and F classes?
was (Author: daradurvs):
[~vozerov]
Can I do some refactoring within this task? (to remove unused methods and code
duplicates)
> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
> Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
[
https://issues.apache.org/jira/browse/IGNITE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905208#comment-15905208
]
Ivan Veselovsky edited comment on IGNITE-3542 at 3/13/17 1:22 PM:
--
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) The problem is that we base on natural assertion "file does not exist after
removal", and with current implementation of IgfsImpl#exists() we can fulfill
it only if the file is also deleted from the secondary file system upon
removal. The matter is that if a file does not exist on primary file system,
but exists on the secondary one, #exists() returns *true*.
was (Author: iveselovskiy):
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) Agree, I'm not sure what to do best in case
{code}!pathIds.allExists(){code} -- deletion on secondary Fs really looks
strange, but that is an existing functionality. Agree, this may look strange.
But I guess, we should not throw an Exception in this case, but rather should
return {code}new IgfsDeleteResult(false, null);{code}, shouldn't we?
> IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
> -
>
> Key: IGNITE-3542
> URL: https://issues.apache.org/jira/browse/IGNITE-3542
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> If integrity check failed, it means that some concurrent file system update
> occurred. We should always perform re-try in this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
[
https://issues.apache.org/jira/browse/IGNITE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905208#comment-15905208
]
Ivan Veselovsky edited comment on IGNITE-3542 at 3/13/17 1:32 PM:
--
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) The problem is that we base on natural assertion "file does not exist after
removal", and with current implementation of IgfsImpl#exists() we can fulfill
it only if the file is also deleted from the secondary file system upon
removal. The matter is that if a file does not exist on primary file system,
but exists on the secondary one, #exists() returns *true*.
was (Author: iveselovskiy):
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) The problem is that we base on natural assertion "file does not exist after
removal", and with current implementation of IgfsImpl#exists() we can fulfill
it only if the file is also deleted from the secondary file system upon
removal. The matter is that if a file does not exist on primary file system,
but exists on the secondary one, #exists() returns *true*.
> IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
> -
>
> Key: IGNITE-3542
> URL: https://issues.apache.org/jira/browse/IGNITE-3542
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> If integrity check failed, it means that some concurrent file system update
> occurred. We should always perform re-try in this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
[
https://issues.apache.org/jira/browse/IGNITE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905208#comment-15905208
]
Ivan Veselovsky edited comment on IGNITE-3542 at 3/13/17 1:54 PM:
--
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) The problem is that we base on natural assertion "file does not exist after
removal", and with current implementation of IgfsImpl#exists() we can fulfill
it only if the file is also deleted from the secondary file system upon
removal. The reason is that if a file does not exist on primary file system,
but exists on the secondary one, IgfsImpl#exists() returns *true*. Test
org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest#testDeletePathMissingPartially
checks this behavior.
It seems, throwing an exception in this case would violate the method contract,
since method org.apache.ignite.IgniteFileSystem#delete javadoc specifies
throwing IgniteException on error only.
So, I would suggest to stay with the behavior suggested in the patch -- it
seems logical and corresponds to the existing tests.
was (Author: iveselovskiy):
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) The problem is that we base on natural assertion "file does not exist after
removal", and with current implementation of IgfsImpl#exists() we can fulfill
it only if the file is also deleted from the secondary file system upon
removal. The matter is that if a file does not exist on primary file system,
but exists on the secondary one, #exists() returns *true*.
> IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
> -
>
> Key: IGNITE-3542
> URL: https://issues.apache.org/jira/browse/IGNITE-3542
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> If integrity check failed, it means that some concurrent file system update
> occurred. We should always perform re-try in this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-3542) IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
[
https://issues.apache.org/jira/browse/IGNITE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905208#comment-15905208
]
Ivan Veselovsky edited comment on IGNITE-3542 at 3/13/17 1:56 PM:
--
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) The problem is that we base on natural assertion "file does not exist after
removal", and with current implementation of IgfsImpl#exists() we can fulfill
it only if the file is also deleted from the secondary file system upon
removal. The reason is that if a file does not exist on primary file system,
but exists on the secondary one, IgfsImpl#exists() returns *true*. Test
org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest#testDeletePathMissingPartially
asserts this behavior directly.
It seems, throwing an exception in this case would violate the method contract,
since method org.apache.ignite.IgniteFileSystem#delete javadoc specifies
throwing IgniteException on error only.
So, I would suggest to stay with the behavior suggested in the patch -- it
seems logical and corresponds to the existing tests.
was (Author: iveselovskiy):
[~vozerov] ,
1) The suggested fix does not prevent the {code}delete{code} to be invoked on
underlying Fs in case integrity check failed, we just do retry and go to next
loop in this case. This is exactly what is requested by this ticket.
2) The problem is that we base on natural assertion "file does not exist after
removal", and with current implementation of IgfsImpl#exists() we can fulfill
it only if the file is also deleted from the secondary file system upon
removal. The reason is that if a file does not exist on primary file system,
but exists on the secondary one, IgfsImpl#exists() returns *true*. Test
org.apache.ignite.internal.processors.igfs.IgfsDualAbstractSelfTest#testDeletePathMissingPartially
checks this behavior.
It seems, throwing an exception in this case would violate the method contract,
since method org.apache.ignite.IgniteFileSystem#delete javadoc specifies
throwing IgniteException on error only.
So, I would suggest to stay with the behavior suggested in the patch -- it
seems logical and corresponds to the existing tests.
> IGFS: Ensure IgfsPathIds.verifyIntegrity() always lead to re-try.
> -
>
> Key: IGNITE-3542
> URL: https://issues.apache.org/jira/browse/IGNITE-3542
> Project: Ignite
> Issue Type: Bug
> Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Minor
> Fix For: 2.0
>
>
> If integrity check failed, it means that some concurrent file system update
> occurred. We should always perform re-try in this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907526#comment-15907526 ] Anton Vinogradov commented on IGNITE-4211: -- [~daradurvs] Seems, we already have such tests at GridSpringCacheManagerSelfTest Please add check for new method here. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907545#comment-15907545 ] Vyacheslav Daradur commented on IGNITE-4211: [~avinogradov] The GridSpringCacheManagerSelfTest is another test, which not covered the SpringCache class. (it is very strange test) The SpringCacheTest class is a class which covered all SpringCache methods in accordance with the unit-testing(JUnit) and TDD-practices and maven-structure. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-1178) NPE in GridCacheProcessor.onKernalStop()
[
https://issues.apache.org/jira/browse/IGNITE-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907552#comment-15907552
]
ASF GitHub Bot commented on IGNITE-1178:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/1517
> NPE in GridCacheProcessor.onKernalStop()
>
>
> Key: IGNITE-1178
> URL: https://issues.apache.org/jira/browse/IGNITE-1178
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> If user start node with incorrectly configured cache type metadata for
> JdbcPojoStore NPE is raised in onKernalStop. See attached stacktrace:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to initialize property
> 'exceptionOid' for key class 'class
> org.apache.ignite.examples.algofusion.ExceptionMasterKey' and value class
> 'class org.apache.ignite.examples.algofusion.ExceptionMaster'. Make sure
> that one of these classes contains respective getter method or field.
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.buildClassProperty(GridQueryProcessor.java:1342)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processClassMeta(GridQueryProcessor.java:1148)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:149)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:249)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:922)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:779)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1538)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1405)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:931)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at org.apache.ignite.examples.algofusion.AlgoDB.main(AlgoDB.java:89)
> [15:45:29,007][ERROR][main][IgniteKernal] Failed to pre-stop processor:
> GridProcessorAdapter []
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.GridCacheEventManager.isRecordable(GridCacheEventManager.java:342)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1089)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:896)
> at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:1706)
> at
> org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1650)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:852)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1538)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1405)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:931)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at org.apache.ignite.examples.algofusion.AlgoDB.main(AlgoDB.java:89)
> [15:45:29] Ignite node stopped wih ERRORS [uptime=00:00:02:515]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4211) Update Spring dependency to latest stable version
[ https://issues.apache.org/jira/browse/IGNITE-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907586#comment-15907586 ] Anton Vinogradov commented on IGNITE-4211: -- [~daradurvs] GridSpringCacheManagerSelfTest checks spring annotations (eg. @Cacheable). Seems we just need to add one more case to support get with predicate. See commit https://github.com/spring-projects/spring-framework/commit/19d97c425316801a767cf99178ef30af730b1570 for details. > Update Spring dependency to latest stable version > - > > Key: IGNITE-4211 > URL: https://issues.apache.org/jira/browse/IGNITE-4211 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 1.7 >Reporter: Sergey Kozlov >Assignee: Vyacheslav Daradur > Fix For: 2.0 > > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we to update to latest stable > version (4.3.4 at the moment)? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-1178) NPE in GridCacheProcessor.onKernalStop()
[
https://issues.apache.org/jira/browse/IGNITE-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-1178:
-
Fix Version/s: 2.0
> NPE in GridCacheProcessor.onKernalStop()
>
>
> Key: IGNITE-1178
> URL: https://issues.apache.org/jira/browse/IGNITE-1178
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
>
> If user start node with incorrectly configured cache type metadata for
> JdbcPojoStore NPE is raised in onKernalStop. See attached stacktrace:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to initialize property
> 'exceptionOid' for key class 'class
> org.apache.ignite.examples.algofusion.ExceptionMasterKey' and value class
> 'class org.apache.ignite.examples.algofusion.ExceptionMaster'. Make sure
> that one of these classes contains respective getter method or field.
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.buildClassProperty(GridQueryProcessor.java:1342)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processClassMeta(GridQueryProcessor.java:1148)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initializeCache(GridQueryProcessor.java:149)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:249)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:922)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:779)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1538)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1405)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:931)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at org.apache.ignite.examples.algofusion.AlgoDB.main(AlgoDB.java:89)
> [15:45:29,007][ERROR][main][IgniteKernal] Failed to pre-stop processor:
> GridProcessorAdapter []
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.GridCacheEventManager.isRecordable(GridCacheEventManager.java:342)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1089)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:896)
> at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:1706)
> at
> org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1650)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:852)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1538)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1405)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:931)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> at org.apache.ignite.examples.algofusion.AlgoDB.main(AlgoDB.java:89)
> [15:45:29] Ignite node stopped wih ERRORS [uptime=00:00:02:515]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-933) GridFailFastNodeFailureDetectionSelfTest.testFailFast fails periodically
[ https://issues.apache.org/jira/browse/IGNITE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907621#comment-15907621 ] ASF GitHub Bot commented on IGNITE-933: --- GitHub user javaller opened a pull request: https://github.com/apache/ignite/pull/1615 IGNITE-933 Changed timeout to 500. Test completes successfully on single core machine as well as on multi-core servers. You can merge this pull request into a Git repository by running: $ git pull https://github.com/javaller/ignite master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1615.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 #1615 commit 8e64009ecc2e960db3cfdb5ce900962f17d07982 Author: javaller <2w3e4r5t> Date: 2017-03-13T14:58:42Z IGNITE-933 Changed timeout to 500. Test completes successfully on single core machine as well as on multi-core servers. > GridFailFastNodeFailureDetectionSelfTest.testFailFast fails periodically > > > Key: IGNITE-933 > URL: https://issues.apache.org/jira/browse/IGNITE-933 > Project: Ignite > Issue Type: Bug > Components: general, newbie >Affects Versions: sprint-5 >Reporter: Denis Magda >Assignee: Vadim Opolski > Labels: newbie > > The timeout for latch (500 millis) seems to be not enough for some machines. > Investigate and fix appropriately. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4758) Introduce MemoryPolicy configuration and adapt PageMemory concept to multiple memory policies
[ https://issues.apache.org/jira/browse/IGNITE-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907759#comment-15907759 ] Sergey Chugunov commented on IGNITE-4758: - Fixed tests for Indexing SPI. > Introduce MemoryPolicy configuration and adapt PageMemory concept to multiple > memory policies > - > > Key: IGNITE-4758 > URL: https://issues.apache.org/jira/browse/IGNITE-4758 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Sergey Chugunov >Assignee: Alexey Kuznetsov > Fix For: 2.0 > > Original Estimate: 336h > Time Spent: 32h > Remaining Estimate: 304h > > h2. Acceptance Criteria > # For each named *MemoryPolicy* described in configuration new named > *PageMemory* is created. > # Each cache on startup is assigned to corresponding *PageMemory* instance > which is stored in context of the cache. > # A default *PageMemory* is used to store content of caches with no > *MemoryPolicy* configured. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4793) Spark shared RDD example fails
[
https://issues.apache.org/jira/browse/IGNITE-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda resolved IGNITE-4793.
-
Resolution: Cannot Reproduce
No longer reproduced. Most likely cleaning of local .m2 directory helped out.
> Spark shared RDD example fails
> --
>
> Key: IGNITE-4793
> URL: https://issues.apache.org/jira/browse/IGNITE-4793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Denis Magda
>Priority: Critical
>
> Download the latest Apache Ignite 1.9.0 binary and try to start either
> {{SharedRDDExample}} or {{ScalarSharedRDDExample}}. I'm getting the exception
> below all the time:
> {code}
> /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/bin/java
> -Didea.launcher.port=7532 "-Didea.launcher.bin.path=/Applications/IntelliJ
> IDEA CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> "/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/packager.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/tools.jar:/Users/dmagda/Downloads/apache-ignite-fabric-1.9.0-bin/examples/target/classes:/Users/dmagda/.m2/repository/javax/cache/cache-api/1.0.0/cache-api-1.0.0.jar:/Users/dmagda/.m2/repository/org/apache/ignite/ignite-core/1.9.0/ignite-core-1.9.0.jar:/Users/dmagda/.m2/repository/org/jetbrains/annotations/13.0/annotations-13.0.jar:/Users/dmagda/.m2/repository/org/gridgain/ignite-shmem/1.0.0/ignite-shmem-1.0.0.jar:/Users/dmagda/.m2/repository/org/apache/ignite/ignite-spring/1.9.0/ignite-spring-1.9.0.jar:/Users/dmagda/.m2/repository/org/springframework/spring-core/4.1.0.RELEASE/spring-core-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-aop/4.1.0.RELEASE/spring-aop-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/dmagda/.m2/repository/org/springframework/spring-beans/4.1.0.RELEASE/spring-beans-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-context/4.1.0.RELEASE/spring-context-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-expression/4.1.0.RELEASE/spring-expression-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-tx/4.1.0.RELEASE/spring-tx-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-jdbc/4.1.0.RELEASE/spring-jdbc-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar:/Users/dmagda/.m2/repository/org/apache/ignite/ignite-log4j/1.9.0/ignite-log4j-1.9.0.jar:/Users/dmagda/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar:/Users/dmagda/.m2/repo
[jira] [Closed] (IGNITE-4793) Spark shared RDD example fails
[
https://issues.apache.org/jira/browse/IGNITE-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda closed IGNITE-4793.
---
> Spark shared RDD example fails
> --
>
> Key: IGNITE-4793
> URL: https://issues.apache.org/jira/browse/IGNITE-4793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Denis Magda
>Priority: Critical
>
> Download the latest Apache Ignite 1.9.0 binary and try to start either
> {{SharedRDDExample}} or {{ScalarSharedRDDExample}}. I'm getting the exception
> below all the time:
> {code}
> /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/bin/java
> -Didea.launcher.port=7532 "-Didea.launcher.bin.path=/Applications/IntelliJ
> IDEA CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> "/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/dt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/packager.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/lib/tools.jar:/Users/dmagda/Downloads/apache-ignite-fabric-1.9.0-bin/examples/target/classes:/Users/dmagda/.m2/repository/javax/cache/cache-api/1.0.0/cache-api-1.0.0.jar:/Users/dmagda/.m2/repository/org/apache/ignite/ignite-core/1.9.0/ignite-core-1.9.0.jar:/Users/dmagda/.m2/repository/org/jetbrains/annotations/13.0/annotations-13.0.jar:/Users/dmagda/.m2/repository/org/gridgain/ignite-shmem/1.0.0/ignite-shmem-1.0.0.jar:/Users/dmagda/.m2/repository/org/apache/ignite/ignite-spring/1.9.0/ignite-spring-1.9.0.jar:/Users/dmagda/.m2/repository/org/springframework/spring-core/4.1.0.RELEASE/spring-core-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-aop/4.1.0.RELEASE/spring-aop-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/dmagda/.m2/repository/org/springframework/spring-beans/4.1.0.RELEASE/spring-beans-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-context/4.1.0.RELEASE/spring-context-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-expression/4.1.0.RELEASE/spring-expression-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-tx/4.1.0.RELEASE/spring-tx-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/org/springframework/spring-jdbc/4.1.0.RELEASE/spring-jdbc-4.1.0.RELEASE.jar:/Users/dmagda/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar:/Users/dmagda/.m2/repository/org/apache/ignite/ignite-log4j/1.9.0/ignite-log4j-1.9.0.jar:/Users/dmagda/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar:/Users/dmagda/.m2/repository/org/apache/ignite/ignite-indexing/1.9.0/ignite-indexing-1.9.0.jar:/Users/dmagda/.m2/repository/commons-codec/
[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907893#comment-15907893
]
Denis Magda commented on IGNITE-533:
[~dreamx], excellent, thanks a lot!
I've altered the doc a bit and released it under 1.9 version:
https://apacheignite-mix.readme.io/docs/zeromq-streamer
[~pgarg], please do the final review of the page above and close the ticket.
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * 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.15#6346)
[jira] [Assigned] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-533:
--
Assignee: Prachi Garg (was: Maksim Kozlov)
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Prachi Garg
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * 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.15#6346)
[jira] [Commented] (IGNITE-4587) Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
[
https://issues.apache.org/jira/browse/IGNITE-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907918#comment-15907918
]
Andrey Gura commented on IGNITE-4587:
-
[~dreamx],
I've review your changes. See my comments below. Please, fix.
# Class {{GridCacheAtomicFullApiSelfTest}}: method {{cacheConfiguration()}} can
be removed because it just returns result of base class method.
# Class {{GridCacheAtomicMultiNodeP2PDisabledFullApiSelfTest}}: method
{{cacheConfiguration()}} can be removed because it just returns result of base
class method.
# Class {{GridCacheReplicatedAtomicMultiNodeFullApiSelfTest}}: method
{{cacheConfiguration()}} can be removed because it just returns result of base
class method.
# Class {{GridCacheAtomicMessageCountSelfTest}}: methods
{{testPartitionedPrimary()}} and {{testClientPrimary()}} should be renamed to
{{testPartitioned()}} and {{testClient()}} respectively.
# Class {{GridCacheAtomicNearCacheSelfTest}}: method {{startGridsLocal()}}
confuses. Why {{Local}}? May be {{doStartGrids}} or something like.
# Class {{GridCacheAtomicVersionComparator}}: {{ignoreTime}} parameter at
{{compare}} method is unused and should be removed.
# Class {{GridCacheInterceptorAbstractSelfTest}}: unused import and methods.
# Class {{GridCacheMapEntry}}, method {{innerUpdate}}, lines 2172 and 2228:
{{ignireTime}} variable is always {{true}}. Need remove usage.
# Class {{GridCacheMultithreadedFailoverAbstractTest}}, method
{{configuration()}}, line 221: Nested if could be combined with embraced.
# Class {{GridCacheUtils}}: unused imports.
# Class {{GridCacheUtils}}: Bug. Please fix array size and offsets in
{{versionToBytes()}} and {{readVersion()}} methods.
# Class {{IgniteUtils}}: Bug. Please fix offsets in {{writeVersion()}} and
{{readVersion()}} methods.
# Class {{GridCacheVersion}}: Bug. Integers will be overflowed in
{{asGridUuid()}} method. Please replace by {{new UUID(topVer, nodeOrderDrId)}}.
# Class {{GridCacheVersion}}: method {{fieldsCount()}} returns incorrect
result. Use {{MessageCodeGenerator}} in order to generate correct code.
# Class {{GridCacheVersionEx}}: incorrect implementations of {{fieldsCount()}},
{{writeTo()}} and {{readFrom()}} methods. Use {{MessageCodeGenerator}} in order
to generate correct code.
# Class {{GridCommonAbstractTest}}: unused imports.
# Class {{GridCommonAbstractTest}}: method {{atomicClockModeDelay()}} should be
removed.
# Class {{GridDhtAtomicCache}}: I'm not sure about it. It seems that methos
{{isFastMap()}} should not be removed. Could you please ask about it on dev
list. Check also {{fastMap}} flag in {{GridNearAtomicUpdateFuture}} class.
# Class {{GridDhtAtomicCache}}: Redundant {{catch}} blocks in
{{lockEntriesMethod()}}, lines 2899 and 2914.
# Class {{GridNearAtomicSingleUpdateFuture}}: Method {{mapSingleUpdate()}}
creates different requests (like {{GridNearAtomicSingleUpdateInvokeRequest}}).
For all this requests all instantiations have {{updateVer == null}}. Need to
remove this prameter. The same for {{GridNearAtomicUpdateFuture}} class
{{mapUpdate()}} and {{mapSingleUpdate()}} methods.
# Class {{IgniteBenchmarkArguments}}: Comand line arguments {{"-wom",
"--writeOrderMode"}} were removed. Please, check that there are not this
arguments usges in {{modules/yardstick}}.
# Class {{IgniteCacheExpiryPolicyAbstractTest}}: methods {{nearReaderUpdate()}}
and {{nearPutAll()}}. It seems that all {{U.sleep()}} calls are redundant now.
# Class {{IgniteCachePutRetryAbstractSelfTest}}: unused import.
Also I see a lot of removed tests. I need additional time for analyzing it.
Thanks!
> Discontinue and remove CacheAtomicWriteOrderMode.CLOCK mode
> ---
>
> Key: IGNITE-4587
> URL: https://issues.apache.org/jira/browse/IGNITE-4587
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Denis Magda
>Assignee: Maksim Kozlov
> Fix For: 2.0
>
>
> {{CacheAtomicWriteOrderMode.CLOCK}} proved to be harmful in production due to
> timing issues.
> It makes sense to remove it completely in 2.0 release. Migration guide has be
> updated:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Garg closed IGNITE-533.
--
Reviewed and fixed minor issues.
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Prachi Garg
> Fix For: 2.0
>
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * 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.15#6346)
