[jira] [Assigned] (IGNITE-9368) Web console: Double confirmation of unsaved changes.
[ https://issues.apache.org/jira/browse/IGNITE-9368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9368: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good to me. Merged to master. > Web console: Double confirmation of unsaved changes. > > > Key: IGNITE-9368 > URL: https://issues.apache.org/jira/browse/IGNITE-9368 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.7 > > > On move from any configuration page to Queries page configuration dialog > about unsaved changes is shown 2 times. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9368) Web console: Double confirmation of unsaved changes.
[ https://issues.apache.org/jira/browse/IGNITE-9368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9368: - Ignite Flags: (was: Docs Required) > Web console: Double confirmation of unsaved changes. > > > Key: IGNITE-9368 > URL: https://issues.apache.org/jira/browse/IGNITE-9368 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > On move from any configuration page to Queries page configuration dialog > about unsaved changes is shown 2 times. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9368) Web console: Double confirmation of unsaved changes.
[ https://issues.apache.org/jira/browse/IGNITE-9368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9368: - Fix Version/s: 2.7 > Web console: Double confirmation of unsaved changes. > > > Key: IGNITE-9368 > URL: https://issues.apache.org/jira/browse/IGNITE-9368 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > On move from any configuration page to Queries page configuration dialog > about unsaved changes is shown 2 times. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9286) Redesign and Refactor UI
[ https://issues.apache.org/jira/browse/IGNITE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-9286. > Redesign and Refactor UI > > > Key: IGNITE-9286 > URL: https://issues.apache.org/jira/browse/IGNITE-9286 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Dmitriy Shabalin >Assignee: Alexey Kuznetsov >Priority: Major > Labels: web-console-configuration > Fix For: 2.7 > > Time Spent: 3h 35m > Remaining Estimate: 0h > > We should refactor all screens to use latest modern controls as on > "Configuration" screen. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9339) Web console: form-field-size improvements
[
https://issues.apache.org/jira/browse/IGNITE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-9339:
Assignee: Alexander Kalinin (was: Dmitriy Shabalin)
> Web console: form-field-size improvements
> -
>
> Key: IGNITE-9339
> URL: https://issues.apache.org/jira/browse/IGNITE-9339
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexander Kalinin
>Priority: Minor
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> I think there some changes due for {{form-field-size}} component:
> 1. [~pkonstantinov] expressed his confusion multiple times about the fact
> that {{form-field-size}} converts visible value when user changes scale. He
> suggests to keep the view value the same and only scale the model value.
> 2. It wasn't the case at the moment {{form-field-size}} was added, but now
> some form fields use different default scale (i.e. it's bytes vs megabytes).
> [~Dmitriyff] introduced redundant "time" scale in IGNITE-9286, surely we can
> figure out a better component API for cases like this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621248#comment-16621248 ] ASF GitHub Bot commented on IGNITE-9646: GitHub user slukyano opened a pull request: https://github.com/apache/ignite/pull/4793 IGNITE-9646: Added jackson dependencies back to ignite-aws. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9646 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4793.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 #4793 commit 23e6d55c3993c2510513a0feb7a4e9516a749ea3 Author: Stanislav Lukyanov Date: 2018-09-19T21:53:34Z IGNITE-9646: Added jackson dependencies back to ignite-aws. > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov reassigned IGNITE-9646: -- Assignee: Stanislav Lukyanov > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9651) Binary objects comparison may fail when the same reference occurs more than once
[
https://issues.apache.org/jira/browse/IGNITE-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-9651:
---
Description:
If a composite object contains multiple occurrences of the same POJO that POJO
will be properly serialized only the first time, and all other references will
refer to that first object. Because of that the same object may have different
views in binary format when serialized on its own and when serialized as a part
of another object.
Having multiple binary views of the same object leads to several issues with
binary objects comparison. Examples in pseudocode are below, JUnit tests are
attached
Example 1 (RepeatingFieldTest.java)
{code}
class Key { int i, Pojo pojo1, Pojo pojo2 }
class Pojo { int i }
cache.put(new Key(42, new Pojo(42), new Pojo(42)), 42);
// new Pojo is created for both fields - works
assertEquals(INT, cache.get(new Key(42, new Pojo(42), new Pojo(42;
// same Pojo is used for both fields - fails
// this is because the second field is serialized as a reference to the first
one, and binary representation differs
Pojo obj = new Pojo(42);
assertEquals(42, cache.get(new Key(42, obj, obj)));
{code}
Example 2 (RepeatingFieldSqlTest.java)
{code}
class Pojo { int i }
class Key { int i, Pojo pojo }
class Value { Pojo pojo, Key key }
Pojo obj = new Pojo(42);
Key key = new Key(42, obj);
Value val = new Value(key, obj);
cache.put(key, val);
// supposed to return 1 row, but returns 0
SqlFieldsQuery qry = new SqlFieldsQuery("select * from Value where _key = key");
{code}
was:
If a composite object contains multiple occurrences of the same POJO that POJO
will be properly serialized only the first time, and all other references will
refer to that first object. Because of that the same object may have different
views in binary format when serialized on its own and when serialized as a part
of another object.
Having multiple binary views of the same object leads to several issues with
binary objects comparison. Examples in pseudocode are below, JUnit tests are
attached
Example 1 (RepeatingFieldTest.java)
{code}
class Key { int i, Pojo pojo1, Pojo pojo2 }
class Pojo { int i }
cache.put(new Key(42, new Pojo(42), new Pojo(42)), 42);
// new Pojo is created for both fields - works
assertEquals(INT, cache.get(new Key(42, new Pojo(42), new Pojo(42;
// same Pojo is used for both fields - fails
// this is because the second field is serialized as a reference to the first
one, and binary representation differs
Pojo obj = new Pojo(42);
assertEquals(42, cache.get(new Key(42, obj, obj)));
{code}
Example 2 (RepeatingFieldSqlTest.java)
{code}
class Pojo { int i }
class Key { int i, Pojo pojo }
class Value { Pojo pojo, Key key }
Pojo obj = new Pojo(INT);
Key key = new Key(INT, obj);
Value val = new Value(key, obj);
cache.put(key, val);
// supposed to return 1 row, but returns 0
SqlFieldsQuery qry = new SqlFieldsQuery("select * from Value where _key = key");
{code}
> Binary objects comparison may fail when the same reference occurs more than
> once
>
>
> Key: IGNITE-9651
> URL: https://issues.apache.org/jira/browse/IGNITE-9651
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Stanislav Lukyanov
>Priority: Major
> Attachments: RepeatingFieldSqlTest.java, RepeatingFieldTest.java
>
>
> If a composite object contains multiple occurrences of the same POJO that
> POJO will be properly serialized only the first time, and all other
> references will refer to that first object. Because of that the same object
> may have different views in binary format when serialized on its own and when
> serialized as a part of another object.
> Having multiple binary views of the same object leads to several issues with
> binary objects comparison. Examples in pseudocode are below, JUnit tests are
> attached
>
> Example 1 (RepeatingFieldTest.java)
> {code}
> class Key { int i, Pojo pojo1, Pojo pojo2 }
> class Pojo { int i }
> cache.put(new Key(42, new Pojo(42), new Pojo(42)), 42);
> // new Pojo is created for both fields - works
> assertEquals(INT, cache.get(new Key(42, new Pojo(42), new Pojo(42;
> // same Pojo is used for both fields - fails
> // this is because the second field is serialized as a reference to the first
> one, and binary representation differs
> Pojo obj = new Pojo(42);
> assertEquals(42, cache.get(new Key(42, obj, obj)));
> {code}
>
> Example 2 (RepeatingFieldSqlTest.java)
> {code}
> class Pojo { int i }
> class Key { int i, Pojo pojo }
> class Value { Pojo pojo, Key key }
> Pojo obj = new Pojo(42);
> Key key =
[jira] [Updated] (IGNITE-9651) Binary objects comparison may fail when the same reference occurs more than once
[
https://issues.apache.org/jira/browse/IGNITE-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-9651:
---
Description:
If a composite object contains multiple occurrences of the same POJO that POJO
will be properly serialized only the first time, and all other references will
refer to that first object. Because of that the same object may have different
views in binary format when serialized on its own and when serialized as a part
of another object.
Having multiple binary views of the same object leads to several issues with
binary objects comparison. Examples in pseudocode are below, JUnit tests are
attached
Example 1 (RepeatingFieldTest.java)
{code}
class Key { int i, Pojo pojo1, Pojo pojo2 }
class Pojo { int i }
cache.put(new Key(42, new Pojo(42), new Pojo(42)), 42);
// new Pojo is created for both fields - works
assertEquals(INT, cache.get(new Key(42, new Pojo(42), new Pojo(42;
// same Pojo is used for both fields - fails
// this is because the second field is serialized as a reference to the first
one, and binary representation differs
Pojo obj = new Pojo(42);
assertEquals(42, cache.get(new Key(42, obj, obj)));
{code}
Example 2 (RepeatingFieldSqlTest.java)
{code}
class Pojo { int i }
class Key { int i, Pojo pojo }
class Value { Pojo pojo, Key key }
Pojo obj = new Pojo(INT);
Key key = new Key(INT, obj);
Value val = new Value(key, obj);
cache.put(key, val);
// supposed to return 1 row, but returns 0
SqlFieldsQuery qry = new SqlFieldsQuery("select * from Value where _key = key");
{code}
was:
If a composite object contains multiple occurrences of the same POJO that POJO
will be properly serialized only the first time, and all other references will
refer to that first object. Because of that the same object may have different
views in binary format when serialized on its own and when serialized as a part
of another object.
Having multiple binary views of the same object leads to several issues with
binary objects comparison. Examples in pseudocode are below, JUnit tests are
attached
Example 1 (RepeatingFieldTest.java)
{code}
class Key { int i, Pojo pojo1, Pojo pojo2 }
class Pojo { int i }
cache.put(new Key(42, new Pojo(42), new Pojo(42)), 42);
// new Pojo is created for both fields - works
assertEquals(INT, cache.get(new Key(42, new Pojo(42), new Pojo(42;
// same Pojo is used for both fields - fails
// this is because the second field is serialized as a reference to the first
one, and binary representation differs
Pojo obj = new Pojo(42);
assertEquals(42, cache.get(new Key(42, obj, obj)));
{code}
Example 2 (RepeatingFieldSqlTest.java)
{code}
class Pojo { int i }
class Key { int i, Pojo pojo }
class Value { Pojo pojo, Key key }
Pojo obj = new Pojo(INT);
Key key = new Key(INT, obj);
Value val = new Value(key, obj);
cache.put(key, val);
// supposed to return 1 row, but returns 0
SqlFieldsQuery qry = new SqlFieldsQuery("select * from Value where _key = key");
{code}
> Binary objects comparison may fail when the same reference occurs more than
> once
>
>
> Key: IGNITE-9651
> URL: https://issues.apache.org/jira/browse/IGNITE-9651
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Stanislav Lukyanov
>Priority: Major
> Attachments: RepeatingFieldSqlTest.java, RepeatingFieldTest.java
>
>
> If a composite object contains multiple occurrences of the same POJO that
> POJO will be properly serialized only the first time, and all other
> references will refer to that first object. Because of that the same object
> may have different views in binary format when serialized on its own and when
> serialized as a part of another object.
> Having multiple binary views of the same object leads to several issues with
> binary objects comparison. Examples in pseudocode are below, JUnit tests are
> attached
>
> Example 1 (RepeatingFieldTest.java)
> {code}
> class Key { int i, Pojo pojo1, Pojo pojo2 }
> class Pojo { int i }
> cache.put(new Key(42, new Pojo(42), new Pojo(42)), 42);
> // new Pojo is created for both fields - works
> assertEquals(INT, cache.get(new Key(42, new Pojo(42), new Pojo(42;
> // same Pojo is used for both fields - fails
> // this is because the second field is serialized as a reference to the first
> one, and binary representation differs
> Pojo obj = new Pojo(42);
> assertEquals(42, cache.get(new Key(42, obj, obj)));
> {code}
>
> Example 2 (RepeatingFieldSqlTest.java)
> {code}
> class Pojo { int i }
> class Key { int i, Pojo pojo }
> class Value { Pojo pojo, Key key }
> Pojo obj = new Pojo(INT);
> Key key
[jira] [Created] (IGNITE-9651) Binary objects comparison may fail when the same reference occurs more than once
Stanislav Lukyanov created IGNITE-9651:
--
Summary: Binary objects comparison may fail when the same
reference occurs more than once
Key: IGNITE-9651
URL: https://issues.apache.org/jira/browse/IGNITE-9651
Project: Ignite
Issue Type: Bug
Components: binary
Reporter: Stanislav Lukyanov
Attachments: RepeatingFieldSqlTest.java, RepeatingFieldTest.java
If a composite object contains multiple occurrences of the same POJO that POJO
will be properly serialized only the first time, and all other references will
refer to that first object. Because of that the same object may have different
views in binary format when serialized on its own and when serialized as a part
of another object.
Having multiple binary views of the same object leads to several issues with
binary objects comparison. Examples in pseudocode are below, JUnit tests are
attached
Example 1 (RepeatingFieldTest.java)
{code}
class Key { int i, Pojo pojo1, Pojo pojo2 }
class Pojo { int i }
cache.put(new Key(42, new Pojo(42), new Pojo(42)), 42);
// new Pojo is created for both fields - works
assertEquals(INT, cache.get(new Key(42, new Pojo(42), new Pojo(42;
// same Pojo is used for both fields - fails
// this is because the second field is serialized as a reference to the first
one, and binary representation differs
Pojo obj = new Pojo(42);
assertEquals(42, cache.get(new Key(42, obj, obj)));
{code}
Example 2 (RepeatingFieldSqlTest.java)
{code}
class Pojo { int i }
class Key { int i, Pojo pojo }
class Value { Pojo pojo, Key key }
Pojo obj = new Pojo(INT);
Key key = new Key(INT, obj);
Value val = new Value(key, obj);
cache.put(key, val);
// supposed to return 1 row, but returns 0
SqlFieldsQuery qry = new SqlFieldsQuery("select * from Value where _key = key");
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620967#comment-16620967 ] Maxim Muzafarov commented on IGNITE-7196: - [~DmitriyGovorukhin] I've added TC link for the latest test results. Also, I've also answered to your comments in Upsouce. We can continue the discussion here or there, as you like. > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode
[jira] [Updated] (IGNITE-9519) Composite types should be inlined in index tree
[ https://issues.apache.org/jira/browse/IGNITE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-9519: --- Summary: Composite types should be inlined in index tree (was: PK as complex type should can be keep at inline index) > Composite types should be inlined in index tree > --- > > Key: IGNITE-9519 > URL: https://issues.apache.org/jira/browse/IGNITE-9519 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.6 >Reporter: Yury Gerzhedovich >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.7 > > > Currently in case PK is complex type it can not be keep at inline index. > This is critical performance issue due to for any put or get operation it > cant' be fully comparable and require read full object from the heap or even > disk storage. > To mitigate the problem we need add ability keep complex type (java object) > at inline indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9650) java.math.BigDecimal / .Net decimal columns shown as OTHER in JDBC Thin metadata
Ilya Kasnacheev created IGNITE-9650: --- Summary: java.math.BigDecimal / .Net decimal columns shown as OTHER in JDBC Thin metadata Key: IGNITE-9650 URL: https://issues.apache.org/jira/browse/IGNITE-9650 Project: Ignite Issue Type: Bug Components: jdbc Affects Versions: 2.6 Reporter: Ilya Kasnacheev Attachments: Screenshot_20180919_200457.png Subj. According to our docs it should be DECIMAL: https://apacheignite-sql.readme.io/docs/data-types#section-decimal DECIMAL Possible values: Data type with fixed precision and scale. Mapped to: Java/JDBC: java.math.BigDecimal .NET/C#: decimal C/C++: ignite::Decimal ODBC: SQL_DECIMAL But it turns to be mapped to OTHER (see screenshot) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620820#comment-16620820
]
Andrey Kuznetsov commented on IGNITE-8570:
--
After discussion at Upsource and subsequent minor changes, I'm OK with the PR.
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8855) Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is significantly smaller than number of clients
[ https://issues.apache.org/jira/browse/IGNITE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620796#comment-16620796 ] ASF GitHub Bot commented on IGNITE-8855: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4739 > Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is > significantly smaller than number of clients > > > Key: IGNITE-8855 > URL: https://issues.apache.org/jira/browse/IGNITE-8855 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > After fixing client nodes hangs in IGNITE-8657 another issue was found out: > when EXCHANGE_HISTORY is significantly smaller than number of clients they > interfere with each other on initial exchange and make reconnect attempts > over and over again. > To avoid this random delay (maybe exponential) should be added for clients > before making new reconnect attempt. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8855) Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is significantly smaller than number of clients
[ https://issues.apache.org/jira/browse/IGNITE-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620785#comment-16620785 ] Dmitriy Govorukhin commented on IGNITE-8855: [~ibessonov] Your changes are merged, thanks for the contribution! > Client nodes make a lot of attempts to join topology if EXCHANGE_HISTORY is > significantly smaller than number of clients > > > Key: IGNITE-8855 > URL: https://issues.apache.org/jira/browse/IGNITE-8855 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.7 > > > After fixing client nodes hangs in IGNITE-8657 another issue was found out: > when EXCHANGE_HISTORY is significantly smaller than number of clients they > interfere with each other on initial exchange and make reconnect attempts > over and over again. > To avoid this random delay (maybe exponential) should be added for clients > before making new reconnect attempt. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9582) Document Model Updating
[ https://issues.apache.org/jira/browse/IGNITE-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-9582: --- Assignee: Aleksey Zinoviev (was: Alexey Platonov) > Document Model Updating > --- > > Key: IGNITE-9582 > URL: https://issues.apache.org/jira/browse/IGNITE-9582 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9582) Document Model Updating
[ https://issues.apache.org/jira/browse/IGNITE-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620777#comment-16620777 ] Alexey Platonov commented on IGNITE-9582: - [https://docs.google.com/document/d/1xJMenCjYNV8EgqosPzcRDC9g1sZ9xIKEKopSnLAdBz0/edit?usp=sharing] > Document Model Updating > --- > > Key: IGNITE-9582 > URL: https://issues.apache.org/jira/browse/IGNITE-9582 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Alexey Platonov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks
[ https://issues.apache.org/jira/browse/IGNITE-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov updated IGNITE-6445: - Fix Version/s: (was: 2.7) 2.8 > IgniteTxManager.txLocksInfo method misses locks > --- > > Key: IGNITE-6445 > URL: https://issues.apache.org/jira/browse/IGNITE-6445 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Fix For: 2.8 > > > In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) > misses locks. > For example: > # In case of a configuration with near cache, entries are created for the > near cache and for the ordinal cache. For each entry, their own MVCC > candidates are created. > # For non-custom objects of type (Integer, etc.), the entry stored in > "GridNearTxLocal" is not associated with MVCC candidates with which the same > entity is associated in another format stored in "GridDhtTxLocal" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6224) Node stoping does not wait all transactions completion
[
https://issues.apache.org/jira/browse/IGNITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Biryukov updated IGNITE-6224:
-
Fix Version/s: (was: 2.7)
2.8
> Node stoping does not wait all transactions completion
> --
>
> Key: IGNITE-6224
> URL: https://issues.apache.org/jira/browse/IGNITE-6224
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Fix For: 2.8
>
> Attachments: TransactionBehindStopNodeTest.java
>
>
> I have started grid node and executing transaction over some cache. After I
> stopped the node in the middle execution of transaction. I got transaction
> execution exception:
> {noformat}
> java.lang.IllegalStateException: class
> org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
> perform cache operation (cache is stopped): cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:164)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1656)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:869)
> at
> org.apache.ignite.TransactionBehindStopNodeTest.testOneNode(TransactionBehindStopNodeTest.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> although I stopped node with _false_ {{cancel}} flag.
> {code}
> G.stop(getTestIgniteInstanceName(0), false);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9138) ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup fails.
[
https://issues.apache.org/jira/browse/IGNITE-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Biryukov updated IGNITE-9138:
-
Fix Version/s: (was: 2.7)
2.8
> ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup fails.
> ---
>
> Key: IGNITE-9138
> URL: https://issues.apache.org/jira/browse/IGNITE-9138
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
>
> {noformat}
> junit.framework.AssertionFailedError: Expected: but was:
> ZkCommunicationErrorProcessFuture
> [impl=org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl@180b3819,
> endTime=1532545453881, id=9e083d2d461-645a2360-f5bb-43d3-8327-83d0a4a00124,
> state=WAIT_TIMEOUT, resolveTopVer=0, resErr=null, collectResFut=null]
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.checkInternalStructuresCleanup(ZookeeperDiscoverySpiTest.java:517)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.afterTest(ZookeeperDiscoverySpiTest.java:476)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620763#comment-16620763 ] Dmitriy Govorukhin commented on IGNITE-7196: [~Mmuzaf] Also, please add a link to TC run in links block, same place as for PR link. > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], >
[jira] [Resolved] (IGNITE-9243) Avoid test suit hangs on stopAllGrids
[ https://issues.apache.org/jira/browse/IGNITE-9243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Biryukov resolved IGNITE-9243. -- Resolution: Won't Fix My idea did not work. > Avoid test suit hangs on stopAllGrids > - > > Key: IGNITE-9243 > URL: https://issues.apache.org/jira/browse/IGNITE-9243 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > Tests sometimes hang on node join to topology, and this leads to the hang of > the whole suite. > Solution: Do not wait for nodes to join a topology in *stopAllGrids* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Comment Edited] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620760#comment-16620760 ] Dmitriy Govorukhin edited comment on IGNITE-7196 at 9/19/18 3:39 PM: - [~Mmuzaf] Thanks for your work, I left my comments in UpSource review. was (Author: dmitriygovorukhin): [~Mmuzaf] Thanks for your work, I leave my comments in UpSource review. > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent >
[jira] [Commented] (IGNITE-7196) Exchange can stuck and wait while new node restoring state from disk and starting caches
[ https://issues.apache.org/jira/browse/IGNITE-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620760#comment-16620760 ] Dmitriy Govorukhin commented on IGNITE-7196: [~Mmuzaf] Thanks for your work, I leave my comments in UpSource review. > Exchange can stuck and wait while new node restoring state from disk and > starting caches > > > Key: IGNITE-7196 > URL: https://issues.apache.org/jira/browse/IGNITE-7196 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Fix For: 2.7 > > > Exchange can stuck and wait while new node restoring state from disk and > starting caches, there's a log snippet from a just joined new node that shows > the issue: > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=57, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=3ac1160e-0de4-41bc-a366-59292c9f03c1, > customEvt=null, allowMerge=true] > [21:36:13,023][INFO][exchange-worker-#62%statement_grid%][FilePageStoreManager] > Resolved page store work directory: > /mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log work directory: > /mnt/wal/WAL/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,024][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Resolved write ahead log archive directory: > /mnt/wal/WAL_archive/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463 > [21:36:13,046][INFO][exchange-worker-#62%statement_grid%][FileWriteAheadLogManager] > Started write-ahead log manager [mode=DEFAULT] > [21:36:13,065][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=100.0 MiB, pages=6352, tableSize=373.4 > KiB, checkpointBuffer=100.0 MiB] > [21:36:13,105][INFO][exchange-worker-#62%statement_grid%][PageMemoryImpl] > Started page memory [memoryAllocated=32.0 GiB, pages=2083376, tableSize=119.6 > MiB, checkpointBuffer=896.0 MiB] > [21:36:13,428][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Read checkpoint status > [startMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930965253-306c0895-1f5f-4237-bebf-8bf2b49682af-START.bin, > > endMarker=/mnt/store/node00-d1eb270c-d2cc-4550-87aa-64f6df2a9463/cp/1512930869357-1c24b6dc-d64c-4b83-8166-11edf1bfdad3-END.bin] > [21:36:13,429][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Checking memory state [lastValidPos=FileWALPointer [idx=3582, > fileOffset=59186076, len=9229, forceFlush=false], lastMarked=FileWALPointer > [idx=3629, fileOffset=50829700, len=9229, forceFlush=false], > lastCheckpointId=306c0895-1f5f-4237-bebf-8bf2b49682af] > [21:36:13,429][WARNING][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Ignite node stopped in the middle of checkpoint. Will restore memory state > and finish checkpoint on node start. > [21:36:18,312][INFO][grid-nio-worker-tcp-comm-0-#41%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.17.115:57148] > [21:36:21,619][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Found last checkpoint marker [cpId=306c0895-1f5f-4237-bebf-8bf2b49682af, > pos=FileWALPointer [idx=3629, fileOffset=50829700, len=9229, > forceFlush=false]] > [21:36:21,620][INFO][exchange-worker-#62%statement_grid%][GridCacheDatabaseSharedManager] > Finished applying memory changes [changesApplied=165103, time=8189ms] > [21:36:22,403][INFO][grid-nio-worker-tcp-comm-1-#42%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.28.10:47964] > [21:36:23,414][INFO][grid-nio-worker-tcp-comm-2-#43%statement_grid%][TcpCommunicationSpi] > Accepted incoming communication connection [locAddr=/172.31.20.209:48100, > rmtAddr=/172.31.27.101:46000] > [21:36:33,019][WARNING][main][GridCachePartitionExchangeManager] Failed to > wait for initial partition map exchange. Possible reasons are: > ^-- Transactions in deadlock. > ^-- Long running transactions (ignore if this is the case). > ^-- Unreleased explicit locks. > [21:36:53,021][WARNING][main][GridCachePartitionExchangeManager] Still > waiting for initial partition map exchange > [fut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent > [evtNode=TcpDiscoveryNode [id=3ac1160e-0de4-41bc-a366-59292c9f03c1, > addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.31.20.209], >
[jira] [Comment Edited] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620740#comment-16620740 ] Artem Budnikov edited comment on IGNITE-7728 at 9/19/18 3:20 PM: - [~dmagda] I added a compute example and moved the page: [https://apacheignite-sql.readme.io/v2.6/docs/getting-started-1] For the compute example to work, the cluster's deployment mode must be set to PRIVATE. I added a note about this on the page, but I think the source code in GitHub should be updated as well. Also, asked the guys to provide C++ and .Net snippets. Will add them when they are available. was (Author: artem budnikov): [~dmagda] I added a compute example and moved the page: [https://apacheignite-sql.readme.io/v2.6/docs/getting-started-1] For the compute example to work, the cluster's deployment mode must be set to PRIVATE. I added a note about this on the page, but I think the source code in GitHub should be updated as well. > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-7728: -- Assignee: Denis Magda (was: Artem Budnikov) > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620740#comment-16620740 ] Artem Budnikov commented on IGNITE-7728: [~dmagda] I added a compute example and moved the page: [https://apacheignite-sql.readme.io/v2.6/docs/getting-started-1] For the compute example to work, the cluster's deployment mode must be set to PRIVATE. I added a note about this on the page, but I think the source code in GitHub should be updated as well. > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620739#comment-16620739 ] Pavel Kuznetsov commented on IGNITE-9637: - About 2) Batched insert and putAll benchmarks have "batchSize" parameter Sql and native streamer benchmarks have : "BATCH_SIZE", "ALLOW_OVERWRITE", "PER_NODE_PARALLEL_OPERATIONS", "PER_NODE_BUFFER_SIZE", "ORDERED" parameters [~vozerov] could you please take a look at configuration file modules/yardstick/config/upload/benchmark-upload-regular.properties ? > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6044) SQL insert waits for transaction commit, but it must be executed right away
[ https://issues.apache.org/jira/browse/IGNITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620737#comment-16620737 ] Yury Gerzhedovich commented on IGNITE-6044: --- Hi [~vozerov], Thanks for the review and good point to fix. Fix has been done and tet result looks good. test results: [https://ci.ignite.apache.org/viewLog.html?buildId=1906467=queuedBuildOverviewTab] > SQL insert waits for transaction commit, but it must be executed right away > --- > > Key: IGNITE-6044 > URL: https://issues.apache.org/jira/browse/IGNITE-6044 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Yury Gerzhedovich >Priority: Critical > Labels: sql-stability, usability > Fix For: 2.7 > > > Doc says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away."" > https://apacheignite.readme.io/docs/dml#section-transactional-support > However the data will be added to cache only after transaction commit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-9637: Description: We want to have benchmark suite that measures how long it takes to upload data to server. There is existing benchmark code in org.apache.ignite.yardstick.upload package 1) Improve data model: - Add indexes to data model. Number of indexes should be configurable. - Add missing benchmark that performs putAll 2) Define parameters to use in benchmarks was: We want to measure data load with indexes. We already have table with several fileds. We need benchmark parameter that handles number of indexes. > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to have benchmark suite that measures how long it takes to upload > data to server. > There is existing benchmark code in org.apache.ignite.yardstick.upload > package > 1) Improve data model: > - Add indexes to data model. Number of indexes should be configurable. > - Add missing benchmark that performs putAll > 2) Define parameters to use in benchmarks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9478) SQL: throw reducer retry error
[
https://issues.apache.org/jira/browse/IGNITE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620729#comment-16620729
]
Sergey Grimstad commented on IGNITE-9478:
-
branched out of IGNITE-6195
> SQL: throw reducer retry error
> --
>
> Key: IGNITE-9478
> URL: https://issues.apache.org/jira/browse/IGNITE-9478
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.7
>
>
> Currently we cannot pass correct error message from reducer retry condition
> to user exception. Need to fix that. See
> \{{GridReduceQueryExecutor.logRetry}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9637) SQL: Create suite for data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-9637: Summary: SQL: Create suite for data load benchmarks (was: SQL: Add indexes to data load benchmarks) > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to measure data load with indexes. > We already have table with several fileds. We need benchmark parameter that > handles number of indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8619) Remote node could not start in ssh connection
[
https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620697#comment-16620697
]
Oleg Ignatenko commented on IGNITE-8619:
Proposed changes to {{StartNodeCallableImpl}} look right to me; besides usual
run at Teamcity I also checked them in a customised stress test at my machine
and results were satisfying. Changes made in tests look somewhat troublesome
though - I made some suggestions on that in Upsource. I also would want to see
note from Ilya Lantukh at Upsource resolved (the one where he suggests to add
comment in the source code explaining the regex value passed in parameter).
After my concerns regarding test are resolved, recommend to merge into master.
[~NSAmelchev] - pinging you about this as promised, please feel free to contact
me if needed.
> Remote node could not start in ssh connection
> -
>
> Key: IGNITE-8619
> URL: https://issues.apache.org/jira/browse/IGNITE-8619
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Now there is a problem with launch remote node via ssh. Initially was an
> assumption that it's due to remote process has not enough time to write
> information into log:
> [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this
> correction didn't fix [TeamCity
> |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]
> (IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls).
> So it's necessary to make launch remote node via ssh always succesful.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9649) Rework logging in important places
Pavel Kovalenko created IGNITE-9649: --- Summary: Rework logging in important places Key: IGNITE-9649 URL: https://issues.apache.org/jira/browse/IGNITE-9649 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.0 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.8 Currently, we have insufficient, incomplete or too sufficient logs at DEBUG and TRACE levels. We should revisit and rework logging in important places of product: 1) Partitions Map Exchange 2) Rebalance 3) Partitions workflow 4) Time logging for critical places -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9648) Improve doc and javadoc for Ignite distrubuted lock
Dmitriy Pavlov created IGNITE-9648: -- Summary: Improve doc and javadoc for Ignite distrubuted lock Key: IGNITE-9648 URL: https://issues.apache.org/jira/browse/IGNITE-9648 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Make more clear statement how distributed locks relate to entry lock. Is it the same key for entry and for the acquired lock(K key); Is it possible to acquire the lock for unexistent entry? https://apacheignite.readme.io/docs/distributed-locks org.apache.ignite.IgniteCache#lock -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results
[ https://issues.apache.org/jira/browse/IGNITE-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620609#comment-16620609 ] Maxim Pudov commented on IGNITE-8545: - I run team city again [https://ci.ignite.apache.org/viewLog.html?buildId=1870597]. All mentioned test except one passed. The test which failed is flaky and has to do with my changes. As dead code was removed as [~amashenkov] asked, I think the PR is ready to be merged. > If queryParallelism in nodes' caches configurations differ, query may hang, > assert or return incomplete results > --- > > Key: IGNITE-8545 > URL: https://issues.apache.org/jira/browse/IGNITE-8545 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Maxim Pudov >Priority: Critical > Fix For: 2.7 > > Attachments: IgniteSqlSplitterQueryParallelismTest.java > > > I imagine it should not. See the attached file. > It happens both with client nodes and with server nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results
[ https://issues.apache.org/jira/browse/IGNITE-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620609#comment-16620609 ] Maxim Pudov edited comment on IGNITE-8545 at 9/19/18 1:50 PM: -- I run team city again [https://ci.ignite.apache.org/viewLog.html?buildId=1870597]. All mentioned test except one passed. The test which failed is flaky and has nothing to do with my changes. As dead code was removed as [~amashenkov] asked, I think the PR is ready to be merged. was (Author: maxim.pudov): I run team city again [https://ci.ignite.apache.org/viewLog.html?buildId=1870597]. All mentioned test except one passed. The test which failed is flaky and has to do with my changes. As dead code was removed as [~amashenkov] asked, I think the PR is ready to be merged. > If queryParallelism in nodes' caches configurations differ, query may hang, > assert or return incomplete results > --- > > Key: IGNITE-8545 > URL: https://issues.apache.org/jira/browse/IGNITE-8545 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Assignee: Maxim Pudov >Priority: Critical > Fix For: 2.7 > > Attachments: IgniteSqlSplitterQueryParallelismTest.java > > > I imagine it should not. See the attached file. > It happens both with client nodes and with server nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Commented] (IGNITE-9616) SQL: Introduce H2 factory for holder of aggregate result
[
https://issues.apache.org/jira/browse/IGNITE-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620601#comment-16620601
]
Taras Ledkov commented on IGNITE-9616:
--
[~vozerov], the [draft of the
patch|https://github.com/h2database/h2database/pull/1458] is provided to review
by H2 commiters.
> SQL: Introduce H2 factory for holder of aggregate result
>
>
> Key: IGNITE-9616
> URL: https://issues.apache.org/jira/browse/IGNITE-9616
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> H2 collects aggregate results at the simple HashMap (groups set and values
> set).
> This causes an OOME error on large groups set and large group size with
> {{DISTINCT}}.
> We have to introduce way to use our own implementation of the aggregate
> result's container.
> H2 issue:
> [#1433|https://github.com/h2database/h2database/issues/1433#issuecomment-421045128]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
***UNCHECKED*** [jira] [Commented] (IGNITE-9637) SQL: Add indexes to data load benchmarks
[ https://issues.apache.org/jira/browse/IGNITE-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620587#comment-16620587 ] Pavel Kuznetsov commented on IGNITE-9637: - I've added indexes into the data model. Added missed benchmark for putAll. Now I need code review. [~vozerov] Could you please take a look at branch ignite-9637 and check that indexes are OK. > SQL: Add indexes to data load benchmarks > > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We want to measure data load with indexes. > We already have table with several fileds. We need benchmark parameter that > handles number of indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9645) [TC Bot] Add comparison of failed tests lists in two date intervals
[ https://issues.apache.org/jira/browse/IGNITE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PetrovMikhail updated IGNITE-9645: -- Summary: [TC Bot] Add comparison of failed tests lists in two date intervals (was: Add comparison of failed tests lists in two date intervals) > [TC Bot] Add comparison of failed tests lists in two date intervals > --- > > Key: IGNITE-9645 > URL: https://issues.apache.org/jira/browse/IGNITE-9645 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > > Based on [IGNITE-9541|https://issues.apache.org/jira/browse/IGNITE-9541] It's > needed to add comparison of failed tests lists in two date intervals -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9579) Document Random Forest
[ https://issues.apache.org/jira/browse/IGNITE-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-9579: --- Assignee: Aleksey Zinoviev (was: Alexey Platonov) > Document Random Forest > -- > > Key: IGNITE-9579 > URL: https://issues.apache.org/jira/browse/IGNITE-9579 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9579) Document Random Forest
[ https://issues.apache.org/jira/browse/IGNITE-9579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620579#comment-16620579 ] Alexey Platonov commented on IGNITE-9579: - [https://docs.google.com/document/d/1ZLdZrQvIl2d_oMJIoc0fKMAmr1PKSv-r-vAmQdXY4ao/edit?usp=sharing] > Document Random Forest > -- > > Key: IGNITE-9579 > URL: https://issues.apache.org/jira/browse/IGNITE-9579 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8485) TDE - Phase-1
[
https://issues.apache.org/jira/browse/IGNITE-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620535#comment-16620535
]
Nikolay Izhikov edited comment on IGNITE-8485 at 9/19/18 12:53 PM:
---
[~vozerov]
> 5) GridEncryptionManager - checks for notCoordinator() looks strange to me. I
> do not see any cases where current coordinator should do anything else than
> other nodes.
Yes, you are right in case of {{collectGridNodeData}}. Redundant check removed.
> 4) GridEncryptionManager.onKernalStart0 - I cannot understand why we are
> listening to ctx.discovery().localJoinFuture().listen here. Could you please
> clarify?
This is required to handle the case with statically configured caches:
1. Statically configured caches are registered *before* node joins to the
cluster.
2. At the moment of such registration, we can't generate and store an
encryption keys, because keys would be different on every node.
3. If node create new cluster({{locaJoinFuture}} && {{notCoordinator==false}})
we can generate and store encryption keys.
4. Second and subsequent nodes will receive newly generated keys from
coordinator on join.
I added comments to this piece of code. Hope this makes it more clear to any
other readers.
was (Author: nizhikov):
[~vozerov]
> 5) GridEncryptionManager - checks for notCoordinator() looks strange to me. I
> do not see any cases where current coordinator should do anything else than
> other nodes.
Yes, you are right in case of {{collectGridNodeData}}. Redundant check removed.
> 4) GridEncryptionManager.onKernalStart0 - I cannot understand why we are
> listening to ctx.discovery().localJoinFuture().listen here. Could you please
> clarify?
This is required to handle the case with statically configured caches:
1. Statically configured caches are registered *before* node joins to the
cluster.
2. At the moment of such registration, we can't generate and store an
encryption keys, because keys would be different on every node.
3. If node create new cluster({{locaJoinFuture}} && {{notCoordinator==false}})
we can generate and store encryption keys.
4. Second and subsequent nodes will receive newly generated keys from
coordinator on join.
> TDE - Phase-1
> -
>
> Key: IGNITE-8485
> URL: https://issues.apache.org/jira/browse/IGNITE-8485
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Critical
> Fix For: 2.7
>
>
> Basic support for a Transparent Data Encryption should be implemented:
> 1. Usage of standard JKS, Java Security.
> 2. Persistent Data Encryption/Decryption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8485) TDE - Phase-1
[
https://issues.apache.org/jira/browse/IGNITE-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620535#comment-16620535
]
Nikolay Izhikov commented on IGNITE-8485:
-
[~vozerov]
> 5) GridEncryptionManager - checks for notCoordinator() looks strange to me. I
> do not see any cases where current coordinator should do anything else than
> other nodes.
Yes, you are right in case of {{collectGridNodeData}}. Redundant check removed.
> 4) GridEncryptionManager.onKernalStart0 - I cannot understand why we are
> listening to ctx.discovery().localJoinFuture().listen here. Could you please
> clarify?
This is required to handle the case with statically configured caches:
1. Statically configured caches are registered *before* node joins to the
cluster.
2. At the moment of such registration, we can't generate and store an
encryption keys, because keys would be different on every node.
3. If node create new cluster({{locaJoinFuture}} && {{notCoordinator==false}})
we can generate and store encryption keys.
4. Second and subsequent nodes will receive newly generated keys from
coordinator on join.
> TDE - Phase-1
> -
>
> Key: IGNITE-8485
> URL: https://issues.apache.org/jira/browse/IGNITE-8485
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Critical
> Fix For: 2.7
>
>
> Basic support for a Transparent Data Encryption should be implemented:
> 1. Usage of standard JKS, Java Security.
> 2. Persistent Data Encryption/Decryption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9519) PK as complex type should can be keep at inline index
[ https://issues.apache.org/jira/browse/IGNITE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620534#comment-16620534 ] Stanislav Lukyanov commented on IGNITE-9519: The problem was that we have multiple of representing equal binary objects - detached (binary object in its own array) and non-detached (object in a parent array with a `start` field indicating where the object starts. To fix that I've added call to `BinaryObjectImpl::detach` to have the objects in a "canonical" way. TC: https://ci.ignite.apache.org/viewLog.html?buildId=1901198=buildResultsDiv=IgniteTests24Java8_RunAll [~vozerov], please review (third time's a charm!). > PK as complex type should can be keep at inline index > - > > Key: IGNITE-9519 > URL: https://issues.apache.org/jira/browse/IGNITE-9519 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.6 >Reporter: Yury Gerzhedovich >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.7 > > > Currently in case PK is complex type it can not be keep at inline index. > This is critical performance issue due to for any put or get operation it > cant' be fully comparable and require read full object from the heap or even > disk storage. > To mitigate the problem we need add ability keep complex type (java object) > at inline indexes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9616) SQL: Introduce H2 factory for holder of aggregate result
[
https://issues.apache.org/jira/browse/IGNITE-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reassigned IGNITE-9616:
Assignee: Taras Ledkov
> SQL: Introduce H2 factory for holder of aggregate result
>
>
> Key: IGNITE-9616
> URL: https://issues.apache.org/jira/browse/IGNITE-9616
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> H2 collects aggregate results at the simple HashMap (groups set and values
> set).
> This causes an OOME error on large groups set and large group size with
> {{DISTINCT}}.
> We have to introduce way to use our own implementation of the aggregate
> result's container.
> H2 issue:
> [#1433|https://github.com/h2database/h2database/issues/1433#issuecomment-421045128]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8913) Uninformative SQL query cancellation message
[
https://issues.apache.org/jira/browse/IGNITE-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620522#comment-16620522
]
Sergey Grimstad commented on IGNITE-8913:
-
fixed according to review
> Uninformative SQL query cancellation message
>
>
> Key: IGNITE-8913
> URL: https://issues.apache.org/jira/browse/IGNITE-8913
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.5
>Reporter: Vladislav Pyatkov
>Assignee: Sergey Grimstad
>Priority: Major
> Labels: sql-stability
> Fix For: 2.7
>
> Attachments: sgrimstad_IGNITE_8913_Query_cancelled_me.patch
>
>
> When query timeouted or cancelled or other exception, we getting message:
> "The query was cancelled while executing".
> Need make message more clear - text of query, node which the cancelled,
> reason of cancel query e.t.c.
> {noformat}
> 2018-06-19
> 00:00:10.653[ERROR][query-#93192%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to execute local query.
> org.apache.ignite.cache.query.QueryCancelledException: The query was
> cancelled while executing.
> at
> org.apache.ignite.internal.processors.query.GridQueryCancel.set(GridQueryCancel.java:53)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1115)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1185)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:683)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:527)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:218)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor$2.onMessage(GridMapQueryExecutor.java:178)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2333)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> 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)
> 2018-06-19
> 00:00:11.629[ERROR][query-#93187%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to execute local query.
> org.apache.ignite.cache.query.QueryCancelledException: The query was
> cancelled while executing.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:670)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:527)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:218)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor$2.onMessage(GridMapQueryExecutor.java:178)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2333)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6173) SQL: do not start caches on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620515#comment-16620515
]
Yury Gerzhedovich commented on IGNITE-6173:
---
[~amashenkov], could you please review the PR again?
> SQL: do not start caches on client nodes
>
>
> Key: IGNITE-6173
> URL: https://issues.apache.org/jira/browse/IGNITE-6173
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: sql-stability
>
> When cache is started, this even is distributed through custom discovery
> message. Server nodes start the cache, client nodes do nothing until cache is
> requested explicitly. At the same time H2 database objects are created only
> when cache is really started.
> For this reason query parsing could lead to {{TABLE NOT FOUND}}, {{INDEX NOT
> FOUND}}, etc. errors. If such exception is observed, we force start of all
> known cache on a client and then retry. See
> {{GridCacheProcessor#createMissingQueryCaches}} method.
> First, client node cache start leads to another custom discovery message. So
> query performance may suffer. Second, this is not needed! We already have all
> necessary cache info in discovery.
> Let's try to find a way to use available discovery data and do not start
> cache on a client for SQL query execution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9647) EVT_CACHE_OBJECT_REMOVED is fired when entry is absent before remove
Ivan Pavlukhin created IGNITE-9647:
--
Summary: EVT_CACHE_OBJECT_REMOVED is fired when entry is absent
before remove
Key: IGNITE-9647
URL: https://issues.apache.org/jira/browse/IGNITE-9647
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Ivan Pavlukhin
Attachments: RemoveEventBugReproducer.java
Currently {{cache.remove(key)}} triggers {{EVT_CACHE_OBJECT_REMOVED}} event
regardless whether entry was in cache before remove or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9646: Assignee: (was: Alexey Kuznetsov) > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9365) Force backups to different AWS availability zones using only Spring XML
[ https://issues.apache.org/jira/browse/IGNITE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620072#comment-16620072 ] David Harvey edited comment on IGNITE-9365 at 9/19/18 11:54 AM: [~vkulichenko], the use case I thinking about is we have a working cluster, and a new node is added to the baseline, but it is missing the attribute. If the affinityBackupFilter throws an exception, there is nothing to catch all the way back to GridDhtPartitionsExchangeFuture.processFullMessage(), and all nodes that tries to calculate() affinity will throw that exception. For this use case, we would want to validate that the node coming online has the proper attribute set, and not discover this problem on arbitrary nodes during a partition map exchange. I don't have a complete enough understanding to know where that validation should go. A more promising approach is to not allow a node with a null attribute to service _either_ the primary or backup. That is, if you configure a cache with an affinityBackupFilter, the set of nodes that can service that cache will be limited to nodes that will not throw an exception if the filter is given the node and a list of nodes only containing that node. I don't yet see how to handle the case where no nodes have the attribute, however. Also, I failed to mention there is precedent for the currently coded approach: If exclNeighbors==true, but there are only neighbors available, it will create the backup on the neighbor. If the node characteristic that distinguishes between groups does not exist, then as coded it simply places the node in its own group. The semantics of this, or your alternative of placing all such nodes in one group, are clear and easy to describe, even if the cause is likely a misconfiguration. If we go with your original proposal, then I can document a procedure where you can compare the total number of cache entries across all caches with SELECT COUNT(*)... to determine if the caches are properly backed up. was (Author: syssoftsol): [~vkulichenko], the use case I thinking about is we have a working cluster, and a new node is added to the baseline, but it is missing the attribute. If the affinityBackupFilter throws an exception, there is nothing to catch all the way back to GridDhtPartitionsExchangeFuture.processFullMessage(), and all nodes that tries to calculate() affinity will throw that exception. For this use case, we would want to validate that the node coming online has the proper attribute set, and not discover this on an arbitrary node. I don't have a complete enough understanding to know where that validation should go. A more promising approach is to not allow a node with a null attribute to service _either_ the primary or backup. That is, if you configure a cache with an affinityBackupFilter, the set of nodes that can service that cache will be limited to nodes that will not throw an exception if the filter is given the node and a list of nodes only containing that node. I don't yet see how to handle the case where no nodes have the attribute, however. > Force backups to different AWS availability zones using only Spring XML > --- > > Key: IGNITE-9365 > URL: https://issues.apache.org/jira/browse/IGNITE-9365 > Project: Ignite > Issue Type: Improvement > Components: cache > Environment: >Reporter: David Harvey >Assignee: David Harvey >Priority: Minor > Fix For: 2.7 > > Attachments: master_947962f785_availability_zones_via_spring.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > As a developer, I want to be able to force cache backups each to a different > "Availability Zone", when I'm running out-of-the-box Ignite, without > additional Jars installed. "Availability zone" is a AWS feature with > different names for the same function by other cloud providers. A single > availability zone has the characteristic that some or all of the EC2 > instances in that zone can fail together due to a single fault. You have no > control over the hosts on which the EC2 instance VMs run on in AWS, except by > controlling the availability zone . > > I could write a few lines of a custom affinityBackupFilter, and configure it > a RendezvousAffinityFunction, but then I have to get it deployed on all nodes > in the cluster, and peer class loading will not work to this. The code to > do this should just be part of Ignite. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9646: Priority: Blocker (was: Critical) > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Alexey Kuznetsov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9646: Fix Version/s: 2.7 > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Alexey Kuznetsov >Priority: Blocker > Fix For: 2.7 > > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9646) Regression in release build for ignite-aws module
[ https://issues.apache.org/jira/browse/IGNITE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9646: Fix Version/s: (was: 2.7) Description: In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & jackson-mapper-asl were removed and that leads to ClassNotFound errors at runtime if ignite node uses TcpDiscoveryS3IpFinder and started from binary build. We need to return that dependencies back, because Ignite binary build logic ignore transient dependencies. was: In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & jackson-mapper-asl were removed and that leads to ClassNotFound errors at runtime if ignite node uses TcpDiscoveryZookeeperIpFinder and started from binary build. We need to return that dependencies back, because Ignite binary build logic ignore transient dependencies. Component/s: (was: zookeeper) aws Summary: Regression in release build for ignite-aws module (was: CLONE - Regression in release build for ignite-zookeeper module) > Regression in release build for ignite-aws module > - > > Key: IGNITE-9646 > URL: https://issues.apache.org/jira/browse/IGNITE-9646 > Project: Ignite > Issue Type: Bug > Components: aws >Reporter: Ilya Kasnacheev >Assignee: Alexey Kuznetsov >Priority: Critical > > In IGNITE-9073 from pom.xml of ignite-aws jackson-core-asl & > jackson-mapper-asl > were removed and that leads to ClassNotFound errors at runtime if ignite node > uses TcpDiscoveryS3IpFinder and started from binary build. > We need to return that dependencies back, because Ignite binary build logic > ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9646) CLONE - Regression in release build for ignite-zookeeper module
Ilya Kasnacheev created IGNITE-9646: --- Summary: CLONE - Regression in release build for ignite-zookeeper module Key: IGNITE-9646 URL: https://issues.apache.org/jira/browse/IGNITE-9646 Project: Ignite Issue Type: Bug Components: zookeeper Reporter: Ilya Kasnacheev Assignee: Alexey Kuznetsov Fix For: 2.7 In IGNITE-9073 from pom.xml of ignite-zookeeper jackson-core-asl & jackson-mapper-asl were removed and that leads to ClassNotFound errors at runtime if ignite node uses TcpDiscoveryZookeeperIpFinder and started from binary build. We need to return that dependencies back, because Ignite binary build logic ignore transient dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9644) SQL: local DML query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Grimstad updated IGNITE-9644: Description: Related to IGNITE-7039. Need to expand for DML. Commented out test market as TODO: IGNITE-9644 (was: Related to IGNITE-7039. Need to expand for DML.) > SQL: local DML query should pin affected partitions > --- > > Key: IGNITE-9644 > URL: https://issues.apache.org/jira/browse/IGNITE-9644 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergey Grimstad >Priority: Major > Fix For: 2.7 > > > Related to IGNITE-7039. Need to expand for DML. Commented out test market as > TODO: IGNITE-9644 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7039) SQL: local query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620484#comment-16620484 ] Sergey Grimstad commented on IGNITE-7039: - 3. Ticket Created 1,2 - fixed > SQL: local query should pin affected partitions > --- > > Key: IGNITE-7039 > URL: https://issues.apache.org/jira/browse/IGNITE-7039 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Sergey Grimstad >Priority: Major > Labels: sql-stability > Fix For: 2.7 > > Attachments: 3194.patch > > > When distributed query is executed, we pin cache partitions for particular > topology version on map nodes [1]. However, it seems that we do no do that > for local queries. This is a bug because partition with required data could > be evicted from local node at any time, leading to incorrect results. > [1] > https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7039) SQL: local query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620484#comment-16620484 ] Sergey Grimstad edited comment on IGNITE-7039 at 9/19/18 11:44 AM: --- 3. Ticket Created IGNITE-9644 1,2 - fixed was (Author: sgrimstad): 3. Ticket Created 1,2 - fixed > SQL: local query should pin affected partitions > --- > > Key: IGNITE-7039 > URL: https://issues.apache.org/jira/browse/IGNITE-7039 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Sergey Grimstad >Priority: Major > Labels: sql-stability > Fix For: 2.7 > > Attachments: 3194.patch > > > When distributed query is executed, we pin cache partitions for particular > topology version on map nodes [1]. However, it seems that we do no do that > for local queries. This is a bug because partition with required data could > be evicted from local node at any time, leading to incorrect results. > [1] > https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9645) Add comparison of failed tests lists in two date intervals
[ https://issues.apache.org/jira/browse/IGNITE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PetrovMikhail updated IGNITE-9645: -- Description: Based on [IGNITE-9541|https://issues.apache.org/jira/browse/IGNITE-9541] It's needed to add comparison of failed tests lists in two date intervals (was: Based on https://issues.apache.org/jira/browse/IGNITE-9541. It's needed to add comparison of failed tests lists in two date intervals) > Add comparison of failed tests lists in two date intervals > -- > > Key: IGNITE-9645 > URL: https://issues.apache.org/jira/browse/IGNITE-9645 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > > Based on [IGNITE-9541|https://issues.apache.org/jira/browse/IGNITE-9541] It's > needed to add comparison of failed tests lists in two date intervals -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9645) Add comparison of failed tests lists in two date intervals
PetrovMikhail created IGNITE-9645: - Summary: Add comparison of failed tests lists in two date intervals Key: IGNITE-9645 URL: https://issues.apache.org/jira/browse/IGNITE-9645 Project: Ignite Issue Type: Task Reporter: PetrovMikhail Assignee: PetrovMikhail Based on https://issues.apache.org/jira/browse/IGNITE-9541. It's needed to add comparison of failed tests lists in two date intervals -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9644) SQL: local DML query should pin affected partitions
Sergey Grimstad created IGNITE-9644: --- Summary: SQL: local DML query should pin affected partitions Key: IGNITE-9644 URL: https://issues.apache.org/jira/browse/IGNITE-9644 Project: Ignite Issue Type: Bug Components: sql Reporter: Sergey Grimstad Fix For: 2.7 Related to IGNITE-7039. Need to expand for DML. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9419) Avoid saving cache configuration synchronously during PME
[ https://issues.apache.org/jira/browse/IGNITE-9419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620457#comment-16620457 ] Pavel Kovalenko commented on IGNITE-9419: - [~ilantukh] [~agoncharuk] Fix has reworked. Could you please look at the changes again? > Avoid saving cache configuration synchronously during PME > - > > Key: IGNITE-9419 > URL: https://issues.apache.org/jira/browse/IGNITE-9419 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.7 > > > Currently, we save cache configuration during PME at the activation phase > here > org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.CachesInfo#updateCachesInfo > . We should avoid this, as it performs operations to a disk. We should save > it asynchronously or lazy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9357) Spark Structured Streaming with Ignite as data source and sink
[ https://issues.apache.org/jira/browse/IGNITE-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620452#comment-16620452 ] Stephen Darlington commented on IGNITE-9357: I created a patch to this patch here: [https://github.com/sdarlington/ignite/commit/15df75bf60ab3cbd6f6936131d26be560a026d22] This is needed so that using an OffsetPolicy of 'timestamp' works correctly. > Spark Structured Streaming with Ignite as data source and sink > -- > > Key: IGNITE-9357 > URL: https://issues.apache.org/jira/browse/IGNITE-9357 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.7 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > > We are working on a PoC where we want to use Ignite as a data storage and > Spark as a computation engine. We found that Ignite is supported neither as a > source nor as a Sink when using Spark Structured Streaming, which is a must > for us. > We are enhancing Ignite to support Spark streaming with Ignite. We will send > docs and code for review for the Ignite Community to consider if the > community wants to accept this feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Assigned] (IGNITE-9574) Document Gradient boosting
[ https://issues.apache.org/jira/browse/IGNITE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-9574: --- Assignee: Aleksey Zinoviev (was: Alexey Platonov) > Document Gradient boosting > -- > > Key: IGNITE-9574 > URL: https://issues.apache.org/jira/browse/IGNITE-9574 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9574) Document Gradient boosting
[ https://issues.apache.org/jira/browse/IGNITE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620442#comment-16620442 ] Alexey Platonov commented on IGNITE-9574: - [https://docs.google.com/document/d/1kLbJOIup5B918Ku86lig5DacyUWLfSp7iF5U1Uv7WOw/edit?usp=sharing] > Document Gradient boosting > -- > > Key: IGNITE-9574 > URL: https://issues.apache.org/jira/browse/IGNITE-9574 > Project: Ignite > Issue Type: Task > Components: documentation, ml >Reporter: Aleksey Zinoviev >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9627) TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620413#comment-16620413
]
ASF GitHub Bot commented on IGNITE-9627:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4790
> TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
> -
>
> Key: IGNITE-9627
> URL: https://issues.apache.org/jira/browse/IGNITE-9627
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test is flaky in master. Also, it uses the default failure handler and
> can halt JVM.
> Example of fail: [TC
> build|https://ci.ignite.apache.org/viewLog.html?buildId=1895268=buildResultsDiv=IgniteTests24Java8_Spi#testNameId-3225493048753223945].
> Log:
> {noformat}
> [2018-09-18 06:12:42,466][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Client wasn't segmented.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiSkipMessageSendTest.testClientSegmented(TcpCommunicationSpiSkipMessageSendTest.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9643) [TC Bot] update cwiki
Ryabov Dmitrii created IGNITE-9643: -- Summary: [TC Bot] update cwiki Key: IGNITE-9643 URL: https://issues.apache.org/jira/browse/IGNITE-9643 Project: Ignite Issue Type: Task Reporter: Ryabov Dmitrii We need to update [wiki page|https://cwiki.apache.org/confluence/display/IGNITE/Make+Teamcity+Green+Again#MakeTeamcityGreenAgain-MTCGABot] with latest changes and new implemented features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7251) Remove term "fabric" from Ignite deliverables
[
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620390#comment-16620390
]
Peter Ivanov commented on IGNITE-7251:
--
I am on the task as soon as Java 9 will be fixed.
> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Blocker
> Labels: important
> Fix For: 2.7
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release -
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as -
> {{apache-ignite-\{version}-bin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9608) Fix buttons on start demo
[ https://issues.apache.org/jira/browse/IGNITE-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9608: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Fix buttons on start demo > - > > Key: IGNITE-9608 > URL: https://issues.apache.org/jira/browse/IGNITE-9608 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.7 > > Original Estimate: 2h > Time Spent: 2h > Remaining Estimate: 0h > > !https://snag.gy/HrOW1Y.jpg! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9026) Two levels of Peer class loading fails in CONTINUOUS mode
[ https://issues.apache.org/jira/browse/IGNITE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryabov Dmitrii updated IGNITE-9026: --- Fix Version/s: 2.8 > Two levels of Peer class loading fails in CONTINUOUS mode > - > > Key: IGNITE-9026 > URL: https://issues.apache.org/jira/browse/IGNITE-9026 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: David Harvey >Assignee: David Harvey >Priority: Major > Fix For: 2.8 > > Attachments: master_1b3742f4d7_p2p_two_hops.patch > > > We had an seemingly functional system in SHARED_MODE, where we have a custom > StreamReceiver that sometimes sends closures on the peer class loaded code to > other servers. However, we ended up running out of Metaspace, because we had > > 6000 class loaders! We suspected a regression in this change > [https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c], > so we switched to CONTINUOUS mode. We then started getting failures to > load some of the classes for the closures on the second server. Through > some testing and code inspection, there seems to be the following flaws > between GridDeploymentCommunication.sendResourceRequest and its two callers. > The callers iterate though all the participant nodes until they find an > online node that responds to the request (timeout is treated as offline > node), with either success or failure, and then the loop terminates. The > assumption is that all nodes are equally capable of providing the resource, > so if one fails, then the others would also fail. > The first flaw is that GridDeploymentCommunication.sendResourceRequest() has > a check for a cycle, i.e., whether the destination node is one of the nodes > that originated or forwarded this request, and in that case, a failure > response is faked. However, that causes the caller's loop to terminate. So > depending on the order of the nodes in the participant list, > sendResourceRequest() may fail before trying any nodes because it has one of > the calling nodes on this list. It should instead be skipping any of the > calling nodes. > Example with 1 client node a 2 server nodes: C1 sends data to S1, which > forwards closure to S2. C1 also sends to S2 which forwards to S1. So now > the node lists on S1 and S2 contain C1 and the other S node. If the order > of the node lists on S1 is (S2,C1) and on S2 (S1,C1), then when S1 tries to > load a class, it will try S2, then S2 will try S1, but will get a fake > failure generated, causing S2 not to try more nodes (i.e., C1), and causing > S1 also not to try more nodes. > The other flaw is the assumption that all participants have equal access to > the resource. Assume S1 knows about userVersion1 via S3 and S4, with S3 > though C1 and S4 through C2. If C2 fails, then S4 is not capable of getting > back to a master, but S1 has no way of knowing that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620382#comment-16620382
]
Denis Garus commented on IGNITE-8640:
-
Freezing occurs if a node has a NoOpFailureHandler.
In case using, for example, a StopNodeFailureHandler the node will be stopped.
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.8
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:544)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1190)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:722)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2332)
> at
>
***UNCHECKED*** [jira] [Commented] (IGNITE-7499) DataRegionMetricsImpl#getPageSize returns ZERO for system data regions
[ https://issues.apache.org/jira/browse/IGNITE-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620373#comment-16620373 ] Alexey Kuznetsov commented on IGNITE-7499: -- [~andrey-kuznetsov], There no special reason, I just collect metrics from ALL regions to show on external tools, like Web Console. And I do not like idea to filter system / regular data regions on UI. It is better just collect metrics and show them. > DataRegionMetricsImpl#getPageSize returns ZERO for system data regions > -- > > Key: IGNITE-7499 > URL: https://issues.apache.org/jira/browse/IGNITE-7499 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Alexey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Working on IGNITE-7492 I found that DataRegionMetricsImpl#getPageSize returns > ZERO for system data regions. > Meanwhile there is also > org.apache.ignite.internal.pagemem.PageMemory#systemPageSize method. > That looks a bit strange, why we need PageSize and SystemPageSize ? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9162) Query returns ICE: org.h2.table.TableView cannot be cast
[
https://issues.apache.org/jira/browse/IGNITE-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620369#comment-16620369
]
Sergey Grimstad commented on IGNITE-9162:
-
tests [https://ci.ignite.apache.org/viewLog.html?buildId=1900544;] (some flaky)
> Query returns ICE: org.h2.table.TableView cannot be cast
>
>
> Key: IGNITE-9162
> URL: https://issues.apache.org/jira/browse/IGNITE-9162
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4
>Reporter: Sergey Kozlov
>Assignee: Sergey Grimstad
>Priority: Critical
> Fix For: 2.7
>
> Attachments: 4779.patch, caches.xml, client.xml, policies.xml,
> server.xml
>
>
> 1. Start 1 Ignite node {{bin/ignite.sh server.xml -v -J-DCONSISTENT_ID=node1}}
> 2. Start sqlline {{bin/sqlline.sh -u
> jdbc:ignite:thin://127.0.0.1/?distributedJoins=true}}
> 3. Execute statements:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> CREATE TABLE t1 ( id INT NOT NULL, int_col1
> INT NOT NULL, PRIMARY KEY (id)) WITH "TEMPLATE=partitioned";
> No rows affected (0,151 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> INSERT INTO t1 (id,int_col1) VALUES
> (1,0),(2,0),(3,0),(4,0);
> 4 rows affected (0,052 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> SELECT * FROM ( SELECT * FROM t1 WHERE
> int_col1 > 0 ORDER BY id ) WHERE int_col1 = 1
> ORDER BY id;
> Error: javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: org.h2.table.TableView cannot be
> cast
> to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> (state=5,code=0)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> Node log:
> {noformat}
> [12:39:38,162][SEVERE][client-connector-#50][JdbcRequestHandler] Failed to
> execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=PUBLIC,
> pageSize=1024, maxRows=0, sqlQry=SELECT * FROM ( SELECT * FROM t1 WHERE
> int_col1 > 0 ORDER BY id ) WHERE int_col1 = 1 ORDER BY id, args=[],
> stmtType=ANY_STATEMENT_TYPE]]
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2047)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:456)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:203)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:160)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.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: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:
> org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2601)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> ... 12 more
> Caused by: java.lang.ClassCastException: org.h2.table.TableView cannot be
> cast to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2336)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2268)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2250)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
> at
>
[jira] [Updated] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-8547:
Fix Version/s: 2.7
> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9, 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: test
> Fix For: 2.7
>
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException,
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
> for (int i = 0; i < 16; i++) {
> final int ii = i;
> Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> thread.start();
> threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
> thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And
> that's exactly what OptimizedMarshaller does.
> See also the attached test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8290) Activation message handling fails with AssertionError sporadically.
[ https://issues.apache.org/jira/browse/IGNITE-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-8290: - Fix Version/s: 2.8 > Activation message handling fails with AssertionError sporadically. > --- > > Key: IGNITE-8290 > URL: https://issues.apache.org/jira/browse/IGNITE-8290 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Andrew Mashenkov >Assignee: Andrey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Attachments: disco-msg-fails-2.stack, disco-msg-fails.stack > > > Some test fails sporadically due to AssertionError while processing custom > discovery message which can leads to grid and tests handing. > PFA stacktraces. > org.apache.ignite.internal.processors.cache.persistence.db.IgnitePdsWholeClusterRestartTest > is a good startpoint. > However, the test passes at master, it's every run logs lot of > AssertionErrors . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-7499) DataRegionMetricsImpl#getPageSize returns ZERO for system data regions
[ https://issues.apache.org/jira/browse/IGNITE-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-7499: - Fix Version/s: (was: 2.7) 2.8 > DataRegionMetricsImpl#getPageSize returns ZERO for system data regions > -- > > Key: IGNITE-7499 > URL: https://issues.apache.org/jira/browse/IGNITE-7499 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Alexey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.8 > > > Working on IGNITE-7492 I found that DataRegionMetricsImpl#getPageSize returns > ZERO for system data regions. > Meanwhile there is also > org.apache.ignite.internal.pagemem.PageMemory#systemPageSize method. > That looks a bit strange, why we need PageSize and SystemPageSize ? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6893) Java Deadlocks monitoring
[
https://issues.apache.org/jira/browse/IGNITE-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-6893:
-
Fix Version/s: (was: 2.7)
2.8
> Java Deadlocks monitoring
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Labels: iep-7
> Fix For: 2.8
>
>
> Java Level Deadlocks
> Description
> This situation occurs if user or Ignite comes to a Java-level deadlock due to
> a bug in code - reverse order synchronized(mux1) {synchronized (mux2) {}}
> sections, reverse order reentrant locks, etc.
> Detection and Solution
> This most likely cannot be resolved automatically and will require JVM
> restart.
> We can implement periodical threaddumps analysis and detect the deadlock.
> Report
> Deadlock should be reported to the logs.
> Web Console should fire an alert on java deadlock detection and display a
> warning on UI.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8862) IgniteChangeGlobalStateTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-8862: - Fix Version/s: 2.8 > IgniteChangeGlobalStateTest hangs on TeamCity > - > > Key: IGNITE-8862 > URL: https://issues.apache.org/jira/browse/IGNITE-8862 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7251) Remove term "fabric" from Ignite deliverables
[
https://issues.apache.org/jira/browse/IGNITE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620353#comment-16620353
]
Anton Vinogradov commented on IGNITE-7251:
--
[~vveider]
The release is coming :)
Is it possible to review this task asap?
> Remove term "fabric" from Ignite deliverables
> -
>
> Key: IGNITE-7251
> URL: https://issues.apache.org/jira/browse/IGNITE-7251
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Anton Vinogradov
>Priority: Blocker
> Labels: important
> Fix For: 2.7
>
>
> Apache Ignite binary releases still include “fabric” word in their names:
> https://ignite.apache.org/download.cgi#binaries
> For instance, this is a full name of the previous release -
> apache-ignite-fabric-2.3.0-bin.
> It’s a little oversight on our side because the project has not been
> positioned as a fabric for a while.
> Remove “fabric” from the name and have the binary releases named as -
> {{apache-ignite-\{version}-bin}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-8823:
-
Affects Version/s: 2.6
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Ignite8823ReproducerTest.java
>
>
> Reproducable by test method {{testCreateConsistencyMultithreaded}} in
> {{IgfsPrimaryMultiNodeSelfTest}} and
> {{IgfsPrimaryRelaxedConsistencyMultiNodeSelfTest}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
>
[jira] [Updated] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-8823:
-
Fix Version/s: 2.8
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: Ignite8823ReproducerTest.java
>
>
> Reproducable by test method {{testCreateConsistencyMultithreaded}} in
> {{IgfsPrimaryMultiNodeSelfTest}} and
> {{IgfsPrimaryRelaxedConsistencyMultiNodeSelfTest}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
>
[jira] [Updated] (IGNITE-8570) Create lighter version of GridStringLogger
[
https://issues.apache.org/jira/browse/IGNITE-8570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-8570:
-
Fix Version/s: (was: 2.7)
2.8
> Create lighter version of GridStringLogger
> --
>
> Key: IGNITE-8570
> URL: https://issues.apache.org/jira/browse/IGNITE-8570
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_:
> Most usages of {{GridStringLogger}} in test assumes the following scenario.
> First, it is set as a logger for some Ignite node.
> Then, after some activity on that node, log content is searched for some
> predefined strings.
> {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to
> store log contents, older contents gets dropped on exaustion.
> Thus, changes that add more logging may damage some independent tests that
> use {{GridStringLogger}}.
>
> +_The suggestion for new implementation:_+
> The suggestion is to implement and use another test logger conforming to
> these requirements:
> * It does not accumulate any logs(actually, it will print no logs to
> anywhere)
> * It allows to set the listener that fires when log message matches certain
> regular expression, {{Matcher}} can be passed to the listener
>
> _+Proposed design+_, pseudocode:
> ```
> Class GridRegexpLogger implements IgniteLogger{
> …
> debug(String str){
> if (/* str matches pattern. */)
> \{ /* notify listeners. */ }
> }
> …
> listen("regexp", IgniteInClosure loggerListener)// listener receives
> message
> { /* registers listener. */ }
> listenDebug("regexp", loggerListener)
> { /* registers listener for debug output only. */ }
> …
> }
> ```
> +_Sample regexp logger usage_+:
> ```
> GridRegexpLogger logger;
> logger.listen(“regexp”, new GridRegexpListener());
> logger.listenDebug("regexp", new GridRegexpListener());
> ```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9627) TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620345#comment-16620345
]
Alexey Goncharuk commented on IGNITE-9627:
--
[~NSAmelchev] looks good, will merge shortly.
> TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
> -
>
> Key: IGNITE-9627
> URL: https://issues.apache.org/jira/browse/IGNITE-9627
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test is flaky in master. Also, it uses the default failure handler and
> can halt JVM.
> Example of fail: [TC
> build|https://ci.ignite.apache.org/viewLog.html?buildId=1895268=buildResultsDiv=IgniteTests24Java8_Spi#testNameId-3225493048753223945].
> Log:
> {noformat}
> [2018-09-18 06:12:42,466][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Client wasn't segmented.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiSkipMessageSendTest.testClientSegmented(TcpCommunicationSpiSkipMessageSendTest.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-896) Configuration inconsistency
[ https://issues.apache.org/jira/browse/IGNITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Kulagin updated IGNITE-896: --- Fix Version/s: 2.8 > Configuration inconsistency > --- > > Key: IGNITE-896 > URL: https://issues.apache.org/jira/browse/IGNITE-896 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: sprint-5 >Reporter: Valentin Kulichenko >Assignee: Nikolai Kulagin >Priority: Minor > Labels: Usability > Fix For: 2.8 > > > I noticed that some entities on cache configuration are configured via > factories, while others are set directly. For example, we use factory for > ExpiryPolicy, but not for EvictionPolicy, which looks inconsistent. Since > factory-based approach comes from JCache, I think we should use it wherever > possible. > Here is the list of settings that need to be fixed: > * Affinity > * AffinityMapper > * EvictionFilter > * EvictionPolicy > * CacheInterceptor > * TopologyValidator > Need to add new configuration properties that use factories and deprecate old > ones (do not remove for compatibility). > Also need to check other configuration beans (list above is for cache config > only). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Garus updated IGNITE-8640:
Fix Version/s: (was: 2.7)
2.8
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.8
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:544)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1190)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:722)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2332)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This
[jira] [Updated] (IGNITE-9560) Security permissions to restrict arbitrary code exectution
[ https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-9560: Fix Version/s: 2.8 > Security permissions to restrict arbitrary code exectution > -- > > Key: IGNITE-9560 > URL: https://issues.apache.org/jira/browse/IGNITE-9560 > Project: Ignite > Issue Type: Task > Components: security >Affects Versions: 2.6 >Reporter: Anton Vinogradov >Priority: Major > Fix For: 2.8 > > > SecurityPermission class should be extended to cover all cases able to cause > arbitrary code execution. > 1) Restriction on listener registration > - IgniteEvents listener > - CQ listener > 2) Restriction on closure (able to be executed on the remote node) execution > - Compute API (seems to be covered, should be rechecked) > - Services > - Entry processor > 3) We have to make sure that cases listed at #1 and #2 are the all possible > cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6333) Improve cache transaction metrics to better understand transactions efficiency.
[ https://issues.apache.org/jira/browse/IGNITE-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-6333: - Fix Version/s: (was: 2.7) > Improve cache transaction metrics to better understand transactions > efficiency. > --- > > Key: IGNITE-6333 > URL: https://issues.apache.org/jira/browse/IGNITE-6333 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexei Scherbakov >Assignee: Pavel Pereslegin >Priority: Major > Labels: cache, newbie > > I suggest to add: > 1. Count of rollbacks due to transaction timeout. Depends on IGNITE-6181 > 2. Count of rollbacks due to deadlocks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-9275) Introduce mechanism to fetch partition file via a p2p protocol
[ https://issues.apache.org/jira/browse/IGNITE-9275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9275: Fix Version/s: 2.8 > Introduce mechanism to fetch partition file via a p2p protocol > -- > > Key: IGNITE-9275 > URL: https://issues.apache.org/jira/browse/IGNITE-9275 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.8 > > > As a first step to estimate how much faster the file-rebalancing may be, I > suggest to implement a simple partition fetch procedure via the communication > SPI extension: > 1) Node A sends a partition fetch request to node B > 2) Node B starts a checkpoint and creates a local copy of the partition. Note > that during the partition copy there might be concurrent ongoing checkpoints, > this must be handled properly > 3) Node B establishes a new TCP connection on the TCP communication port > (handshake and verification is assumed) > 4) Node B calls transferFile (or native analogue, investigation needed) to > send the partition file in the most effective way > 5) Node A writes the file to a specified location on the local file system > After this mechanics is implemented, we need to hack the rebalance code and > use partition fetch logic instead of regular rebalance to measure > 1) How much faster (or slower) the new approach performs > 2) How it affects the concurrent transactions in the grid -- This message was sent by Atlassian JIRA (v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-8366) Replace service instance parameter with a class name in ServiceConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-8366:
Fix Version/s: (was: 2.7)
2.8
> Replace service instance parameter with a class name in ServiceConfiguration
>
>
> Key: IGNITE-8366
> URL: https://issues.apache.org/jira/browse/IGNITE-8366
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Reporter: Denis Mekhanikov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: iep-17
> Fix For: 2.8
>
>
> {{ServiceConfiguration#service}} parameter should be replaced with a
> {{className}}. All parameters, needed for service initialization, should be
> provided as a map of properties in {{ServiceConfiguration}}.
> This approach has two advantages:
> # It allows service redeployment with changed classes, because there will be
> no need to deserialize the service object.
> # Changes of initialization parameters will be able to be detected, when
> manual redeployment happens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
***UNCHECKED*** [jira] [Updated] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples
[ https://issues.apache.org/jira/browse/IGNITE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryabov Dmitrii updated IGNITE-6826: --- Fix Version/s: (was: 2.7) 2.8 > Change default DiscoverySpi ipFinder type for examples > -- > > Key: IGNITE-6826 > URL: https://issues.apache.org/jira/browse/IGNITE-6826 > Project: Ignite > Issue Type: Improvement > Components: examples >Affects Versions: 2.3 >Reporter: Alexey Popov >Assignee: Ryabov Dmitrii >Priority: Major > Labels: newbie > Fix For: 2.8 > > > It is better to change multicast ipFinder to static (vm) ipFinder for java > examples, .NET examples and C++ examples. > http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-2894) Binary object inside of Externalizable still serialized with OptimizedMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-2894:
Fix Version/s: (was: 2.7)
> Binary object inside of Externalizable still serialized with
> OptimizedMarshaller
>
>
> Key: IGNITE-2894
> URL: https://issues.apache.org/jira/browse/IGNITE-2894
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Amelchev Nikita
>Priority: Critical
> Labels: community, customer, iep-2
>
> When binary marshaller meets an Externalizable object, it switches to
> optimized marshaller. And if there is a regular object inside, it's still
> serialized with optimized, even if its type is declared in binary
> configuration with custom mapper, etc.
> Essentially, binary marshaller should fully support Java serialization,
> including {{Externalizable}} and {{writeObject}}/{{readObject}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6135) java.sql.Date is serialized using OptimizedMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-6135:
Fix Version/s: (was: 2.7)
> java.sql.Date is serialized using OptimizedMarshaller
> -
>
> Key: IGNITE-6135
> URL: https://issues.apache.org/jira/browse/IGNITE-6135
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Amelchev Nikita
>Priority: Major
>
> For some reason, if an object has a field of {{java.sql.Date}}, it's
> serialized with {{OptimizedMarshaller}}. It should be a first class citizen,
> similar to {{java.util.Date}}.
> In addition, it's possible to write a field using builder like this:
> {code}
> builder.setField(name, val, java.util.Date.class)
> {code}
> where {{val}} is instance of {{java.sql.Date}}. This leads to an exception
> during deserialization, because {{java.util.Date}} would be expected.
> More context and code reproducing the issue can be found here:
> http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-td16276.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-4188) Savepoints support inside of Ignite Transactions
[
https://issues.apache.org/jira/browse/IGNITE-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryabov Dmitrii updated IGNITE-4188:
---
Fix Version/s: (was: 2.7)
2.8
> Savepoints support inside of Ignite Transactions
>
>
> Key: IGNITE-4188
> URL: https://issues.apache.org/jira/browse/IGNITE-4188
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Magda
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.8
>
>
> A savepoint is a special mark inside a transaction that allows all commands
> that are executed after it was established to be rolled back, restoring the
> transaction state to what it was at the time of the savepoint.
> Here is a reference to the similar functionality implemented by some of RDBMs
> vendors.
> https://www.postgresql.org/docs/8.1/static/sql-savepoint.html
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_10001.htm
> http://dev.mysql.com/doc/refman/5.7/en/savepoint.html
> Consider the following example.
> {code}
> BEGIN;
> INSERT INTO table1 VALUES (1);
> SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (2);
> ROLLBACK TO SAVEPOINT my_savepoint;
> INSERT INTO table1 VALUES (3);
> COMMIT;
> {code}
> The execution result must guarantee that only values 1 and 3 are inserted
> into table1.
> In Ignite, it should be supported this way (preserving the same behavior as
> above).
> {code}
> Ignite ignite = ;
> IgniteCache c = ;
> try (Transaction tx = ignite.transactions().txStart()) {
> c.put(1, 1);
>
> tx.savepoint("mysavepoint");
>
> c.put(2, 2);
>
> tx.rollbackToSavepoint("mysavepoint");
>
> c.put(3, 3);
>
> tx.commit();
> }
> {code}
> As a summary the following has to be supported on Ignite side:
> - The {{savepoint}} method which will set a named transaction savepoint with
> a name of an identifier.
> - Multiple savepoints defined within a transaction. The names of the
> savepoints have to differ from each other. If the current transaction has a
> savepoint with the same name, the old savepoint is deleted and a new one is
> set.
> - The {{rollbackToSavepoint}} method that will roll back all the changes done
> after a specific checkpoint establishment.
> - The {{releaseCheckpoint}} method that will destroy a savepoint, keeping the
> effects of commands executed after it was established.
> - Full support of the behavior listed above at the level of ODBC and JDBC
> drivers and DML (will be handled under separate tickets).
> - The behavior has to be support for all transactional modes.
> Original proposal on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/TX-savepoints-td12041.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9627) TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
[
https://issues.apache.org/jira/browse/IGNITE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620322#comment-16620322
]
Amelchev Nikita commented on IGNITE-9627:
-
*The test can halt JVM.*
I have rewritten test to avoid use default failure handler.
*The test was flaky.*
I set segmentation policy to NOOP (was STOP) in config. Default handler stops
node on segmentation happens in the test. The local listener couldn't get the
event if segmentation failure handles first.
*Other fixes.*
I have decreased timeouts and removed unnecessary sleeps for more fast test
completion. It still reproduces the problem that fixed in IGNITE-7944 if revert
prod changes.
Code style issues.
[TC
tests|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Spi_IgniteTests24Java8=pull%2F4790%2Fhead=buildTypeStatusDiv]
are OK. I have run 160 times and test separate suite.
[~agoncharuk] Could you review, please?
> TcpCommunicationSpiSkipMessageSendTest.testClientSegmented is flaky in master
> -
>
> Key: IGNITE-9627
> URL: https://issues.apache.org/jira/browse/IGNITE-9627
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test is flaky in master. Also, it uses the default failure handler and
> can halt JVM.
> Example of fail: [TC
> build|https://ci.ignite.apache.org/viewLog.html?buildId=1895268=buildResultsDiv=IgniteTests24Java8_Spi#testNameId-3225493048753223945].
> Log:
> {noformat}
> [2018-09-18 06:12:42,466][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Client wasn't segmented.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpiSkipMessageSendTest.testClientSegmented(TcpCommunicationSpiSkipMessageSendTest.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9609) Web console: update to AngularJS 1.7.4
[ https://issues.apache.org/jira/browse/IGNITE-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9609: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Merged to master. > Web console: update to AngularJS 1.7.4 > -- > > Key: IGNITE-9609 > URL: https://issues.apache.org/jira/browse/IGNITE-9609 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.7 > > Time Spent: 56m > Remaining Estimate: 0h > > Let's update package-.json to use AngularJS 1.7.4, the 1.7.3 release > introduced some interesting new feature we might use (like extra form methods > and arbitrary event/property bindings). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9026) Two levels of Peer class loading fails in CONTINUOUS mode
[
https://issues.apache.org/jira/browse/IGNITE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620305#comment-16620305
]
Ryabov Dmitrii commented on IGNITE-9026:
PDS tests were unmuted 2 days ago (branch have master 7 days old), so they
should be ok. Test {{testGetReadThrough}} had 2 fails 2 weeks ago,
[~syssoftsol], please, rebase your branch on current master and rerun "Run All"
on [TeamCity|https://ci.ignite.apache.org].
> Two levels of Peer class loading fails in CONTINUOUS mode
> -
>
> Key: IGNITE-9026
> URL: https://issues.apache.org/jira/browse/IGNITE-9026
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: David Harvey
>Assignee: David Harvey
>Priority: Major
> Attachments: master_1b3742f4d7_p2p_two_hops.patch
>
>
> We had an seemingly functional system in SHARED_MODE, where we have a custom
> StreamReceiver that sometimes sends closures on the peer class loaded code to
> other servers. However, we ended up running out of Metaspace, because we had
> > 6000 class loaders! We suspected a regression in this change
> [https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c],
> so we switched to CONTINUOUS mode. We then started getting failures to
> load some of the classes for the closures on the second server. Through
> some testing and code inspection, there seems to be the following flaws
> between GridDeploymentCommunication.sendResourceRequest and its two callers.
> The callers iterate though all the participant nodes until they find an
> online node that responds to the request (timeout is treated as offline
> node), with either success or failure, and then the loop terminates. The
> assumption is that all nodes are equally capable of providing the resource,
> so if one fails, then the others would also fail.
> The first flaw is that GridDeploymentCommunication.sendResourceRequest() has
> a check for a cycle, i.e., whether the destination node is one of the nodes
> that originated or forwarded this request, and in that case, a failure
> response is faked. However, that causes the caller's loop to terminate. So
> depending on the order of the nodes in the participant list,
> sendResourceRequest() may fail before trying any nodes because it has one of
> the calling nodes on this list. It should instead be skipping any of the
> calling nodes.
> Example with 1 client node a 2 server nodes: C1 sends data to S1, which
> forwards closure to S2. C1 also sends to S2 which forwards to S1. So now
> the node lists on S1 and S2 contain C1 and the other S node. If the order
> of the node lists on S1 is (S2,C1) and on S2 (S1,C1), then when S1 tries to
> load a class, it will try S2, then S2 will try S1, but will get a fake
> failure generated, causing S2 not to try more nodes (i.e., C1), and causing
> S1 also not to try more nodes.
> The other flaw is the assumption that all participants have equal access to
> the resource. Assume S1 knows about userVersion1 via S3 and S4, with S3
> though C1 and S4 through C2. If C2 fails, then S4 is not capable of getting
> back to a master, but S1 has no way of knowing that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9642) Examples: can't compile springdata examples
Stepan Pilschikov created IGNITE-9642:
-
Summary: Examples: can't compile springdata examples
Key: IGNITE-9642
URL: https://issues.apache.org/jira/browse/IGNITE-9642
Project: Ignite
Issue Type: Bug
Components: examples
Affects Versions: 2.7
Reporter: Stepan Pilschikov
Can't compile springdata examples from sources
{code}
[INFO] -
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 3.890 s
[INFO] Finished at: 2018-09-19T08:27:16Z
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on
project ignite-examples: Compilation failure: Compilation failure:
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/PersonRepository.java:[23,49]
package org.apache.ignite.springdata20.repository does not exist
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/PersonRepository.java:[24,56]
package org.apache.ignite.springdata20.repository.config does not exist
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/PersonRepository.java:[25,56]
package org.apache.ignite.springdata20.repository.config does not exist
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/PersonRepository.java:[34,43]
cannot find symbol
[ERROR] symbol: class IgniteRepository
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/PersonRepository.java:[33,2]
cannot find symbol
[ERROR] symbol: class RepositoryConfig
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringAppCfg.java:[25,49]
package org.apache.ignite.springdata20.repository does not exist
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringAppCfg.java:[26,56]
package org.apache.ignite.springdata20.repository.config does not exist
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringAppCfg.java:[27,57]
package org.apache.ignite.springdata20.repository.support does not exist
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringAppCfg.java:[43,2]
cannot find symbol
[ERROR] symbol: class EnableIgniteRepositories
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/PersonRepository.java:[56,6]
cannot find symbol
[ERROR] symbol: class Query
[ERROR] location: interface
org.apache.ignite.examples.springdata.PersonRepository
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringDataExample.java:[62,13]
cannot find symbol
[ERROR] symbol: method deleteAll()
[ERROR] location: variable repo of type
org.apache.ignite.examples.springdata.PersonRepository
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringDataExample.java:[64,60]
cannot find symbol
[ERROR] symbol: method count()
[ERROR] location: variable repo of type
org.apache.ignite.examples.springdata.PersonRepository
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringDataExample.java:[101,13]
cannot find symbol
[ERROR] symbol: method
save(java.util.TreeMap)
[ERROR] location: variable repo of type
org.apache.ignite.examples.springdata.PersonRepository
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringDataExample.java:[103,49]
cannot find symbol
[ERROR] symbol: method count()
[ERROR] location: variable repo of type
org.apache.ignite.examples.springdata.PersonRepository
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringDataExample.java:[111,29]
cannot find symbol
[ERROR] symbol: method findById(long)
[ERROR] location: variable repo of type
org.apache.ignite.examples.springdata.PersonRepository
[ERROR]
[..sources..]/examples/src/main/java/org/apache/ignite/examples/springdata/SpringDataExample.java:[122,40]
cannot find symbol
[ERROR] symbol: method findAllById(java.util.ArrayList)
[ERROR] location: variable repo of type
org.apache.ignite.examples.springdata.PersonRepository
[ERROR] -> [Help 1]
[ERROR]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9026) Two levels of Peer class loading fails in CONTINUOUS mode
[
https://issues.apache.org/jira/browse/IGNITE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620297#comment-16620297
]
Ignite TC Bot commented on IGNITE-9026:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=1900586]]
* TcpDiscoverySslSelfTest.testNoExtraNodeFailedMessage (last started)
{color:#d04437}PDS (Direct IO) 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=1900606]]
* IgnitePdsNativeIoTestSuite2: IgnitePersistentStoreDataStructuresTest.testSet
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=1900610]]
* IgnitePdsTestSuite2: IgnitePersistentStoreDataStructuresTest.testSet - 0,0%
fails in last 100 master runs.
{color:#d04437}Cache (Expiry Policy){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=1900621]]
* IgniteCacheExpiryPolicyTestSuite:
IgniteCacheTxExpiryPolicyWithStoreTest.testGetReadThrough - 0,0% fails in last
100 master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=1900650buildTypeId=IgniteTests24Java8_RunAll]
> Two levels of Peer class loading fails in CONTINUOUS mode
> -
>
> Key: IGNITE-9026
> URL: https://issues.apache.org/jira/browse/IGNITE-9026
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: David Harvey
>Assignee: David Harvey
>Priority: Major
> Attachments: master_1b3742f4d7_p2p_two_hops.patch
>
>
> We had an seemingly functional system in SHARED_MODE, where we have a custom
> StreamReceiver that sometimes sends closures on the peer class loaded code to
> other servers. However, we ended up running out of Metaspace, because we had
> > 6000 class loaders! We suspected a regression in this change
> [https://github.com/apache/ignite/commit/d2050237ee2b760d1c9cbc906b281790fd0976b4#diff-3fae20691c16a617d0c6158b0f61df3c],
> so we switched to CONTINUOUS mode. We then started getting failures to
> load some of the classes for the closures on the second server. Through
> some testing and code inspection, there seems to be the following flaws
> between GridDeploymentCommunication.sendResourceRequest and its two callers.
> The callers iterate though all the participant nodes until they find an
> online node that responds to the request (timeout is treated as offline
> node), with either success or failure, and then the loop terminates. The
> assumption is that all nodes are equally capable of providing the resource,
> so if one fails, then the others would also fail.
> The first flaw is that GridDeploymentCommunication.sendResourceRequest() has
> a check for a cycle, i.e., whether the destination node is one of the nodes
> that originated or forwarded this request, and in that case, a failure
> response is faked. However, that causes the caller's loop to terminate. So
> depending on the order of the nodes in the participant list,
> sendResourceRequest() may fail before trying any nodes because it has one of
> the calling nodes on this list. It should instead be skipping any of the
> calling nodes.
> Example with 1 client node a 2 server nodes: C1 sends data to S1, which
> forwards closure to S2. C1 also sends to S2 which forwards to S1. So now
> the node lists on S1 and S2 contain C1 and the other S node. If the order
> of the node lists on S1 is (S2,C1) and on S2 (S1,C1), then when S1 tries to
> load a class, it will try S2, then S2 will try S1, but will get a fake
> failure generated, causing S2 not to try more nodes (i.e., C1), and causing
> S1 also not to try more nodes.
> The other flaw is the assumption that all participants have equal access to
> the resource. Assume S1 knows about userVersion1 via S3 and S4, with S3
> though C1 and S4 through C2. If C2 fails, then S4 is not capable of getting
> back to a master, but S1 has no way of knowing that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (IGNITE-9381) p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node disconnect
[ https://issues.apache.org/jira/browse/IGNITE-9381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reopened IGNITE-9381: > p2p does not undeploy ScanQuery IgniteBiPredicate filter on client node > disconnect > -- > > Key: IGNITE-9381 > URL: https://issues.apache.org/jira/browse/IGNITE-9381 > Project: Ignite > Issue Type: Bug >Reporter: Andrew Medvedev >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.7 > > Attachments: AndmedScanFilterClassLoadingTest.java, snapshots.xml > > > Once deployed via scan query, an IgniteBiPredicate filter does not change if > client reconnects (with a modified filter) > Steps to reproduce: > * start server node in separate jvm with attached configuration (persistence > enabled) > * run attached reproducer AndmedScanFilterClassLoadingTest. It includes a > task and a scan filter, both print "FOO" on server side > * modify FOO -> BAR for both > * re-run modifed AndmedScanFilterClassLoadingTest . > Expected: Both print "BAR". > Actual behavior: task prints "BAR", scan filter prints "FOO" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
