[jira] [Assigned] (IGNITE-5597) Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache
[
https://issues.apache.org/jira/browse/IGNITE-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Yakushin reassigned IGNITE-5597:
---
Assignee: Andrei Yakushin
> Wrong javadoc in Affinity and AffinityFunction for REPLICATED cache
> ---
>
> Key: IGNITE-5597
> URL: https://issues.apache.org/jira/browse/IGNITE-5597
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Evgenii Zhuravlev
>Assignee: Andrei Yakushin
> Labels: javadoc
>
> RendezvoudAffinityFunction.getPartitions() Javadoc says:
> {code:java}
> * Note that for fully replicated caches this method should always
> * return {@code 1}.
> {code}
> but it's not true, it works the same as PARTITIONED cache.
> Affinity.mapKeyToNode(K key) javadoc says:
> {code:java}
> *
> * For fully replicated caches first node ID returned by {@link
> AffinityFunction}
> * is returned.
> *
> * For partitioned caches, primary node for the given key is
> returned.
> {code}
> it looks confusing, while REPLICATED cache has primary nodes for keys as
> PRATITIONED.
> Also,
> {code:java}
> * Provides affinity information to detect which node is primary and which
> nodes are
> * backups for a partitioned cache.
> {code}
> Affinity matter for REPLICATED cache too.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5627) Web Console: refactor grid columns menu
[ https://issues.apache.org/jira/browse/IGNITE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-5627: - Description: Currently, every menu that allows to toggle individual columns/categories has it's own implementation. What to do: 1. Create a global reusable component that implements that should: * Support cases when grid has regular columnDefs only and columnDefs with categories. * Not display items that are always visible/hidden. * Have it's own default button markup which can be replaced by transclusion slot. * Automatically enable groups during previous groupping when user groups by such item (old implementation had such an issue, see admin users list for live example). For example, if first grouping was by column User with column Email hidden, and then user switches to Email grouping, Email column should become visible in grid and should be hidden from menu. * Scroll enabled column/category into view. If category has multiple columns, scroll to first column of the set. When multiple columns/categories are enabled, do not scroll anywhere. 2. Use new component where appropriate and remove old copypasted code. was: Currently, every menu that allows to toggle individual columns/categories has it's own implementation. What to do: 1. Create a global reusable component that implements that should: * Support cases when grid has regular columnDefs only and columnDefs with categories. * Not display items that are always visible/hidden. * Have it's own default button markup which can be replaced by transclusion slot. * Automatically enable groups during previous groupping when user groups by such item (old implementation had such an issue, see admin users list for live example). For example, if first grouping was by column User with column Email hidden, and then user switches to Email grouping, Email column should become visible in grid and should be hidden from menu. 2. Use new component where appropriate and remove old copypasted code. > Web Console: refactor grid columns menu > --- > > Key: IGNITE-5627 > URL: https://issues.apache.org/jira/browse/IGNITE-5627 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: grid column selector.PNG > > > Currently, every menu that allows to toggle individual columns/categories has > it's own implementation. > What to do: > 1. Create a global reusable component that implements that should: > * Support cases when grid has regular columnDefs only and columnDefs with > categories. > * Not display items that are always visible/hidden. > * Have it's own default button markup which can be replaced by transclusion > slot. > * Automatically enable groups during previous groupping when user groups by > such item (old implementation had such an issue, see admin users list for > live example). For example, if first grouping was by column User with column > Email hidden, and then user switches to Email grouping, Email column should > become visible in grid and should be hidden from menu. > * Scroll enabled column/category into view. If category has multiple columns, > scroll to first column of the set. When multiple columns/categories are > enabled, do not scroll anywhere. > 2. Use new component where appropriate and remove old copypasted code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5627) Web Console: refactor grid columns menu
[ https://issues.apache.org/jira/browse/IGNITE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16069429#comment-16069429 ] Alexey Kuznetsov commented on IGNITE-5627: -- Looks good for me. > Web Console: refactor grid columns menu > --- > > Key: IGNITE-5627 > URL: https://issues.apache.org/jira/browse/IGNITE-5627 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: grid column selector.PNG > > > Currently, every menu that allows to toggle individual columns/categories has > it's own implementation. > What to do: > 1. Create a global reusable component that implements that should: > * Support cases when grid has regular columnDefs only and columnDefs with > categories. > * Not display items that are always visible/hidden. > * Have it's own default button markup which can be replaced by transclusion > slot. > * Automatically enable groups during previous groupping when user groups by > such item (old implementation had such an issue, see admin users list for > live example). For example, if first grouping was by column User with column > Email hidden, and then user switches to Email grouping, Email column should > become visible in grid and should be hidden from menu. > 2. Use new component where appropriate and remove old copypasted code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5627) Web Console: refactor grid columns menu
[ https://issues.apache.org/jira/browse/IGNITE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-5627: Assignee: Vasiliy Sisko (was: Alexey Kuznetsov) Vasiliy, could test this feature? > Web Console: refactor grid columns menu > --- > > Key: IGNITE-5627 > URL: https://issues.apache.org/jira/browse/IGNITE-5627 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: grid column selector.PNG > > > Currently, every menu that allows to toggle individual columns/categories has > it's own implementation. > What to do: > 1. Create a global reusable component that implements that should: > * Support cases when grid has regular columnDefs only and columnDefs with > categories. > * Not display items that are always visible/hidden. > * Have it's own default button markup which can be replaced by transclusion > slot. > * Automatically enable groups during previous groupping when user groups by > such item (old implementation had such an issue, see admin users list for > live example). For example, if first grouping was by column User with column > Email hidden, and then user switches to Email grouping, Email column should > become visible in grid and should be hidden from menu. > 2. Use new component where appropriate and remove old copypasted code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5627) Web Console: refactor grid columns menu
[ https://issues.apache.org/jira/browse/IGNITE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-5627: Assignee: Alexey Kuznetsov (was: Ilya Borisov) Please review. > Web Console: refactor grid columns menu > --- > > Key: IGNITE-5627 > URL: https://issues.apache.org/jira/browse/IGNITE-5627 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: grid column selector.PNG > > > Currently, every menu that allows to toggle individual columns/categories has > it's own implementation. > What to do: > 1. Create a global reusable component that implements that should: > * Support cases when grid has regular columnDefs only and columnDefs with > categories. > * Not display items that are always visible/hidden. > * Have it's own default button markup which can be replaced by transclusion > slot. > * Automatically enable groups during previous groupping when user groups by > such item (old implementation had such an issue, see admin users list for > live example). For example, if first grouping was by column User with column > Email hidden, and then user switches to Email grouping, Email column should > become visible in grid and should be hidden from menu. > 2. Use new component where appropriate and remove old copypasted code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5611) Web Console: update some of selects to new design
[ https://issues.apache.org/jira/browse/IGNITE-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16069390#comment-16069390 ] Ilya Borisov commented on IGNITE-5611: -- Me and [~vabramova] decided to use same menu item height as regular buttons (36px). Keep that in mind when looking at attached images. > Web Console: update some of selects to new design > - > > Key: IGNITE-5611 > URL: https://issues.apache.org/jira/browse/IGNITE-5611 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.1 > > Attachments: new-select-look.PNG, old select look.PNG > > > Update all selects that look [like this|^new-select-look.PNG] to look [like > that|^old select look.PNG]. > Notable changes: > 1. Add "All" default option to top of the menu. It should be unchecked when > no items are selected. It should be checked when all items are selected. When > all items are selected, click on "all" should unselect all items. When some > items are selected, "all" click should select all items. > 2. Selected checkbox icon should be of brand blue color. Unselected icons are > grey. Checkmark icon might look slightly different from new design, we will > sync checkbox implementations/design in a separate task anyway. > During testing, please make sure that *all* places that use bs-select > directive don't have regressions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5627) Web Console: refactor grid columns menu
[ https://issues.apache.org/jira/browse/IGNITE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-5627: - Attachment: grid column selector.PNG > Web Console: refactor grid columns menu > --- > > Key: IGNITE-5627 > URL: https://issues.apache.org/jira/browse/IGNITE-5627 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Attachments: grid column selector.PNG > > > Currently, every menu that allows to toggle individual columns/categories has > it's own implementation. > What to do: > 1. Create a global reusable component that implements that should: > * Support cases when grid has regular columnDefs only and columnDefs with > categories. > * Not display items that are always visible/hidden. > * Have it's own default button markup which can be replaced by transclusion > slot. > * Automatically enable groups during previous groupping when user groups by > such item (old implementation had such an issue, see admin users list for > live example). For example, if first grouping was by column User with column > Email hidden, and then user switches to Email grouping, Email column should > become visible in grid and should be hidden from menu. > 2. Use new component where appropriate and remove old copypasted code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5627) Web Console: refactor grid columns menu
Ilya Borisov created IGNITE-5627: Summary: Web Console: refactor grid columns menu Key: IGNITE-5627 URL: https://issues.apache.org/jira/browse/IGNITE-5627 Project: Ignite Issue Type: Sub-task Components: UI, wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Priority: Minor Currently, every menu that allows to toggle individual columns/categories has it's own implementation. What to do: 1. Create a global reusable component that implements that should: * Support cases when grid has regular columnDefs only and columnDefs with categories. * Not display items that are always visible/hidden. * Have it's own default button markup which can be replaced by transclusion slot. * Automatically enable groups during previous groupping when user groups by such item (old implementation had such an issue, see admin users list for live example). For example, if first grouping was by column User with column Email hidden, and then user switches to Email grouping, Email column should become visible in grid and should be hidden from menu. 2. Use new component where appropriate and remove old copypasted code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5627) Web Console: refactor grid columns menu
[ https://issues.apache.org/jira/browse/IGNITE-5627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-5627: - Description: Currently, every menu that allows to toggle individual columns/categories has it's own implementation. What to do: 1. Create a global reusable component that implements that should: * Support cases when grid has regular columnDefs only and columnDefs with categories. * Not display items that are always visible/hidden. * Have it's own default button markup which can be replaced by transclusion slot. * Automatically enable groups during previous groupping when user groups by such item (old implementation had such an issue, see admin users list for live example). For example, if first grouping was by column User with column Email hidden, and then user switches to Email grouping, Email column should become visible in grid and should be hidden from menu. 2. Use new component where appropriate and remove old copypasted code. was: Currently, every menu that allows to toggle individual columns/categories has it's own implementation. What to do: 1. Create a global reusable component that implements that should: * Support cases when grid has regular columnDefs only and columnDefs with categories. * Not display items that are always visible/hidden. * Have it's own default button markup which can be replaced by transclusion slot. * Automatically enable groups during previous groupping when user groups by such item (old implementation had such an issue, see admin users list for live example). For example, if first grouping was by column User with column Email hidden, and then user switches to Email grouping, Email column should become visible in grid and should be hidden from menu. 2. Use new component where appropriate and remove old copypasted code. > Web Console: refactor grid columns menu > --- > > Key: IGNITE-5627 > URL: https://issues.apache.org/jira/browse/IGNITE-5627 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > Currently, every menu that allows to toggle individual columns/categories has > it's own implementation. > What to do: > 1. Create a global reusable component that implements that should: > * Support cases when grid has regular columnDefs only and columnDefs with > categories. > * Not display items that are always visible/hidden. > * Have it's own default button markup which can be replaced by transclusion > slot. > * Automatically enable groups during previous groupping when user groups by > such item (old implementation had such an issue, see admin users list for > live example). For example, if first grouping was by column User with column > Email hidden, and then user switches to Email grouping, Email column should > become visible in grid and should be hidden from menu. > 2. Use new component where appropriate and remove old copypasted code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16069082#comment-16069082 ] Denis Magda commented on IGNITE-5618: - Gotcha, now it's clear. Please take over this and make sure the issue is fixed before 2.1. BTW, do you see any unique exception? We need to document this for scenarios when someone tries to allocate memory for a non-default region. > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: .NET > Fix For: 2.1 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5622) Streaming and batching for ODBC driver
[ https://issues.apache.org/jira/browse/IGNITE-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16069067#comment-16069067 ] Denis Magda commented on IGNITE-5622: - [~vozerov], good, by some reason [~isapego] forgot about this when the functionality was discussed between us :) In any case, let's weight all pros and cons of the streaming mode for ODBC once you're back. Probably, it's not that essential. > Streaming and batching for ODBC driver > -- > > Key: IGNITE-5622 > URL: https://issues.apache.org/jira/browse/IGNITE-5622 > Project: Ignite > Issue Type: Task >Affects Versions: 2.0 >Reporter: Denis Magda >Assignee: Igor Sapego > Fix For: 2.2 > > > Ignite ODBC driver has to support both streaming and batching mode is a > similar way it's done for JDBC: > http://apache-ignite-developers.2346864.n4.nabble.com/Batch-DML-queries-design-discussion-td12859.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-5624) SQL: LTRIM/RTRIM not working with multiple character
[
https://issues.apache.org/jira/browse/IGNITE-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-5624.
-
Resolution: Duplicate
> SQL: LTRIM/RTRIM not working with multiple character
>
>
> Key: IGNITE-5624
> URL: https://issues.apache.org/jira/browse/IGNITE-5624
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>
> LTRIM/RTRIM is working only for one char and not for a word (Multiple
> Character). For instance, the example below doesn't work for Ignite:
> {code}
> SELECT product_name, LTRIM(product_name, 'Monitor ') "Short Name"
>FROM products
>WHERE product_name LIKE 'Monitor%';
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (IGNITE-5624) SQL: LTRIM/RTRIM not working with multiple character
[
https://issues.apache.org/jira/browse/IGNITE-5624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-5624.
---
> SQL: LTRIM/RTRIM not working with multiple character
>
>
> Key: IGNITE-5624
> URL: https://issues.apache.org/jira/browse/IGNITE-5624
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>
> LTRIM/RTRIM is working only for one char and not for a word (Multiple
> Character). For instance, the example below doesn't work for Ignite:
> {code}
> SELECT product_name, LTRIM(product_name, 'Monitor ') "Short Name"
>FROM products
>WHERE product_name LIKE 'Monitor%';
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5626) SQL TRIM function is not working properly
[
https://issues.apache.org/jira/browse/IGNITE-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-5626:
Attachment: SqlTrimTest.java
> SQL TRIM function is not working properly
> -
>
> Key: IGNITE-5626
> URL: https://issues.apache.org/jira/browse/IGNITE-5626
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
> Fix For: 2.1
>
> Attachments: SqlTrimTest.java
>
>
> {{TRIM}} function trims only first char instead of the whole provided string.
> Trailing chars are not trimmed at all.
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5626) SQL TRIM function is not working properly
[
https://issues.apache.org/jira/browse/IGNITE-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-5626:
Description:
{{TRIM}} function trims only first char instead of the whole provided string.
Trailing chars are not trimmed at all.
Reproducer attached.
was:{{TRIM}} function trims only one char instead of the whole provided
string. Reproducer attached.
> SQL TRIM function is not working properly
> -
>
> Key: IGNITE-5626
> URL: https://issues.apache.org/jira/browse/IGNITE-5626
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
> Fix For: 2.1
>
>
> {{TRIM}} function trims only first char instead of the whole provided string.
> Trailing chars are not trimmed at all.
> Reproducer attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5626) SQL TRIM function is not working properly
Valentin Kulichenko created IGNITE-5626:
---
Summary: SQL TRIM function is not working properly
Key: IGNITE-5626
URL: https://issues.apache.org/jira/browse/IGNITE-5626
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.0
Reporter: Valentin Kulichenko
Fix For: 2.1
{{TRIM}} function trims only one char instead of the whole provided string.
Reproducer attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5622) Streaming and batching for ODBC driver
[ https://issues.apache.org/jira/browse/IGNITE-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068974#comment-16068974 ] Vladimir Ozerov commented on IGNITE-5622: - [~dmagda], Batching is already implemented, see IGNITE-4370. Streaming is extremely questionable feature, I am against implementing it at all. > Streaming and batching for ODBC driver > -- > > Key: IGNITE-5622 > URL: https://issues.apache.org/jira/browse/IGNITE-5622 > Project: Ignite > Issue Type: Task >Affects Versions: 2.0 >Reporter: Denis Magda >Assignee: Igor Sapego > Fix For: 2.2 > > > Ignite ODBC driver has to support both streaming and batching mode is a > similar way it's done for JDBC: > http://apache-ignite-developers.2346864.n4.nabble.com/Batch-DML-queries-design-discussion-td12859.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5625) SQL: auto-increment of fields
Denis Magda created IGNITE-5625: --- Summary: SQL: auto-increment of fields Key: IGNITE-5625 URL: https://issues.apache.org/jira/browse/IGNITE-5625 Project: Ignite Issue Type: Task Affects Versions: 2.0 Reporter: Denis Magda Fix For: 2.3 SQL engine should be able to auto-increment fields. At least this has to be supported for primary keys. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5624) SQL: LTRIM/RTRIM not working with multiple character
Denis Magda created IGNITE-5624:
---
Summary: SQL: LTRIM/RTRIM not working with multiple character
Key: IGNITE-5624
URL: https://issues.apache.org/jira/browse/IGNITE-5624
Project: Ignite
Issue Type: Task
Reporter: Denis Magda
LTRIM/RTRIM is working only for one char and not for a word (Multiple
Character). For instance, the example below doesn't work for Ignite:
{code}
SELECT product_name, LTRIM(product_name, 'Monitor ') "Short Name"
FROM products
WHERE product_name LIKE 'Monitor%';
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5623) DDL needs to support DEFAULT operator
[
https://issues.apache.org/jira/browse/IGNITE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-5623:
Fix Version/s: (was: 2.1)
2.2
> DDL needs to support DEFAULT operator
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> There should be a way to set a default value for a column/field if the one is
> not specified during an insert operation. In general, we need to support
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
> ID int,
> FirstName varchar(255),
> Age int,
> City varchar(255) DEFAULT 'Sandnes'
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5623) DDL needs to support DEFAULT operator
Denis Magda created IGNITE-5623:
---
Summary: DDL needs to support DEFAULT operator
Key: IGNITE-5623
URL: https://issues.apache.org/jira/browse/IGNITE-5623
Project: Ignite
Issue Type: Task
Reporter: Denis Magda
Assignee: Alexander Paschenko
There should be a way to set a default value for a column/field if the one is
not specified during an insert operation. In general, we need to support
{{ DEFAULT }} in a way it's show below:
{code}
CREATE TABLE Persons (
ID int,
FirstName varchar(255),
Age int,
City varchar(255) DEFAULT 'Sandnes'
);
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5623) DDL needs to support DEFAULT operator
[
https://issues.apache.org/jira/browse/IGNITE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-5623:
Affects Version/s: 2.0
> DDL needs to support DEFAULT operator
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> There should be a way to set a default value for a column/field if the one is
> not specified during an insert operation. In general, we need to support
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
> ID int,
> FirstName varchar(255),
> Age int,
> City varchar(255) DEFAULT 'Sandnes'
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5623) DDL needs to support DEFAULT operator
[
https://issues.apache.org/jira/browse/IGNITE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-5623:
Fix Version/s: 2.1
> DDL needs to support DEFAULT operator
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> There should be a way to set a default value for a column/field if the one is
> not specified during an insert operation. In general, we need to support
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
> ID int,
> FirstName varchar(255),
> Age int,
> City varchar(255) DEFAULT 'Sandnes'
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5622) Streaming and batching for ODBC driver
Denis Magda created IGNITE-5622: --- Summary: Streaming and batching for ODBC driver Key: IGNITE-5622 URL: https://issues.apache.org/jira/browse/IGNITE-5622 Project: Ignite Issue Type: Task Affects Versions: 2.0 Reporter: Denis Magda Assignee: Igor Sapego Fix For: 2.2 Ignite ODBC driver has to support both streaming and batching mode is a similar way it's done for JDBC: http://apache-ignite-developers.2346864.n4.nabble.com/Batch-DML-queries-design-discussion-td12859.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization
[
https://issues.apache.org/jira/browse/IGNITE-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068875#comment-16068875
]
ASF GitHub Bot commented on IGNITE-3935:
GitHub user 1vanan opened a pull request:
https://github.com/apache/ignite/pull/2220
Ignite 3935
Issue https://issues.apache.org/jira/browse/IGNITE-3935
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/1vanan/ignite ignite-3935
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2220.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 #2220
commit 0c0ebb844de5f392e10522d1f6abe70b82dcfb04
Author: ivanan
Date: 2017-06-29T19:31:16Z
initial commit
commit dab3fc1a702ec125b1a26dfc5c1a155cd245ed60
Author: ivanan
Date: 2017-06-29T19:51:27Z
StreamingExample & StreamingExampleSelfTest was added
> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A
> will be used for the deserialization of the whole object's state, i.e.,
> including all its fields that can be custom objects loaded by ClassLoader B.
> In a basic scenario we can have an object of some Ignite class that is
> presented in the classpath. That Ignite class may enclose an object that is
> loaded by peer-class-loading class loader. The deserialization will fail
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg)
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException,
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite =
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache =
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr =
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068801#comment-16068801 ] Pavel Tupitsyn commented on IGNITE-5618: [~dmagda] we are talking about 32-bit process on 64-bit machine. You can have all the RAM in the world, but 32-bit process can only support 2-4GB (depending on OS). So we get 16 GB of ram on a machine, and 80% of this does not fit into 32-bit process address space. > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: .NET > Fix For: 2.1 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5621) Support BINARY and VARBINARY types for C++ and ODBC
Denis Magda created IGNITE-5621: --- Summary: Support BINARY and VARBINARY types for C++ and ODBC Key: IGNITE-5621 URL: https://issues.apache.org/jira/browse/IGNITE-5621 Project: Ignite Issue Type: Task Affects Versions: 2.0 Reporter: Denis Magda Assignee: Igor Sapego Fix For: 2.2 We need to support BINARY and VARBINARY types at C++ and ODBC levels. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5620) Meaningful error codes and types of exceptions for SQL operations
[
https://issues.apache.org/jira/browse/IGNITE-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-5620:
Affects Version/s: 2.0
> Meaningful error codes and types of exceptions for SQL operations
> --
>
> Key: IGNITE-5620
> URL: https://issues.apache.org/jira/browse/IGNITE-5620
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> Presently, SQL engine throws a generic type of exception with custom text in
> case of an operation failure. In result, Ignite ODBC driver returns a similar
> error code (2000) for different kind of failures.
> For example, error code 2000 is returned for the following
> {code}
> Duplicate key during INSERT [key=CorpcontactcountKey [idHash=1412656257,
> hash=2004096461, mdn=9192]]
> {code}
> {code}
> Failed to parse query: INSERT INTO "DG".Corpcontactcount
> (mdn,contactcount,lastupdatetime)
> values(?,?,?,?)
> {code}
> {code}
> Wrong value has been set [typeName=Pocsubscrinfo, fieldName=vocoderid,
> fieldType=short, assignedValueType=byte] Error Code: 2000
> {code}
> The following has to be done:
> * Create unique types of exceptions for Java whenever applicable.
> * Add {{errorCode}} parameter and method to a generic SQL exception.
> * ODBC and JDBC drivers have to return unique codes based on the exception
> code or type.
> * All the codes have to be documented on readme.io.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5620) Meaningful error codes and types of exceptions for SQL operations
[
https://issues.apache.org/jira/browse/IGNITE-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-5620:
Fix Version/s: 2.2
> Meaningful error codes and types of exceptions for SQL operations
> --
>
> Key: IGNITE-5620
> URL: https://issues.apache.org/jira/browse/IGNITE-5620
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> Presently, SQL engine throws a generic type of exception with custom text in
> case of an operation failure. In result, Ignite ODBC driver returns a similar
> error code (2000) for different kind of failures.
> For example, error code 2000 is returned for the following
> {code}
> Duplicate key during INSERT [key=CorpcontactcountKey [idHash=1412656257,
> hash=2004096461, mdn=9192]]
> {code}
> {code}
> Failed to parse query: INSERT INTO "DG".Corpcontactcount
> (mdn,contactcount,lastupdatetime)
> values(?,?,?,?)
> {code}
> {code}
> Wrong value has been set [typeName=Pocsubscrinfo, fieldName=vocoderid,
> fieldType=short, assignedValueType=byte] Error Code: 2000
> {code}
> The following has to be done:
> * Create unique types of exceptions for Java whenever applicable.
> * Add {{errorCode}} parameter and method to a generic SQL exception.
> * ODBC and JDBC drivers have to return unique codes based on the exception
> code or type.
> * All the codes have to be documented on readme.io.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5620) Meaningful error codes and types of exceptions for SQL operations
Denis Magda created IGNITE-5620:
---
Summary: Meaningful error codes and types of exceptions for SQL
operations
Key: IGNITE-5620
URL: https://issues.apache.org/jira/browse/IGNITE-5620
Project: Ignite
Issue Type: Task
Reporter: Denis Magda
Assignee: Alexander Paschenko
Presently, SQL engine throws a generic type of exception with custom text in
case of an operation failure. In result, Ignite ODBC driver returns a similar
error code (2000) for different kind of failures.
For example, error code 2000 is returned for the following
{code}
Duplicate key during INSERT [key=CorpcontactcountKey [idHash=1412656257,
hash=2004096461, mdn=9192]]
{code}
{code}
Failed to parse query: INSERT INTO "DG".Corpcontactcount
(mdn,contactcount,lastupdatetime)
values(?,?,?,?)
{code}
{code}
Wrong value has been set [typeName=Pocsubscrinfo, fieldName=vocoderid,
fieldType=short, assignedValueType=byte] Error Code: 2000
{code}
The following has to be done:
* Create unique types of exceptions for Java whenever applicable.
* Add {{errorCode}} parameter and method to a generic SQL exception.
* ODBC and JDBC drivers have to return unique codes based on the exception code
or type.
* All the codes have to be documented on readme.io.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-4901) Decrease logging level for DataStremer retry
[
https://issues.apache.org/jira/browse/IGNITE-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068733#comment-16068733
]
Alexey Kukushkin commented on IGNITE-4901:
--
Presently when DataStreamer is flushing data and cluster topology changes, the
DataStreamer would output an ERROR message to the console and retry flushing
the data with the latest topology.
We have this IGNITE-4901 issue asking to decrease logging level since a
topology change is normal and DataStreamer reliably handles it.
In addition to setting the log level to INFO, I suggest we change Ignite to
fail to update the cache only if MAJOR topology version changed (another node
joined/left) since minor version change (registering/unregistering another
cache) does not impact updating the cache unless we delete the cache-in-use but
the latter error is handled differently anyway.
Please let me know if anyone has objections or comments. Otherwise I will
submit this solution.
> Decrease logging level for DataStremer retry
> -
>
> Key: IGNITE-4901
> URL: https://issues.apache.org/jira/browse/IGNITE-4901
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>Assignee: Alexey Kukushkin
>Priority: Trivial
>
> When topology are changed DataStreame log the following error message which
> confused users. Need to decrease logging level for this case.
> {noformat}
> ERROR Failed to execute compound future reducer: GridCompoundFuture [...]
> class org.apache.ignite.IgniteCheckedException: DataStreamer request failed
> [node=9d405934-eb78-4452-a3a8-fc44c3c61e76]
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
>
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
>
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1080)
>
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:708)
>
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:101)
>
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:671)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: DataStreamer will
> retry data transfer at stable topology [...]
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:337)
>
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:297)
>
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:56)
>
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:86)
>
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5187) Dynamic index create/drop tests are flaky
[
https://issues.apache.org/jira/browse/IGNITE-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068544#comment-16068544
]
ASF GitHub Bot commented on IGNITE-5187:
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/2219
IGNITE-5187 Made test more reliable.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5187
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2219.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 #2219
commit 2c3d443ac6039f83f735fe1ec594412d93bf25a3
Author: Alexander Paschenko
Date: 2017-06-29T16:12:10Z
IGNITE-5187 Made test more reliable.
> Dynamic index create/drop tests are flaky
> -
>
> Key: IGNITE-5187
> URL: https://issues.apache.org/jira/browse/IGNITE-5187
> Project: Ignite
> Issue Type: Test
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
> Fix For: 2.1
>
>
> Currently we rely on {{Thread.sleep}}. Probably we need something more
> reliable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5187) Dynamic index create/drop tests are flaky
[
https://issues.apache.org/jira/browse/IGNITE-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko reassigned IGNITE-5187:
---
Assignee: Semen Boikov (was: Alexander Paschenko)
> Dynamic index create/drop tests are flaky
> -
>
> Key: IGNITE-5187
> URL: https://issues.apache.org/jira/browse/IGNITE-5187
> Project: Ignite
> Issue Type: Test
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
> Fix For: 2.1
>
>
> Currently we rely on {{Thread.sleep}}. Probably we need something more
> reliable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068517#comment-16068517 ] Denis Magda commented on IGNITE-5618: - [~agoncharuk], take a look at this. > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: .NET > Fix For: 2.1 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-5618: Priority: Blocker (was: Major) > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Blocker > Labels: .NET > Fix For: 2.1 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068515#comment-16068515 ] Denis Magda commented on IGNITE-5618: - [~ptupitsyn], agree, please send the message to the dev list to raise the awareness. Specify what's the reason for that. Honestly, I didn't know and didn't get why 32-bit systems have such a limitation. > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.1 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5619) CPP: Implement Compute::Execute() for Ignite C++
Igor Sapego created IGNITE-5619:
---
Summary: CPP: Implement Compute::Execute() for Ignite C++
Key: IGNITE-5619
URL: https://issues.apache.org/jira/browse/IGNITE-5619
Project: Ignite
Issue Type: New Feature
Components: platforms
Affects Versions: 2.0
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.1
Need to implement method {{Compute::Execute}} and {{Compute::ExecuteAsync}} for
Ignite C++
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-4887) Support for starting transaction in another thread
[
https://issues.apache.org/jira/browse/IGNITE-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068389#comment-16068389
]
Alexey Kuznetsov edited comment on IGNITE-4887 at 6/29/17 2:10 PM:
---
[~yzhdanov] I attached test HangTest.txt which hangs. My question is the
following, is it bug or not ?
was (Author: alexey kuznetsov):
[~yzhdanov] I attached test which hangs. My question is the following, is it
bug or not ?
> Support for starting transaction in another thread
> --
>
> Key: IGNITE-4887
> URL: https://issues.apache.org/jira/browse/IGNITE-4887
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.9
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Attachments: HangTest.txt
>
>
> Consider the following pseudo-code:
> {code:xml}
> IgniteTransactions transactions = ignite1.transactions();
> Transaction tx = startTransaction(transactions);
> cache.put("key1", 1);
> tx.stop();
> {code}
> And in another thread:
> {code:xml}
> transactions.txStart(tx);
> cache.put("key3", 3);
> cache.remove("key2");
> tx.commit();
> {code}
> The Api should be implemented , that let you continue transaction in another
> thread.
> method stop() should mark the transaction as unavailable for further commit.
> method txStart() should resume the transaction.
> reason behind the proposal :
> Consider the next scenario:
> we begin transaction, doing some changes and start async future that will be
> able to introduce futher changes into transaction and commit it in the end.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-4887) Support for starting transaction in another thread
[
https://issues.apache.org/jira/browse/IGNITE-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068389#comment-16068389
]
Alexey Kuznetsov commented on IGNITE-4887:
--
[~yzhdanov] I attached test which hangs. My question is the following, is it
bug or not ?
> Support for starting transaction in another thread
> --
>
> Key: IGNITE-4887
> URL: https://issues.apache.org/jira/browse/IGNITE-4887
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.9
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Attachments: HangTest.txt
>
>
> Consider the following pseudo-code:
> {code:xml}
> IgniteTransactions transactions = ignite1.transactions();
> Transaction tx = startTransaction(transactions);
> cache.put("key1", 1);
> tx.stop();
> {code}
> And in another thread:
> {code:xml}
> transactions.txStart(tx);
> cache.put("key3", 3);
> cache.remove("key2");
> tx.commit();
> {code}
> The Api should be implemented , that let you continue transaction in another
> thread.
> method stop() should mark the transaction as unavailable for further commit.
> method txStart() should resume the transaction.
> reason behind the proposal :
> Consider the next scenario:
> we begin transaction, doing some changes and start async future that will be
> able to introduce futher changes into transaction and commit it in the end.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4887) Support for starting transaction in another thread
[
https://issues.apache.org/jira/browse/IGNITE-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-4887:
-
Attachment: HangTest.txt
> Support for starting transaction in another thread
> --
>
> Key: IGNITE-4887
> URL: https://issues.apache.org/jira/browse/IGNITE-4887
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.9
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Attachments: HangTest.txt
>
>
> Consider the following pseudo-code:
> {code:xml}
> IgniteTransactions transactions = ignite1.transactions();
> Transaction tx = startTransaction(transactions);
> cache.put("key1", 1);
> tx.stop();
> {code}
> And in another thread:
> {code:xml}
> transactions.txStart(tx);
> cache.put("key3", 3);
> cache.remove("key2");
> tx.commit();
> {code}
> The Api should be implemented , that let you continue transaction in another
> thread.
> method stop() should mark the transaction as unavailable for further commit.
> method txStart() should resume the transaction.
> reason behind the proposal :
> Consider the next scenario:
> we begin transaction, doing some changes and start async future that will be
> able to introduce futher changes into transaction and commit it in the end.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5076) Optimization of multi-threaded start nodes in tests
[ https://issues.apache.org/jira/browse/IGNITE-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068365#comment-16068365 ] Andrey Gura commented on IGNITE-5076: - LGTM. Thanks for contribution! Merged into master branch. > Optimization of multi-threaded start nodes in tests > --- > > Key: IGNITE-5076 > URL: https://issues.apache.org/jira/browse/IGNITE-5076 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Dmitriy Govorukhin >Assignee: Vyacheslav Koptilin > Fix For: 2.1 > > > Concurrent start,will more effective if we have coordinator before, > multi-threaded start nodes. If start all nodes concurrent, they will be > compete for coordinator role, it is not effective way. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[
https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068357#comment-16068357
]
Vladislav Pyatkov commented on IGNITE-5038:
---
[~sboikov],
Thank for review and comment.
I have make new observe and understood what you are wary.
In all cases when class loader was used on BinaryReader, I am checking
{{useCache}}, that should by solve issue with caching fields classes of cache
object.
I have added throw through whole marshallers {{useCache}} flag, because Binary
in some case can use Optimizer and Jdk through it.
> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladislav Pyatkov
> Labels: features
> Fix For: 2.1
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize
> an object using a context class loader if it failed to do so with a custom
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5582) CPP: Implement Compute::Broabcast() for Ignite C++
[
https://issues.apache.org/jira/browse/IGNITE-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068333#comment-16068333
]
Igor Sapego commented on IGNITE-5582:
-
Ready. Waiting for IGNITE-5576 to put on review.
> CPP: Implement Compute::Broabcast() for Ignite C++
> --
>
> Key: IGNITE-5582
> URL: https://issues.apache.org/jira/browse/IGNITE-5582
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: cpp
> Fix For: 2.1
>
>
> Need to implement method {{Compute::Broadcast}} and
> {{Compute::BroadcastAsync}} for Ignite C++.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5576) CPP: Implement Compute::Run() for Ignite C++
[
https://issues.apache.org/jira/browse/IGNITE-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068325#comment-16068325
]
ASF GitHub Bot commented on IGNITE-5576:
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/2218
IGNITE-5576: Implemented Compute::Broadcast for C++
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-5582
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2218.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 #2218
commit e7311199eebbe9133f7d3cebe6f6f2a38bd67762
Author: Igor Sapego
Date: 2017-06-22T16:13:19Z
IGNITE-5576: Added Compute::Run()
commit b6c16a5170e0f50c49096f8ba6b0e7cc33312eaa
Author: Igor Sapego
Date: 2017-06-22T16:57:12Z
IGNITE-5576: Added tests. Fixed bug
commit 2618d312008d3961323b4b788667548c0f2b1223
Author: Igor Sapego
Date: 2017-06-23T17:14:03Z
IGNITE-5576: Fixed config
commit efb53f9105154a32c287c02ba39c3a270ee3d2c2
Author: Igor Sapego
Date: 2017-06-23T17:28:15Z
IGNITE-5576: Edited documentation
commit 561519af001b93ae195330fa8e2c2ab4db3046b3
Author: Igor Sapego
Date: 2017-06-27T12:02:02Z
IGNITE-5582: Refactoring
commit b16fb1c3e522835e4286cdb5b0378f9329276df0
Author: Igor Sapego
Date: 2017-06-28T16:31:23Z
IGNITE-5582: Added MultipleJobComputeTaskHolder
commit d505d10206dcc2ce752b72179efce6e6794270d3
Author: Igor Sapego
Date: 2017-06-29T12:55:33Z
IGNITE-5582: Added tests and fixed issues.
commit ab2a6aae554a1be0a7feade1916fea16091daccd
Author: Igor Sapego
Date: 2017-06-29T13:13:46Z
IGNITE-5582: Added Error tests
commit e9c298085374611f40cfe5aa92a470f34d04ddc3
Author: Igor Sapego
Date: 2017-06-29T13:20:11Z
IGNITE-5582: Added tests
> CPP: Implement Compute::Run() for Ignite C++
>
>
> Key: IGNITE-5576
> URL: https://issues.apache.org/jira/browse/IGNITE-5576
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Labels: cpp
> Fix For: 2.1
>
>
> Need to implement method {{Compute::Run}} and {{Compute::RunAsync}} for
> Ignite C++
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5611) Web Console: update some of selects to new design
[ https://issues.apache.org/jira/browse/IGNITE-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-5611: Assignee: Alexey Kuznetsov (was: Dmitriy Shabalin) > Web Console: update some of selects to new design > - > > Key: IGNITE-5611 > URL: https://issues.apache.org/jira/browse/IGNITE-5611 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.1 > > Attachments: new-select-look.PNG, old select look.PNG > > > Update all selects that look [like this|^new-select-look.PNG] to look [like > that|^old select look.PNG]. > Notable changes: > 1. Add "All" default option to top of the menu. It should be unchecked when > no items are selected. It should be checked when all items are selected. When > all items are selected, click on "all" should unselect all items. When some > items are selected, "all" click should select all items. > 2. Selected checkbox icon should be of brand blue color. Unselected icons are > grey. Checkmark icon might look slightly different from new design, we will > sync checkbox implementations/design in a separate task anyway. > During testing, please make sure that *all* places that use bs-select > directive don't have regressions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-5611) Web Console: update some of selects to new design
[ https://issues.apache.org/jira/browse/IGNITE-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-5611. > Web Console: update some of selects to new design > - > > Key: IGNITE-5611 > URL: https://issues.apache.org/jira/browse/IGNITE-5611 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.1 > > Attachments: new-select-look.PNG, old select look.PNG > > > Update all selects that look [like this|^new-select-look.PNG] to look [like > that|^old select look.PNG]. > Notable changes: > 1. Add "All" default option to top of the menu. It should be unchecked when > no items are selected. It should be checked when all items are selected. When > all items are selected, click on "all" should unselect all items. When some > items are selected, "all" click should select all items. > 2. Selected checkbox icon should be of brand blue color. Unselected icons are > grey. Checkmark icon might look slightly different from new design, we will > sync checkbox implementations/design in a separate task anyway. > During testing, please make sure that *all* places that use bs-select > directive don't have regressions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5611) Web Console: update some of selects to new design
[ https://issues.apache.org/jira/browse/IGNITE-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-5611: - Fix Version/s: 2.1 > Web Console: update some of selects to new design > - > > Key: IGNITE-5611 > URL: https://issues.apache.org/jira/browse/IGNITE-5611 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.1 > > Attachments: new-select-look.PNG, old select look.PNG > > > Update all selects that look [like this|^new-select-look.PNG] to look [like > that|^old select look.PNG]. > Notable changes: > 1. Add "All" default option to top of the menu. It should be unchecked when > no items are selected. It should be checked when all items are selected. When > all items are selected, click on "all" should unselect all items. When some > items are selected, "all" click should select all items. > 2. Selected checkbox icon should be of brand blue color. Unselected icons are > grey. Checkmark icon might look slightly different from new design, we will > sync checkbox implementations/design in a separate task anyway. > During testing, please make sure that *all* places that use bs-select > directive don't have regressions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5401) Investigate hangs in JDBC driver testIndexState()
[
https://issues.apache.org/jira/browse/IGNITE-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko reassigned IGNITE-5401:
---
Assignee: Sergey Chugunov (was: Alexander Paschenko)
> Investigate hangs in JDBC driver testIndexState()
> -
>
> Key: IGNITE-5401
> URL: https://issues.apache.org/jira/browse/IGNITE-5401
> Project: Ignite
> Issue Type: Task
> Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Chugunov
> Fix For: 2.1
>
>
> Two JDBC tests hang from time to time. Root cause is the same as tests are
> similar.
> 1)
> org.apache.ignite.jdbc.thin.JdbcThinDynamicIndexAbstractSelfTest#testIndexState
> 2)
> org.apache.ignite.internal.jdbc2.JdbcDynamicIndexAbstractSelfTest#testIndexState
> Failures are noly happen in ATOMIC PARTITIONED cache (with and without
> "near").
> Stack trace:
> {noformat}
> [17:37:00] : [Step 4/5] Thread
> [name="test-runner-#22990%thin.JdbcThinDynamicIndexAtomicPartitionedSelfTest%",
> id=29018, state=WAITING, blockCnt=0, waitCnt=4]
> [17:37:00] : [Step 4/5] at sun.misc.Unsafe.park(Native Method)
> [17:37:00] : [Step 4/5] at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:315)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:176)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:262)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:780)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:757)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.binary.BinaryContext.descriptorForClass(BinaryContext.java:628)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:248)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:371)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:849)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:799)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1769)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapSingleUpdate(GridNearAtomicSingleUpdateFuture.java:546)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:451)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:440)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1161)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:650)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2329)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.distributed.near.GridNearAtomicCache.put(GridNearAtomicCache.java:444)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2306)
> [17:37:00] : [Step 4/5] at
> o.a.i.i.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1494)
> [17:37:00] : [Step 4/5] at
> o.a.i.jdbc.thin.JdbcThinDynamicIndexAbstractSelfTest.testIndexState(JdbcThinDynamicIndexAbstractSelfTest.java:273)
> [17:37:00] : [Step 4/5] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [17:37:00] : [Step 4/5] at
> sun.reflect.NativeMethodAccesso
[jira] [Updated] (IGNITE-5617) Web Console: Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage
[ https://issues.apache.org/jira/browse/IGNITE-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-5617: - Summary: Web Console: Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage (was: Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage) > Web Console: Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent > storage > - > > Key: IGNITE-5617 > URL: https://issues.apache.org/jira/browse/IGNITE-5617 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > > As of new persistent storage donated to Ignite it make sense to > migrate from MongoDB+NodeJS to use some Java-based Web Server + Ignite+PS. > This will give fault tolerance Out Of The Box and minimize third-party > dependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5617) Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage
[ https://issues.apache.org/jira/browse/IGNITE-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-5617: - Component/s: wizards > Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage > > > Key: IGNITE-5617 > URL: https://issues.apache.org/jira/browse/IGNITE-5617 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > > As of new persistent storage donated to Ignite it make sense to > migrate from MongoDB+NodeJS to use some Java-based Web Server + Ignite+PS. > This will give fault tolerance Out Of The Box and minimize third-party > dependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-1090) GridCachePartitionedOptimisticTxNodeRestartTest hangs when node lefts topology
[
https://issues.apache.org/jira/browse/IGNITE-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-1090:
---
Labels: Muted_test test-fail (was: Muted_test)
> GridCachePartitionedOptimisticTxNodeRestartTest hangs when node lefts topology
> --
>
> Key: IGNITE-1090
> URL: https://issues.apache.org/jira/browse/IGNITE-1090
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Denis Magda
>Priority: Critical
> Labels: Muted_test, test-fail
> Fix For: 2.1
>
>
> The test hangs with the following errors:
> {noformat}
> [16:26:33] (err) Failed to execute compound future reducer: Compound future
> listener: GridCompoundIdentityFuture [super=GridCompoundFuture [lsnrCalls=0,
> finished=false, rdc=Map reducer: {}, init=true,
> res=java.util.concurrent.atomic.AtomicMarkableReference@3c6fff03, err=null,
> done=false, cancelled=false, err=null, futs=[true]]]class
> org.apache.ignite.IgniteCheckedException: Failed to wait for topology version
> to change: AffinityTopologyVersion [topVer=274, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.cache.distributed.GridFutureRemapTimeoutObject.onTimeout(GridFutureRemapTimeoutObject.java:64)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:158)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: Remote
> node left grid (will retry): 703c58e1-e099-4f22-b5c3-6c3676338007
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onNodeLeft(GridNearGetFuture.java:215)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$3.onEvent(GridCacheMvccManager.java:186)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:745)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:730)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:270)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:1719)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:1910)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:1758)
> ... 2 more
> {noformat}
> This issue appeared after IGNITE-882 was fixed. Until it wasn't fixed the
> tests hung because of this issue:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Remote node ID is
> not as expected [expected=9019c94c-84f5-4065-89b1-f16fdf708009,
> rcvd=707ed613-1b65-4771-ac98-5faa6857e007]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeHandshake(TcpCommunicationSpi.java:2203)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2025)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068242#comment-16068242 ] Pavel Tupitsyn commented on IGNITE-5618: Same problem is in Java, need to discuss this on dev list, I think. > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.1 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-5613:
Assignee: Alexey Goncharuk
> AtomicSequence usage inside transactions may cause deadlock
> ---
>
> Key: IGNITE-5613
> URL: https://issues.apache.org/jira/browse/IGNITE-5613
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
> Labels: important
> Fix For: 2.1
>
>
> Consider the following update scenario:
> {code}
> Thread 1:
> Transaction tx = txStart() {
> get(key); // Acquires lock;
> seq.incrementAndGet();
> }
> Thread 2:
> seq.incrementAndGet();
> {code}
> Let's now assume that:
> * Sequence is exhausted and needs a non-local update
> * Thread 1 acquired lock on topology version N
> * Topology version changes
> * Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
> which waits for topology version N+1 to become available
> * Thread 1 attemts to incrementAndGet().
> Since the lock is already held, thread 2 waits for the concurrent update to
> complete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
[ https://issues.apache.org/jira/browse/IGNITE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-5618: --- Description: Default MemoryPolicyConfiguration settings do not take process bitness into account. We can't use 80% of RAM under 32-bit mode. * Add a suite on TC which runs .NET tests on 32 bits was:Default MemoryPolicyConfiguration settings do not take process bitness into account. We can't use 80% of RAM under 32-bit mode. > .NET: Ignite fails with OOM on startup under x86 (32 bit) with default > configuration > > > Key: IGNITE-5618 > URL: https://issues.apache.org/jira/browse/IGNITE-5618 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.0 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.1 > > > Default MemoryPolicyConfiguration settings do not take process bitness into > account. We can't use 80% of RAM under 32-bit mode. > * Add a suite on TC which runs .NET tests on 32 bits -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5444) Collections.singletonList is not properly serialized by binary marshaller
[
https://issues.apache.org/jira/browse/IGNITE-5444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068223#comment-16068223
]
ASF GitHub Bot commented on IGNITE-5444:
GitHub user WilliamDo opened a pull request:
https://github.com/apache/ignite/pull/2217
IGNITE-5444 Fix serialization of SingletonList to binary format
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/WilliamDo/ignite IGNITE-5444
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2217.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 #2217
commit 2805fb89feedfe5c66e61161f4876a76b999e28b
Author: William Do
Date: 2017-06-29T11:45:38Z
IGNITE-5444 Fix serialization of SingletonList to binary format
> Collections.singletonList is not properly serialized by binary marshaller
> -
>
> Key: IGNITE-5444
> URL: https://issues.apache.org/jira/browse/IGNITE-5444
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.0
>Reporter: Valentin Kulichenko
>Assignee: William Do
> Fix For: 2.1
>
> Attachments: BinaryObjectSingletonList.java
>
>
> Test attached. {{Collections.singletonList}} is apparently serialized by
> optimized marshaller, because when deserialized, it doesn't return collection
> of binary objects, but rather collection of deserialized objects.
> Most likely the reason for this is that {{Collections.singletonList}} is not
> recognized by {{BinaryUtils.knownCollection}} method.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5618) .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration
Pavel Tupitsyn created IGNITE-5618: -- Summary: .NET: Ignite fails with OOM on startup under x86 (32 bit) with default configuration Key: IGNITE-5618 URL: https://issues.apache.org/jira/browse/IGNITE-5618 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.0 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.1 Default MemoryPolicyConfiguration settings do not take process bitness into account. We can't use 80% of RAM under 32-bit mode. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5617) Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage
Alexey Kuznetsov created IGNITE-5617: Summary: Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage Key: IGNITE-5617 URL: https://issues.apache.org/jira/browse/IGNITE-5617 Project: Ignite Issue Type: Task Reporter: Alexey Kuznetsov As of new persistent storage donated to Ignite it make sense to migrate from MongoDB+NodeJS to use some Java-based Web Server + Ignite+PS. This will give fault tolerance Out Of The Box and minimize third-party dependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5617) Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage
[ https://issues.apache.org/jira/browse/IGNITE-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-5617: Assignee: Alexey Kuznetsov > Rework backend from MongoDB+NodeJS to Java + Ignite + Persistent storage > > > Key: IGNITE-5617 > URL: https://issues.apache.org/jira/browse/IGNITE-5617 > Project: Ignite > Issue Type: Task >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > > As of new persistent storage donated to Ignite it make sense to > migrate from MongoDB+NodeJS to use some Java-based Web Server + Ignite+PS. > This will give fault tolerance Out Of The Box and minimize third-party > dependencies. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5533) CREATE INDEX failed if table has been re-created
[
https://issues.apache.org/jira/browse/IGNITE-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko reassigned IGNITE-5533:
---
Assignee: Sergi Vladykin (was: Semen Boikov)
> CREATE INDEX failed if table has been re-created
>
>
> Key: IGNITE-5533
> URL: https://issues.apache.org/jira/browse/IGNITE-5533
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Sergey Kozlov
>Assignee: Sergi Vladykin
>Priority: Critical
> Fix For: 2.1
>
>
> The brief scenario:
> create table t1 - ok
> insert t1 - ok
> create index t1 - ok
> drop table t1 - ok
> create table t1 - ok
> insert t1 - ok
> create index t1 - fail
> {noformat}
> [21:13:46,190][SEVERE][sql-connector-#239%null%][JdbcRequestHandler] Failed
> to execute SQL query [reqId=25, req=JdbcQueryExecuteRequest [schemaName=nu
> ll, pageSize=1024, maxRows=0, sqlQry=create index on "PUBLIC".t1 (b desc),
> args=[]]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Schema
> change operation failed: Failed to execute SQL statement on internal H2 d
> atabase: CREATE INDEX "t1_b_desc_idx" ON "PUBLIC"."T1" ("B" DESC, "_KEY" ASC)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:277)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:221)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1331)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1856)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1852)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1860)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:188)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:122)
> at
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:152)
> at
> org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:44)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> {code:title=repoducer.java|borderStyle=solid}
> Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1");
> Statement stmt = conn.createStatement();
> for (int i=0; i < 2; i++) {
> String t = Integer.toString(1);
> print(t);
> stmt.execute("drop table if exists \"PUBLIC\".t" + t);
> stmt.execute("create table \"PUBLIC\".t" + t + " (a int
> primary key, b varchar(30))");
> for (int j=1; j < 10; j++) {
> String s = Integer.toString(j);
> stmt.execute("insert into \"PUBLIC\".t" + t + " (a,b)
> values (" + s + ", '" + s + "')");
> }
> stmt.execute("create index on \"PUBLIC\".t" + t + " (b
> desc)");
> stmt.execute("drop table \"PUBLIC\".t" + t);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-4365) Data grid in deadlock on stop
[ https://issues.apache.org/jira/browse/IGNITE-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Menshikov reassigned IGNITE-4365: --- Assignee: Alexander Menshikov > Data grid in deadlock on stop > - > > Key: IGNITE-4365 > URL: https://issues.apache.org/jira/browse/IGNITE-4365 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Yakov Zhdanov >Assignee: Alexander Menshikov > Labels: busylock, gateway, performance > Attachments: thread-dump.txt > > > Attached is the threaddump describing the problem. > # several public threads wait for new cache topology version > # onExchangeFinish() tries to stop the gateway, but cannot do it due to > public threads waiting inside the GW. > # grid stopping thread waits for job requests to complete -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5202) Default mem policy name is not changed after setting defaultMemoryPolicyName property
[
https://issues.apache.org/jira/browse/IGNITE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006438#comment-16006438
]
Sergey Chugunov edited comment on IGNITE-5202 at 6/29/17 9:57 AM:
--
I lowered priority of the bug to Minor because it turned out that there were
some flaws in cache configuration logging causing incorrect messages to appear
in logs.
MemoryPolicy functionality is fine and works as expected.
was (Author: sergey-chugunov):
I lowered priority of the bug to Minor because it turned out that there were
some flaws in cache configuration logging caused incorrect messages to appear
in logs.
MemoryPolicy functionality is fine and works as expected.
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property
> -
>
> Key: IGNITE-5202
> URL: https://issues.apache.org/jira/browse/IGNITE-5202
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ksenia Rybakova
>Assignee: Sergey Chugunov
>Priority: Minor
> Fix For: 2.1
>
>
> Default mem policy name is not changed after setting defaultMemoryPolicyName
> property.
> Config:
> {noformat}
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
>
> class="org.apache.ignite.configuration.IgniteConfiguration"
> parent="base-ignite.cfg">
>
>
>
> ...
>
>
>
>parent="base-mem.cfg">
>
>
>
>
>
>
> {noformat}
> {noformat}
>
> http://www.springframework.org/schema/beans";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd";>
> class="org.apache.ignite.configuration.IgniteConfiguration" abstract="true">
> ...
>
> class="org.apache.ignite.configuration.MemoryConfiguration" abstract="true">
>...
>
>
>...
> class="org.apache.ignite.configuration.MemoryPolicyConfiguration">
>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>...
>
> {noformat}
> According to this config default memory policy should be "default2", but it
> remains "default" (while SystemCacheInitialSize was changed successfully to
> 50Mb as it's set in config).
> {noformat}
> [12:48:12,226][INFO ][main][IgniteKernal] System cache's MemoryPolicy size is
> configured to 50 MB. Use MemoryConfiguration.systemCacheMemorySize property
> to change the setting.
> [12:48:12,226][INFO ][main][IgniteKernal] Configured caches [in 'default'
> memoryPolicy: ['ignite-sys-cache', 'ignite-atomics-sys-cache', 'atomic-part',
> 'atomic-rplc', 'atomic-part-fat-values', 'atomic-part-onheap-evict-fifo',
> 'atomic-rplc-onheap-evict-lru', 'tx-part', 'tx-rplc', 'tx-part-fat-values',
> 'compute', 'tx-part-onheap-evict-lru', 'tx-rplc-onheap-evict-fifo',
> 'atomic-index', 'query', 'orgCache']]
> {noformat}
> Also it would be nice to have default policy name instead of "null" in logs
> when printing caches info:
> {noformat}
> <12:48:12> Cache configured with the following parameters:
> CacheConfiguration [name=atomic-part, memPlcName=null,
> storeConcurrentLoadAllThreshold=5, ...
> {noformat}
> {noformat}
> [12:48:13,239][INFO ][main][GridCacheProcessor] Started cache
> [name=atomic-part, memoryPolicyName=null, mode=PARTITIONED]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5521) Large near caches lead to cluster instability with metrics enabled
[ https://issues.apache.org/jira/browse/IGNITE-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068090#comment-16068090 ] Mikhail Cherkasov commented on IGNITE-5521: --- changeset: https://github.com/apache/ignite/commit/f6cbba3f50668bc5dedd5b3e4b3a98ab94956492 > Large near caches lead to cluster instability with metrics enabled > -- > > Key: IGNITE-5521 > URL: https://issues.apache.org/jira/browse/IGNITE-5521 > Project: Ignite > Issue Type: Bug > Components: cache, general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Mikhail Cherkasov >Priority: Critical > Labels: important > Fix For: 2.1 > > > We have two issues in the way cache metrics are working: > 1) Near cache size is calculated using full iteration over the near entries. > Perhaps, this is done because of near entries may be invalidated by a primary > node change, however, we should give a less strict metric rather than O(N) > cache size time > 2) Cache metrics are copied in discovery worker threads. This looks a bit > risky because an error like the one described before may stall the whole > cluster. We need to make sure that when the heartbeat message is processed, > we already have a metrics snapshot enabled -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners
[
https://issues.apache.org/jira/browse/IGNITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5615:
---
Description:
Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows
catching all events right from the node start.
* Can we unsubscribe from these events later? Does Java support this?
* What about GetEvents for a cluster group, how do we handle local listeners in
this case?
was:Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This
allows catching all events right from the node start.
> .NET: IgniteConfiguration.LocalEventListeners
> -
>
> Key: IGNITE-5615
> URL: https://issues.apache.org/jira/browse/IGNITE-5615
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows
> catching all events right from the node start.
> * Can we unsubscribe from these events later? Does Java support this?
> * What about GetEvents for a cluster group, how do we handle local listeners
> in this case?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5521) Large near caches lead to cluster instability with metrics enabled
[ https://issues.apache.org/jira/browse/IGNITE-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068060#comment-16068060 ] ASF GitHub Bot commented on IGNITE-5521: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2201 > Large near caches lead to cluster instability with metrics enabled > -- > > Key: IGNITE-5521 > URL: https://issues.apache.org/jira/browse/IGNITE-5521 > Project: Ignite > Issue Type: Bug > Components: cache, general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Mikhail Cherkasov >Priority: Critical > Labels: important > Fix For: 2.1 > > > We have two issues in the way cache metrics are working: > 1) Near cache size is calculated using full iteration over the near entries. > Perhaps, this is done because of near entries may be invalidated by a primary > node change, however, we should give a less strict metric rather than O(N) > cache size time > 2) Cache metrics are copied in discovery worker threads. This looks a bit > risky because an error like the one described before may stall the whole > cluster. We need to make sure that when the heartbeat message is processed, > we already have a metrics snapshot enabled -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-5613:
-
Description:
Consider the following update scenario:
{code}
Thread 1:
Transaction tx = txStart() {
get(key); // Acquires lock;
seq.incrementAndGet();
}
Thread 2:
seq.incrementAndGet();
{code}
Let's now assume that:
* Sequence is exhausted and needs a non-local update
* Thread 1 acquired lock on topology version N
* Topology version changes
* Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
which waits for topology version N+1 to become available
* Thread 1 attemts to incrementAndGet().
Since the lock is already held, thread 2 waits for the concurrent update to
complete
was:
Consider the following update scenario:
{code}
Thread 1:
Transaction tx = txStart() {
get(key); // Acquires lock;
seq.incrementAndGet();
}
Thread 2:
seq.incrementAndGet();
{code}
Let's now assume that:
* Sequence is exhausted and needs a non-local update
* Thread 1 acquired lock on topology version N
* Topology version changes
* Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
which waits for topology version N+1 to become available
* Thread 1 attemts to incrementAndGet().
Since the lock is already held, it waits for the concurrent update to complete
> AtomicSequence usage inside transactions may cause deadlock
> ---
>
> Key: IGNITE-5613
> URL: https://issues.apache.org/jira/browse/IGNITE-5613
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
> Labels: important
> Fix For: 2.1
>
>
> Consider the following update scenario:
> {code}
> Thread 1:
> Transaction tx = txStart() {
> get(key); // Acquires lock;
> seq.incrementAndGet();
> }
> Thread 2:
> seq.incrementAndGet();
> {code}
> Let's now assume that:
> * Sequence is exhausted and needs a non-local update
> * Thread 1 acquired lock on topology version N
> * Topology version changes
> * Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
> which waits for topology version N+1 to become available
> * Thread 1 attemts to incrementAndGet().
> Since the lock is already held, thread 2 waits for the concurrent update to
> complete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL for cluster configuration (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Description:
https://apacheignite-mix.readme.io/docs/amazon-aws
It would be nice if it would be possible to change/overwrite the Amazon S3 URL
for the cluster configuration to support an on premise S3 storage like Minio
[https://www.minio.io/].
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
was:
https://apacheignite-mix.readme.io/docs/amazon-aws
It would be nice if it would be possible to change the Amazon S3 URL for the
cluster configuration to support an on premise S3 storage like Minio
[https://www.minio.io/].
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
> Add ability to change Amazon S3 URL for cluster configuration (=support for
> on premise Minio)
> -
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> https://apacheignite-mix.readme.io/docs/amazon-aws
> It would be nice if it would be possible to change/overwrite the Amazon S3
> URL for the cluster configuration to support an on premise S3 storage like
> Minio [https://www.minio.io/].
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {code:xml}
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5535) BLAS support for offheap vector/matrix
[ https://issues.apache.org/jira/browse/IGNITE-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068040#comment-16068040 ] Yury Babak commented on IGNITE-5535: [~oignatenko], you don't need do anything with CacheUtils for this task, because it's a local-case optimization. > BLAS support for offheap vector/matrix > -- > > Key: IGNITE-5535 > URL: https://issues.apache.org/jira/browse/IGNITE-5535 > Project: Ignite > Issue Type: Task > Components: ml >Reporter: Yury Babak >Assignee: Oleg Ignatenko > > We want to add BLAS support for offheap stuctures. Current we implement only > onheap version. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL for cluster configuration (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Description:
https://apacheignite-mix.readme.io/docs/amazon-aws
It would be nice if it would be possible to change the Amazon S3 URL for the
cluster configuration to support an on premise S3 storage like Minio
[https://www.minio.io/].
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
was:
https://apacheignite-mix.readme.io/docs/amazon-aws
It would be nice if it would be possible to change the Amazon S3 URL for the
cluster configuration to support an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
> Add ability to change Amazon S3 URL for cluster configuration (=support for
> on premise Minio)
> -
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> https://apacheignite-mix.readme.io/docs/amazon-aws
> It would be nice if it would be possible to change the Amazon S3 URL for the
> cluster configuration to support an on premise S3 storage like Minio
> [https://www.minio.io/].
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {code:xml}
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL for cluster configuration (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Description:
It would be nice if it would be possible to change the Amazon S3 URL for the
cluster configuration to support an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
was:
It would be nice if it would be possible to change the Amazon S3 URL to support
an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
> Add ability to change Amazon S3 URL for cluster configuration (=support for
> on premise Minio)
> -
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> It would be nice if it would be possible to change the Amazon S3 URL for the
> cluster configuration to support an on premise S3 storage like Minio.
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {code:xml}
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL for cluster configuration (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Description:
https://apacheignite-mix.readme.io/docs/amazon-aws
It would be nice if it would be possible to change the Amazon S3 URL for the
cluster configuration to support an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
was:
It would be nice if it would be possible to change the Amazon S3 URL for the
cluster configuration to support an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
> Add ability to change Amazon S3 URL for cluster configuration (=support for
> on premise Minio)
> -
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> https://apacheignite-mix.readme.io/docs/amazon-aws
> It would be nice if it would be possible to change the Amazon S3 URL for the
> cluster configuration to support an on premise S3 storage like Minio.
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {code:xml}
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL for cluster configuration (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Summary: Add ability to change Amazon S3 URL for cluster configuration
(=support for on premise Minio) (was: Add ability to change Amazon S3 URL
(=support for on premise Minio))
> Add ability to change Amazon S3 URL for cluster configuration (=support for
> on premise Minio)
> -
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> It would be nice if it would be possible to change the Amazon S3 URL to
> support an on premise S3 storage like Minio.
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {code:xml}
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Description:
It would be nice if it would be possible to change the Amazon S3 URL to support
an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
{code}
was:
It would be nice if it would be possible to change the Amazon S3 URL to support
an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
**
{code}
> Add ability to change Amazon S3 URL (=support for on premise Minio)
> ---
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> It would be nice if it would be possible to change the Amazon S3 URL to
> support an on premise S3 storage like Minio.
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {code:xml}
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Description:
It would be nice if it would be possible to change the Amazon S3 URL to support
an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{code:xml}
**
{code}
was:
It would be nice if it would be possible to change the Amazon S3 URL to support
an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{{
**
}}
> Add ability to change Amazon S3 URL (=support for on premise Minio)
> ---
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> It would be nice if it would be possible to change the Amazon S3 URL to
> support an on premise S3 storage like Minio.
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {code:xml}
> class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
> **
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL (=support for on premise Minio)
[
https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Rausch updated IGNITE-5616:
Description:
It would be nice if it would be possible to change the Amazon S3 URL to support
an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
{{
**
}}
was:
It would be nice if it would be possible to change the Amazon S3 URL to support
an on premise S3 storage like Minio.
For now there is no easy ability to do that via the XML configuration because
as we saw fixed S3 URL's in the apache ignite code...
For example something like that:
**
> Add ability to change Amazon S3 URL (=support for on premise Minio)
> ---
>
> Key: IGNITE-5616
> URL: https://issues.apache.org/jira/browse/IGNITE-5616
> Project: Ignite
> Issue Type: Improvement
> Components: aws
>Affects Versions: 2.0
>Reporter: Bernhard Rausch
>
> It would be nice if it would be possible to change the Amazon S3 URL to
> support an on premise S3 storage like Minio.
> For now there is no easy ability to do that via the XML configuration because
> as we saw fixed S3 URL's in the apache ignite code...
> For example something like that:
> {{ class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder">
>
>
> **
> }}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5616) Add ability to change Amazon S3 URL (=support for on premise Minio)
[ https://issues.apache.org/jira/browse/IGNITE-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Rausch updated IGNITE-5616: Description: It would be nice if it would be possible to change the Amazon S3 URL to support an on premise S3 storage like Minio. For now there is no easy ability to do that via the XML configuration because as we saw fixed S3 URL's in the apache ignite code... For example something like that: ** was: It would be nice if it would be possible to change the Amazon S3 URL to support an on premise S3 storage like Minio. For now there is no easy ability to do that via the XML configuration because as we saw fixed S3 URL's in the apache ignite code... For example something like that: > Add ability to change Amazon S3 URL (=support for on premise Minio) > --- > > Key: IGNITE-5616 > URL: https://issues.apache.org/jira/browse/IGNITE-5616 > Project: Ignite > Issue Type: Improvement > Components: aws >Affects Versions: 2.0 >Reporter: Bernhard Rausch > > It would be nice if it would be possible to change the Amazon S3 URL to > support an on premise S3 storage like Minio. > For now there is no easy ability to do that via the XML configuration because > as we saw fixed S3 URL's in the apache ignite code... > For example something like that: > class="org.apache.ignite.spi.discovery.tcp.ipfinder.s3.TcpDiscoveryS3IpFinder"> > > > ** > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-5613:
-
Description:
Consider the following update scenario:
{code}
Thread 1:
Transaction tx = txStart() {
get(key); // Acquires lock;
seq.incrementAndGet();
}
Thread 2:
seq.incrementAndGet();
{code}
Let's now assume that:
* Sequence is exhausted and needs a non-local update
* Thread 1 acquired lock on topology version N
* Topology version changes
* Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
which waits for topology version N+1 to become available
* Thread 1 attemts to incrementAndGet().
Since the lock is already held, it waits for the concurrent update to complete
was:
Consider the following update scenario:
{code}
Thread 1:
Transaction tx = txStart() {
get(key); // Acquires lock;
seq.incrementAndGet();
}
Thread 2:
seq.incrementAndGet();
{code}
Let's now assume that:
* Sequence is exhausted and needs a non-local update
* Thread 1 acquired lock on topology version N
* Topology version changes
* Thread 2 now calls incrementAndGet(), updates the sequence local guard and
starts transaction which waits for topology version N+1 to become available
* Thread 1 attemts to incrementAndGet().
Since guard is already changed, it waits for the concurrent update to complete
> AtomicSequence usage inside transactions may cause deadlock
> ---
>
> Key: IGNITE-5613
> URL: https://issues.apache.org/jira/browse/IGNITE-5613
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
> Labels: important
> Fix For: 2.1
>
>
> Consider the following update scenario:
> {code}
> Thread 1:
> Transaction tx = txStart() {
> get(key); // Acquires lock;
> seq.incrementAndGet();
> }
> Thread 2:
> seq.incrementAndGet();
> {code}
> Let's now assume that:
> * Sequence is exhausted and needs a non-local update
> * Thread 1 acquired lock on topology version N
> * Topology version changes
> * Thread 2 now calls incrementAndGet(), acquires lock and starts transaction
> which waits for topology version N+1 to become available
> * Thread 1 attemts to incrementAndGet().
> Since the lock is already held, it waits for the concurrent update to complete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-5553: Description: h2. Notes When IgniteSet is restored from persistence, size of set is always 0, [link to test history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails]. h2. Detailed description Unlike *IgniteQueue* which uses separate cache key to store its size *IgniteSet* stores it in a field of some class. Test from the link above shows very clearly that after restoring memory state from PDS all set values are restored correctly but size is lost. h2. Proposed solution One possible solution might be to do the same thing as *IgniteQueue* does: size of *IgniteSet* must be stored is cache instead of volatile in-memory fields of random classes. was: h2. Notes When IgniteSet is restored from persistence, size of set is always 0, [link to test history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails] h2. Detailed description Unlike *IgniteQueue* which uses separate cache key to store its size *IgniteSet* stores it in a field of some class. Test from the link above shows very clearly that after restoring memory state from PDS all set values are restored correctly but size is lost. h2. Proposed solution One possible solution might be to do the same thing as *IgniteQueue* does: size of *IgniteSet* must be stored is cache instead of volatile in-memory fields of random classes. > Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error > - > > Key: IGNITE-5553 > URL: https://issues.apache.org/jira/browse/IGNITE-5553 > Project: Ignite > Issue Type: Bug > Components: data structures, persistence >Affects Versions: 2.1 >Reporter: Dmitriy Pavlov >Priority: Critical > Labels: test-fail > Fix For: 2.2 > > > h2. Notes > When IgniteSet is restored from persistence, size of set is always 0, [link > to test > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails]. > h2. Detailed description > Unlike *IgniteQueue* which uses separate cache key to store its size > *IgniteSet* stores it in a field of some class. > Test from the link above shows very clearly that after restoring memory state > from PDS all set values are restored correctly but size is lost. > h2. Proposed solution > One possible solution might be to do the same thing as *IgniteQueue* does: > size of *IgniteSet* must be stored is cache instead of volatile in-memory > fields of random classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-5553: Description: h2. Notes When IgniteSet is restored from persistence, size of set is always 0, [link to test history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails] h2. Detailed description Unlike *IgniteQueue* which uses separate cache key to store its size *IgniteSet* stores it in a field of some class. Test from the link above shows very clearly that after restoring memory state from PDS all set values are restored correctly but size is lost. h2. Proposed solution One possible solution might be to do the same thing as *IgniteQueue* does: size of *IgniteSet* must be stored is cache instead of volatile in-memory fields of random classes. was: h2. Notes When IgniteSet is restored from persistence, size of set is always 0, [link to test history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails] h2. Detailed description Unlike *IgniteQueue* which uses separate cache key to store its size *IgniteSet* stores it in a field of some class. Test from link shows very clearly that after restoring memory state from PDS all set values are restored correctly but size is lost. h2. Proposed solution One possible solution might be to do the same thing as *IgniteQueue* does: size of *IgniteSet* must be stored is cache instead of volatile in-memory fields of random classes. > Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error > - > > Key: IGNITE-5553 > URL: https://issues.apache.org/jira/browse/IGNITE-5553 > Project: Ignite > Issue Type: Bug > Components: data structures, persistence >Affects Versions: 2.1 >Reporter: Dmitriy Pavlov >Priority: Critical > Labels: test-fail > Fix For: 2.2 > > > h2. Notes > When IgniteSet is restored from persistence, size of set is always 0, [link > to test > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails] > h2. Detailed description > Unlike *IgniteQueue* which uses separate cache key to store its size > *IgniteSet* stores it in a field of some class. > Test from the link above shows very clearly that after restoring memory state > from PDS all set values are restored correctly but size is lost. > h2. Proposed solution > One possible solution might be to do the same thing as *IgniteQueue* does: > size of *IgniteSet* must be stored is cache instead of volatile in-memory > fields of random classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[
https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-5553:
Affects Version/s: 2.1
Priority: Critical (was: Major)
Fix Version/s: 2.2
Description:
h2. Notes
When IgniteSet is restored from persistence, size of set is always 0, [link to
test
history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails]
h2. Detailed description
Unlike *IgniteQueue* which uses separate cache key to store its size
*IgniteSet* stores it in a field of some class.
Test from link shows very clearly that after restoring memory state from PDS
all set values are restored correctly but size is lost.
h2. Proposed solution
One possible solution might be to do the same thing as *IgniteQueue* does: size
of *IgniteSet* must be stored is cache instead of volatile in-memory fields of
random classes.
was:
When IgniteSet is restored from persistence, size of set is always 0.
http://ci.ignite.apache.org/viewLog.html?buildId=675215&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgnitePds2#testNameId-7043871603266099589
Reproducable locally (stable)
{noformat}
junit.framework.AssertionFailedError:
Expected :100
Actual :0
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at junit.framework.TestCase.assertEquals(TestCase.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.IgnitePersistentStoreDataStructuresTest.testSet(IgnitePersistentStoreDataStructuresTest.java:195)
{noformat}
Component/s: persistence
data structures
Issue Type: Bug (was: Test)
> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
> Issue Type: Bug
> Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: test-fail
> Fix For: 2.2
>
>
> h2. Notes
> When IgniteSet is restored from persistence, size of set is always 0, [link
> to test
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-7043871603266099589&tab=testDetails]
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size
> *IgniteSet* stores it in a field of some class.
> Test from link shows very clearly that after restoring memory state from PDS
> all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does:
> size of *IgniteSet* must be stored is cache instead of volatile in-memory
> fields of random classes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5616) Add ability to change Amazon S3 URL (=support for on premise Minio)
Bernhard Rausch created IGNITE-5616: --- Summary: Add ability to change Amazon S3 URL (=support for on premise Minio) Key: IGNITE-5616 URL: https://issues.apache.org/jira/browse/IGNITE-5616 Project: Ignite Issue Type: Improvement Components: aws Affects Versions: 2.0 Reporter: Bernhard Rausch It would be nice if it would be possible to change the Amazon S3 URL to support an on premise S3 storage like Minio. For now there is no easy ability to do that via the XML configuration because as we saw fixed S3 URL's in the apache ignite code... For example something like that: -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5615) .NET: IgniteConfiguration.LocalEventListeners
Pavel Tupitsyn created IGNITE-5615:
--
Summary: .NET: IgniteConfiguration.LocalEventListeners
Key: IGNITE-5615
URL: https://issues.apache.org/jira/browse/IGNITE-5615
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.1
Propagate {{IgniteConfiguration.LocalEventListeners}} to .NET. This allows
catching all events right from the node start.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5614) .NET: IDataStreamer.AddData should take IEnumerable
Pavel Tupitsyn created IGNITE-5614:
--
Summary: .NET: IDataStreamer.AddData should take IEnumerable
Key: IGNITE-5614
URL: https://issues.apache.org/jira/browse/IGNITE-5614
Project: Ignite
Issue Type: Improvement
Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Fix For: 2.2
There is {{IDataStreamer.AddData(ICollection> entries)}},
which is not consistent with other APIs like
{{ICache.PutAll(IEnumerable> vals)}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5614) .NET: IDataStreamer.AddData should take IEnumerable
[
https://issues.apache.org/jira/browse/IGNITE-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5614:
---
Description:
There is {{IDataStreamer.AddData(ICollection> entries)}},
which is not consistent with other APIs like
{{ICache.PutAll(IEnumerable> vals)}}.
{{IEnumerable}} is more user-friendly, avoids huge collection allocation, etc.
was:There is {{IDataStreamer.AddData(ICollection>
entries)}}, which is not consistent with other APIs like
{{ICache.PutAll(IEnumerable> vals)}}.
> .NET: IDataStreamer.AddData should take IEnumerable
> ---
>
> Key: IGNITE-5614
> URL: https://issues.apache.org/jira/browse/IGNITE-5614
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.2
>
>
> There is {{IDataStreamer.AddData(ICollection>
> entries)}}, which is not consistent with other APIs like
> {{ICache.PutAll(IEnumerable> vals)}}.
> {{IEnumerable}} is more user-friendly, avoids huge collection allocation, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
Alexey Goncharuk created IGNITE-5613:
Summary: AtomicSequence usage inside transactions may cause
deadlock
Key: IGNITE-5613
URL: https://issues.apache.org/jira/browse/IGNITE-5613
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.5.0.final
Reporter: Alexey Goncharuk
Fix For: 2.1
Consider the following update scenario:
{code}
Thread 1:
Transaction tx = txStart() {
get(key); // Acquires lock;
seq.incrementAndGet();
}
Thread 2:
seq.incrementAndGet();
{code}
Let's now assume that:
* Sequence is exhausted and needs a non-local update
* Thread 1 acquired lock on topology version N
* Topology version changes
* Thread 2 now calls incrementAndGet(), updates the sequence local guard and
starts transaction which waits for topology version N+1 to become available
* Thread 1 attemts to incrementAndGet().
Since guard is already changed, it waits for the concurrent update to complete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5613) AtomicSequence usage inside transactions may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-5613:
-
Labels: important (was: )
> AtomicSequence usage inside transactions may cause deadlock
> ---
>
> Key: IGNITE-5613
> URL: https://issues.apache.org/jira/browse/IGNITE-5613
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
> Labels: important
> Fix For: 2.1
>
>
> Consider the following update scenario:
> {code}
> Thread 1:
> Transaction tx = txStart() {
> get(key); // Acquires lock;
> seq.incrementAndGet();
> }
> Thread 2:
> seq.incrementAndGet();
> {code}
> Let's now assume that:
> * Sequence is exhausted and needs a non-local update
> * Thread 1 acquired lock on topology version N
> * Topology version changes
> * Thread 2 now calls incrementAndGet(), updates the sequence local guard and
> starts transaction which waits for topology version N+1 to become available
> * Thread 1 attemts to incrementAndGet().
> Since guard is already changed, it waits for the concurrent update to complete
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
