[jira] [Assigned] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atri Sharma reassigned IGNITE-12850:
Assignee: Atri Sharma
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.6
>Reporter: Sarunas Valaskevicius
>Assignee: Atri Sharma
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history item, and generates base line topology history with gaps
> # from that point, it is impossible to start the node as
> `{color:#569e16}restoreHistory{color}` throws an exception when it is
> processing the gap
> –
> tested on 2.7.6, but it seems that ignite 2.8.0 would suffer from the same
> issue - by looking at the code
> --
> {code:java}
> 2020-03-21_00:00:03.867 [fapi-main-0] INFO
> o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
> BaselineTopology[id=9]
> 2020-03-21_00:00:03.904 [fapi-main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology
> history has failed, expected history item not found for id=8
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atri Sharma reassigned IGNITE-12850:
Assignee: (was: Atri Sharma)
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history item, and generates base line topology history with gaps
> # from that point, it is impossible to start the node as
> `{color:#569e16}restoreHistory{color}` throws an exception when it is
> processing the gap
> –
> tested on 2.7.6, but it seems that ignite 2.8.0 would suffer from the same
> issue - by looking at the code
> --
> {code:java}
> 2020-03-21_00:00:03.867 [fapi-main-0] INFO
> o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
> BaselineTopology[id=9]
> 2020-03-21_00:00:03.904 [fapi-main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology
> history has failed, expected history item not found for id=8
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15077) Support Quartz Scheduler in Scheduler Module
[ https://issues.apache.org/jira/browse/IGNITE-15077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-15077: Assignee: Atri Sharma > Support Quartz Scheduler in Scheduler Module > > > Key: IGNITE-15077 > URL: https://issues.apache.org/jira/browse/IGNITE-15077 > Project: Ignite > Issue Type: Bug >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15077) Support Quartz Scheduler in Scheduler Module
Atri Sharma created IGNITE-15077: Summary: Support Quartz Scheduler in Scheduler Module Key: IGNITE-15077 URL: https://issues.apache.org/jira/browse/IGNITE-15077 Project: Ignite Issue Type: Bug Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374607#comment-17374607 ] Atri Sharma commented on IGNITE-12401: -- [~Pavlukhin] Thanks, just sent an email :) > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Atri Sharma >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-12401: Assignee: Atri Sharma > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Atri Sharma >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374585#comment-17374585 ] Atri Sharma commented on IGNITE-12401: -- [~Pavlukhin] [~ilyak] Can you please assign this ticket to me? I would want to add it to the text queries refactoring work that I am focusing on. Maybe we can see this ticket and figure out if there is a way to avoid working on this ticket right now and move forward with text queries? > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Ivan Pavlukhin >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15043) FifoQueueCollisionSPI Should Be Thread Safe
[ https://issues.apache.org/jira/browse/IGNITE-15043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-15043: Assignee: Atri Sharma > FifoQueueCollisionSPI Should Be Thread Safe > --- > > Key: IGNITE-15043 > URL: https://issues.apache.org/jira/browse/IGNITE-15043 > Project: Ignite > Issue Type: Bug >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > > Today, if there is a single slot available in the active jobs limit and N > tasks come concurrently, there is a chance that many (or all) of them will be > able to proceed because the logic of FifoQueueCollisionSPI is as follows: > 1. Get active tasks count > 2. Compare to max tasks count > 3. If less, start the task > This is not thread safe, and we need to provide a realistic view of active > tasks count to all threads. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15043) FifoQueueCollisionSPI Should Be Thread Safe
Atri Sharma created IGNITE-15043: Summary: FifoQueueCollisionSPI Should Be Thread Safe Key: IGNITE-15043 URL: https://issues.apache.org/jira/browse/IGNITE-15043 Project: Ignite Issue Type: Bug Reporter: Atri Sharma Today, if there is a single slot available in the active jobs limit and N tasks come concurrently, there is a chance that many (or all) of them will be able to proceed because the logic of FifoQueueCollisionSPI is as follows: 1. Get active tasks count 2. Compare to max tasks count 3. If less, start the task This is not thread safe, and we need to provide a realistic view of active tasks count to all threads. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370494#comment-17370494 ] Atri Sharma commented on IGNITE-12401: -- [~ilyak] What do we need to fix this one, please? > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Yuriy Shuliha >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366452#comment-17366452 ] Atri Sharma commented on IGNITE-12401: -- [~Pavlukhin] [~ilyak] Did we ever fix MOVING partitions? If not, I would like to help on this ticket, please > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Yuriy Shuliha >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14920) Implement Spring Sessions Support
[ https://issues.apache.org/jira/browse/IGNITE-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-14920: Assignee: Atri Sharma > Implement Spring Sessions Support > - > > Key: IGNITE-14920 > URL: https://issues.apache.org/jira/browse/IGNITE-14920 > Project: Ignite > Issue Type: Bug > Components: extensions >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > > This Jira tracks the effort to implement Spring Sessions using Ignite as the > backing data store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14920) Implement Spring Sessions Support
Atri Sharma created IGNITE-14920: Summary: Implement Spring Sessions Support Key: IGNITE-14920 URL: https://issues.apache.org/jira/browse/IGNITE-14920 Project: Ignite Issue Type: Bug Components: extensions Reporter: Atri Sharma This Jira tracks the effort to implement Spring Sessions using Ignite as the backing data store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12692) Calcite integration. DML. Skip reducer optimization.
[ https://issues.apache.org/jira/browse/IGNITE-12692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-12692: Assignee: Atri Sharma > Calcite integration. DML. Skip reducer optimization. > > > Key: IGNITE-12692 > URL: https://issues.apache.org/jira/browse/IGNITE-12692 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Atri Sharma >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Having plan tree we easily can check whether a final modification may be > executed on data nodes directly or not. We should implement such kind of > optimization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12692) Calcite integration. DML. Skip reducer optimization.
[ https://issues.apache.org/jira/browse/IGNITE-12692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351019#comment-17351019 ] Atri Sharma commented on IGNITE-12692: -- I will be actively working on this ticket. > Calcite integration. DML. Skip reducer optimization. > > > Key: IGNITE-12692 > URL: https://issues.apache.org/jira/browse/IGNITE-12692 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Atri Sharma >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Having plan tree we easily can check whether a final modification may be > executed on data nodes directly or not. We should implement such kind of > optimization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14607) Regex Based Filter in IPFinders
[ https://issues.apache.org/jira/browse/IGNITE-14607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma updated IGNITE-14607: - Release Note: Add a way to specify regex based address filters for IP addresses during discovery > Regex Based Filter in IPFinders > --- > > Key: IGNITE-14607 > URL: https://issues.apache.org/jira/browse/IGNITE-14607 > Project: Ignite > Issue Type: Sub-task >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > This Jira tracks the effort to implement regex based IP filtering in IPFinders -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14608) Blocklist Based IP Filtering in IPFinders
Atri Sharma created IGNITE-14608: Summary: Blocklist Based IP Filtering in IPFinders Key: IGNITE-14608 URL: https://issues.apache.org/jira/browse/IGNITE-14608 Project: Ignite Issue Type: Sub-task Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14607) Regex Based Filter in IPFinders
Atri Sharma created IGNITE-14607: Summary: Regex Based Filter in IPFinders Key: IGNITE-14607 URL: https://issues.apache.org/jira/browse/IGNITE-14607 Project: Ignite Issue Type: Sub-task Reporter: Atri Sharma This Jira tracks the effort to implement regex based IP filtering in IPFinders -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14606) Filter Support in IPFinders
Atri Sharma created IGNITE-14606: Summary: Filter Support in IPFinders Key: IGNITE-14606 URL: https://issues.apache.org/jira/browse/IGNITE-14606 Project: Ignite Issue Type: Improvement Reporter: Atri Sharma In some scenarios, IPFinders need to be able to filter returned IPs based on a blocklist or a pattern. This is especially useful for cloud based IPFinders where the container can be shared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12263) Introduce native persistence compaction operation
[ https://issues.apache.org/jira/browse/IGNITE-12263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17323881#comment-17323881 ] Atri Sharma commented on IGNITE-12263: -- Hello. How is this different from: [https://ignite.apache.org/docs/latest/memory-architecture#memory-defragmentation] ? > Introduce native persistence compaction operation > - > > Key: IGNITE-12263 > URL: https://issues.apache.org/jira/browse/IGNITE-12263 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Critical > > Currently, Ignite native persistence does not shrink storage files after > key-value pairs are removed. > The causes of this behavior are: > * The absence of a mechanism that allows Ignite to track highest non-empty > page position in a partition file > * The absence of a mechanism which allows Ignite to select a page closest to > the file beginning for write > * The absence of a mechanism which allows Ignite to move a key-value pair > from page to page during defragmentation > As an initial change I suggest to introduce a new node startup mode, which > will run a defragmentation procedure allowing the node to shrink storage > files. The procedure will not mutate the logical state of a partition > allowing further historical rebalance to quickly catch up the node. Since the > procedure will run during the node startup (during the final stages of > recovery), there will be no concurrent load, thus the entries can be freely > moved from page to page with no tricky synchronization. > If a procedure is applied during the whole cluster restart, then all nodes > will be defragmented simultaneously, allowing for a quicker parallel > defragmentation at a cost of downtime. > The procedure should accept an optional list of cache groups to defragment to > allow arbitrary cache group selection for defragmentation. > An idea of the actions taken during the run for each partition selected for > defragmentation: > * Partition pages are preloaded to memory if possible to avoid excessive > page replacement. During the scan, a HWM of the written data is detected > (empty pages are skipped) > * Pages references in a free list are sorted in a way allowing to pick pages > closest to the file start > * The partition is scanned in reverse order, key-value pairs are moved > closer to the file start, HWM is updated accordingly. This step is > particularly open for various optimizations because different strategies will > work well for different fragmentation patterns. > * After the scan iteration is completed, the file size can be updated > according to the HWM > As a further improvement, this partition defragmentation procedure can be > later run in online mode, after proper cache update protocol changes are > designed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
[ https://issues.apache.org/jira/browse/IGNITE-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312071#comment-17312071 ] Atri Sharma commented on IGNITE-14346: -- [~ilyak] Tried with a build after including the Azure directory and the Ignite node started up fine (after the latest iteration). Please see and let me know. > Implement Azure Blob Storage Based IP Finder > > > Key: IGNITE-14346 > URL: https://issues.apache.org/jira/browse/IGNITE-14346 > Project: Ignite > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Labels: ReviewNeeded > Attachments: Screenshot 2021-03-23 at 8.42.31 PM.png, Screenshot > 2021-03-23 at 8.43.31 PM.png, Screenshot 2021-03-23 at 8.44.11 PM.png, > Screenshot 2021-03-23 at 8.45.05 PM.png > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
[
https://issues.apache.org/jira/browse/IGNITE-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312070#comment-17312070
]
Atri Sharma commented on IGNITE-14346:
--
[~ilyak] Updated. I also started an Ignite node after building a release with
the Azure module included.
I did {{mvn clean install -DskipTests}} and then {{mvn initialize -Prelease and
then started the node.}}
> Implement Azure Blob Storage Based IP Finder
>
>
> Key: IGNITE-14346
> URL: https://issues.apache.org/jira/browse/IGNITE-14346
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Labels: ReviewNeeded
> Attachments: Screenshot 2021-03-23 at 8.42.31 PM.png, Screenshot
> 2021-03-23 at 8.43.31 PM.png, Screenshot 2021-03-23 at 8.44.11 PM.png,
> Screenshot 2021-03-23 at 8.45.05 PM.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312062#comment-17312062
]
Atri Sharma commented on IGNITE-14347:
--
[~sdanilov] Can we merge this, please?
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> Ign
[jira] [Commented] (IGNITE-14402) Java Thin: Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-14402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308548#comment-17308548 ] Atri Sharma commented on IGNITE-14402: -- Hi [~ptupitsyn] Can I help with this one? > Java Thin: Continuous Query > --- > > Key: IGNITE-14402 > URL: https://issues.apache.org/jira/browse/IGNITE-14402 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-50 > Fix For: 2.11 > > > Implement Continuous Query API in Java Thin Client. > See .NET Thin Client as a reference: IGNITE-13148 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
[ https://issues.apache.org/jira/browse/IGNITE-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17307164#comment-17307164 ] Atri Sharma commented on IGNITE-14346: -- [~ilyak] I have uploaded screenshots of test suite with Azure credentials and actual storage. > Implement Azure Blob Storage Based IP Finder > > > Key: IGNITE-14346 > URL: https://issues.apache.org/jira/browse/IGNITE-14346 > Project: Ignite > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Attachments: Screenshot 2021-03-23 at 8.42.31 PM.png, Screenshot > 2021-03-23 at 8.43.31 PM.png, Screenshot 2021-03-23 at 8.44.11 PM.png, > Screenshot 2021-03-23 at 8.45.05 PM.png > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
[ https://issues.apache.org/jira/browse/IGNITE-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma updated IGNITE-14346: - Attachment: Screenshot 2021-03-23 at 8.42.31 PM.png Screenshot 2021-03-23 at 8.43.31 PM.png Screenshot 2021-03-23 at 8.44.11 PM.png Screenshot 2021-03-23 at 8.45.05 PM.png > Implement Azure Blob Storage Based IP Finder > > > Key: IGNITE-14346 > URL: https://issues.apache.org/jira/browse/IGNITE-14346 > Project: Ignite > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Attachments: Screenshot 2021-03-23 at 8.42.31 PM.png, Screenshot > 2021-03-23 at 8.43.31 PM.png, Screenshot 2021-03-23 at 8.44.11 PM.png, > Screenshot 2021-03-23 at 8.45.05 PM.png > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
Atri Sharma created IGNITE-14347: Summary: Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage Key: IGNITE-14347 URL: https://issues.apache.org/jira/browse/IGNITE-14347 Project: Ignite Issue Type: Improvement Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
[ https://issues.apache.org/jira/browse/IGNITE-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-14346: Assignee: Atri Sharma > Implement Azure Blob Storage Based IP Finder > > > Key: IGNITE-14346 > URL: https://issues.apache.org/jira/browse/IGNITE-14346 > Project: Ignite > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
Atri Sharma created IGNITE-14346: Summary: Implement Azure Blob Storage Based IP Finder Key: IGNITE-14346 URL: https://issues.apache.org/jira/browse/IGNITE-14346 Project: Ignite Issue Type: Improvement Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8375) NPE due to race on cache stop and timeout handler execution.
[
https://issues.apache.org/jira/browse/IGNITE-8375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17301496#comment-17301496
]
Atri Sharma commented on IGNITE-8375:
-
I debugged this and do not see this reproducing since GridCacheContext ensures
that it checks the local copy of config before accessing it. However,
GridDhtLockFuture#onComplete should be aware if the cache context is being
cleaned up and hence not invoke loadMissingFromStore. I have created a Jira for
the same:
https://issues.apache.org/jira/browse/IGNITE-14314
> NPE due to race on cache stop and timeout handler execution.
>
>
> Key: IGNITE-8375
> URL: https://issues.apache.org/jira/browse/IGNITE-8375
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Scherbakov
>Priority: Major
>
> {noformat}
> 2018-04-22 22:03:08.547 [INFO
> ][Thread-25420][o.a.i.i.p.cache.GridCacheProcessor] Stopped cache
> [cacheName=com.sbt.cdm.api.model.published.dictionary.PublishedSystem,
> group=CACHEGROUP_DICTIONARY]
> 2018-04-22 22:03:08.548
> [ERROR][grid-timeout-worker-#119%DPL_GRID%DplGridNodeName%][o.a.i.i.p.t.GridTimeoutProcessor]
> Error when executing timeout callback: LockTimeoutObject []
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.loadPreviousValue(GridCacheContext.java:1450)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.loadMissingFromStore(GridDhtLockFuture.java:1030)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:731)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$900(GridDhtLockFuture.java:82)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1133)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> NPE caused by execution of method [1] during timeout handler execution [2]:
> cacheCfg.isLoadPreviousValue() throws NPE because cacheCfg can be nulled by
> [3] on stop.
> [1]
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture#loadMissingFromStore
> [2]
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.LockTimeoutObject#onTimeout
> [3] org.apache.ignite.internal.processors.cache.GridCacheContext#cleanup
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14314) GridDhtLockFuture#onComplete Should Be Aware of Cache Cleanup
Atri Sharma created IGNITE-14314: Summary: GridDhtLockFuture#onComplete Should Be Aware of Cache Cleanup Key: IGNITE-14314 URL: https://issues.apache.org/jira/browse/IGNITE-14314 Project: Ignite Issue Type: Improvement Reporter: Atri Sharma Said method only takes node stoppage into account while deciding if store should be accessed. This can lead to race conditions when the cache is being cleaned up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8635) Add a method to inspect BinaryObject size
[
https://issues.apache.org/jira/browse/IGNITE-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17299431#comment-17299431
]
Atri Sharma commented on IGNITE-8635:
-
PR is available
> Add a method to inspect BinaryObject size
> -
>
> Key: IGNITE-8635
> URL: https://issues.apache.org/jira/browse/IGNITE-8635
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently only concrete implementations of {{BinaryObject}} interface provide
> some information regarding the object serialized size. It makes it hard for
> users to reason about storage size and estimate required storage capacity.
> We need to add a method to the {{BinaryObject}} interface itself to return
> the actual size required to store the object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-8635) Add a method to inspect BinaryObject size
[
https://issues.apache.org/jira/browse/IGNITE-8635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atri Sharma reassigned IGNITE-8635:
---
Assignee: Atri Sharma
> Add a method to inspect BinaryObject size
> -
>
> Key: IGNITE-8635
> URL: https://issues.apache.org/jira/browse/IGNITE-8635
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently only concrete implementations of {{BinaryObject}} interface provide
> some information regarding the object serialized size. It makes it hard for
> users to reason about storage size and estimate required storage capacity.
> We need to add a method to the {{BinaryObject}} interface itself to return
> the actual size required to store the object.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293611#comment-17293611
]
Atri Sharma commented on IGNITE-12508:
--
[~alex_pl] Thanks for highlighting – I have raised a PR for the same.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Rakov
>Assignee: Atri Sharma
>Priority: Major
> Labels: newbie
> Fix For: 2.11
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14236) Provide a new version of cache API
[
https://issues.apache.org/jira/browse/IGNITE-14236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290049#comment-17290049
]
Atri Sharma commented on IGNITE-14236:
--
[~slava.koptilin] This looks like a fun one! Is this something I can help with?
> Provide a new version of cache API
> --
>
> Key: IGNITE-14236
> URL: https://issues.apache.org/jira/browse/IGNITE-14236
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> Need to provide a minimal cache API that includes at least the following
> methods:
> - reading a value for a given key
> - writing a new value for a given key
> - remove a value for a given key
> - method that determines if the cache contains an entry for the specified
> key.
> - a way to iterate all key/value pairs
> - cache/table size (this method is questionable)
> Additionally, it can be considered adding a way to execute the user's code
> for the specified key - something like {{Cache#invoke()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14225) Add Helper Method to Check For Expected Exceptions in JUnitAssertAware
[ https://issues.apache.org/jira/browse/IGNITE-14225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289732#comment-17289732 ] Atri Sharma commented on IGNITE-14225: -- Added as a part of https://github.com/apache/ignite/pull/8820 > Add Helper Method to Check For Expected Exceptions in JUnitAssertAware > -- > > Key: IGNITE-14225 > URL: https://issues.apache.org/jira/browse/IGNITE-14225 > Project: Ignite > Issue Type: Improvement > Environment: We should have a helper method which allows checking if > an expected exception is raised from a specific code block in tests >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14225) Add Helper Method to Check For Expected Exceptions in JUnitAssertAware
[ https://issues.apache.org/jira/browse/IGNITE-14225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-14225: Assignee: Atri Sharma > Add Helper Method to Check For Expected Exceptions in JUnitAssertAware > -- > > Key: IGNITE-14225 > URL: https://issues.apache.org/jira/browse/IGNITE-14225 > Project: Ignite > Issue Type: Improvement > Environment: We should have a helper method which allows checking if > an expected exception is raised from a specific code block in tests >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14225) Add Helper Method to Check For Expected Exceptions in JUnitAssertAware
Atri Sharma created IGNITE-14225: Summary: Add Helper Method to Check For Expected Exceptions in JUnitAssertAware Key: IGNITE-14225 URL: https://issues.apache.org/jira/browse/IGNITE-14225 Project: Ignite Issue Type: Improvement Environment: We should have a helper method which allows checking if an expected exception is raised from a specific code block in tests Reporter: Atri Sharma -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-2399) Add asynchronous acquire to IgniteSemaphore
[ https://issues.apache.org/jira/browse/IGNITE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288289#comment-17288289 ] Atri Sharma commented on IGNITE-2399: - PR is available > Add asynchronous acquire to IgniteSemaphore > --- > > Key: IGNITE-2399 > URL: https://issues.apache.org/jira/browse/IGNITE-2399 > Project: Ignite > Issue Type: Improvement > Components: data structures >Reporter: Vladisav Jelisavcic >Assignee: Atri Sharma >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Usually a permit acquisition is followed by an action, followed by a release > of the permit. A simple enhancement to the existing Semaphore API can be made > that enables asynchronous acquire: > IgniteFuture acquireAndExecute(Callable action, int numPermits); > The method would immediately return a future to be later completed by the > action's result. Permits are to be released after the future is completed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-2399) Add asynchronous acquire to IgniteSemaphore
[ https://issues.apache.org/jira/browse/IGNITE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned IGNITE-2399: --- Assignee: Atri Sharma > Add asynchronous acquire to IgniteSemaphore > --- > > Key: IGNITE-2399 > URL: https://issues.apache.org/jira/browse/IGNITE-2399 > Project: Ignite > Issue Type: Improvement > Components: data structures >Reporter: Vladisav Jelisavcic >Assignee: Atri Sharma >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Usually a permit acquisition is followed by an action, followed by a release > of the permit. A simple enhancement to the existing Semaphore API can be made > that enables asynchronous acquire: > IgniteFuture acquireAndExecute(Callable action, int numPermits); > The method would immediately return a future to be later completed by the > action's result. Permits are to be released after the future is completed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13396) ignite.queue return null instead of throwing IgniteException as declared in the javadoc
[
https://issues.apache.org/jira/browse/IGNITE-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286889#comment-17286889
]
Atri Sharma commented on IGNITE-13396:
--
Investigating more, do we even have this method existent now?
> ignite.queue return null instead of throwing IgniteException as declared in
> the javadoc
> ---
>
> Key: IGNITE-13396
> URL: https://issues.apache.org/jira/browse/IGNITE-13396
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.8.1
>Reporter: Vladimir Pligin
>Priority: Major
>
> {code:java}
> Ignite ignite = Ignition.start();
> IgniteQueue queue = ignite.queue("Queue", 0, null);
> ignite.close();
> {code}
> This code returns null. We need to fix it or align the javadoc.
> Here's the initial discussion:
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-Queue-Documentation-or-Code-defect-td33703.html]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13396) ignite.queue return null instead of throwing IgniteException as declared in the javadoc
[
https://issues.apache.org/jira/browse/IGNITE-13396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286487#comment-17286487
]
Atri Sharma commented on IGNITE-13396:
--
Hello,
Looking at the current state, we should probably just update the documentation?
> ignite.queue return null instead of throwing IgniteException as declared in
> the javadoc
> ---
>
> Key: IGNITE-13396
> URL: https://issues.apache.org/jira/browse/IGNITE-13396
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.8.1
>Reporter: Vladimir Pligin
>Priority: Major
>
> {code:java}
> Ignite ignite = Ignition.start();
> IgniteQueue queue = ignite.queue("Queue", 0, null);
> ignite.close();
> {code}
> This code returns null. We need to fix it or align the javadoc.
> Here's the initial discussion:
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-Queue-Documentation-or-Code-defect-td33703.html]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286485#comment-17286485
]
Atri Sharma commented on IGNITE-12508:
--
[~ilyak] Done, please see.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Atri Sharma
>Priority: Major
> Labels: newbie
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atri Sharma reassigned IGNITE-12508:
Assignee: Atri Sharma
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Atri Sharma
>Priority: Major
> Labels: newbie
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17285899#comment-17285899
]
Atri Sharma commented on IGNITE-12508:
--
[~ilyak] I dont see the option – is it an administrator only action?
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: kartheek b
>Priority: Major
> Labels: newbie
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284657#comment-17284657
]
Atri Sharma commented on IGNITE-12508:
--
PR is raised.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: kartheek b
>Priority: Major
> Labels: newbie
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
