[jira] [Updated] (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
]
Ilya Borisov updated IGNITE-9339:
-
Description:
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.
3. Add autofocus support.
4. Fix validation error icon position:
!screenshot-1.png!
was:
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.
3. Add autofocus support.
> 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
> Attachments: screenshot-1.png
>
> 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.
> 3. Add autofocus support.
> 4. Fix validation error icon position:
> !screenshot-1.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (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
]
Ilya Borisov updated IGNITE-9339:
-
Attachment: screenshot-1.png
> 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
> Attachments: screenshot-1.png
>
> 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.
> 3. Add autofocus support.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10013) Node restart may lead to NPE in GridDhtPartitionsExchangeFuture
Sergey Kozlov created IGNITE-10013:
--
Summary: Node restart may lead to NPE in
GridDhtPartitionsExchangeFuture
Key: IGNITE-10013
URL: https://issues.apache.org/jira/browse/IGNITE-10013
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 2.7
1. Start 4 nodes with ~100 caches, create a few dynamic caches
2. Load data (~500 entries per cache)
3. Restart every node starting from first
The first node may throw NPE:
{noformat}
[20:00:18,355][INFO][exchange-worker-#63][time] Started exchange init
[topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0],
mvccCrd=MvccCoordinator [nodeId=c7a332ee-ee85-4604-aa93-919f15e34e36,
crdVer=1540497597005, topVer=AffinityTopologyVersion [topVer=1,
minorTopVer=0]], mvccCrdChange=false, crd=true, evt=NODE_JOINED,
evtNode=cc8ed618-2f14-46cf-be03-645291c397aa, customEvt=null, allowMerge=true]
[20:00:18,358][INFO][exchange-worker-#63][GridDhtPartitionsExchangeFuture]
Finish exchange future [startVer=AffinityTopologyVersion [topVer=5,
minorTopVer=0], resVer=AffinityTopologyVersion [topVer=5, minorTopVer=0],
err=null]
[20:00:18,364][SEVERE][sys-#77][GridCacheIoManager] Failed processing message
[senderId=c50165fb-1afd-4b3e-8fba-ac825aa532fa,
msg=GridDhtPartitionsSingleMessage [parts=HashMap
{-553318226=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553318133=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=512],
-553318412=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553315529=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553315497=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-553315498=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=490],
-2100569601=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=100],
-553318319=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=512],
374280891=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion [topVer=4,
minorTopVer=1], updateSeq=5, size=32], 374280890=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5, size=64],
374280889=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion [topVer=4,
minorTopVer=1], updateSeq=5, size=128], 374280888=GridDhtPartitionMap
[moving=0, top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5,
size=512], 374280887=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=23], 374280886=GridDhtPartitionMap
[moving=0, top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5,
size=31], 374280885=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=61], 374280884=GridDhtPartitionMap
[moving=0, top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5,
size=490], -553315527=GridDhtPartitionMap [moving=0,
top=AffinityTopologyVersion [topVer=4, minorTopVer=1], updateSeq=5, size=512],
-553315495=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=5, size=512],
-553315528=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=4, size=490],
-553315496=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=4, size=512],
-553315526=GridDhtPartitionMap [moving=0, top=AffinityTopologyVersion
[topVer=4, minorTopVer=1], updateSeq=4, size=512]}, partCntrs=null,
partsSizes=HashMap {-553318226=HashMap {1=1, 2=1, 3=1, 4=1, 5=1, 6=1, 7=1, 9=1,
11=1, 13=1, 20=1, 21=1, 22=1, 24=1, 27=1, 28=1, 31=1, 32=1, 33=1, 34=1, 35=1,
36=1, 39=1, 42=1, 43=1, 47=1, 55=1, 57=1, 58=1, 63=1, 64=1, 65=1, 66=1, 67=1,
70=1, 71=1, 72=1, 73=1, 74=1, 75=1, 79=1, 80=1, 82=1, 84=1, 86=1, 88=1, 90=1,
95=1, 96=1, 99=1}, -553318133=HashMap {1=1, 2=1, 3=1, 4=1, 5=1, 6=1, 7=1, 8=1,
9=1, 10=1, 11=1, 12=1, 13=1, 14=1, 15=1, 16=1, 17=1, 18=1, 19=1, 20=1, 21=1,
22=1, 23=1, 24=1, 25=1, 26=1, 27=1, 28=1, 29=1, 30=1, 31=1, 32=1, 33=1, 34=1,
35=1, 36=1, 37=1, 38=1, 39=1, 40=1, 41=1, 42=1, 43=1, 44=1, 45=1, 46=1, 47=1,
48=1, 49=1, 50=1, 51=1, 52=1, 53=1, 54=1, 55=1, 56=1, 57=1, 58=1, 59=1, 60=1,
61=1, 62=1, 63=1, 64=1, 65=1, 66=1, 67=1, 68=1, 69=1, 70=1, 71=1, 72=1, 73=1,
74=1, 75=1, 76=1, 77=1, 78=1, 79=1, 80=1, 81=1, 82=1, 83=1, 84=1, 85=1, 86=1,
87=1, 88=1, 89=1, 90=1, 91=1, 92=1, 93=1, 94=1, 95=1, 96=1, 97=1, 98=1, 99=1,
100=1},
[jira] [Commented] (IGNITE-9983) Add an inspection configuration for TC suite with enabled short list of rules
[
https://issues.apache.org/jira/browse/IGNITE-9983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664307#comment-16664307
]
Maxim Muzafarov commented on IGNITE-9983:
-
[~NIzhikov]
The new [Inspections:
Core|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=pull%2F5059%2Fhead=buildTypeStatusDiv]
suite has been prepared. Enabled rules:
* Unused imports;
* Missorted modifiers;
* 'size() == 0' replaceable with 'isEmpty()';
* Missing @Override annotation;
The latest changes from the master branch merged into PR.
I've added new inspections configuration for TC (unnecessary inspection like
{{`Android`}} have removed from config).
Build pass successfully with {{Inspections total: 0 (-1), errors: 0}}.
> Add an inspection configuration for TC suite with enabled short list of rules
> -
>
> Key: IGNITE-9983
> URL: https://issues.apache.org/jira/browse/IGNITE-9983
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
>
> Currently, some of the inspection rules fixed over the whole Apache Ignite
> Project:
> IGNITE-9923
> IGNITE-9652
> IGNITE-9597
> IGNITE-9311
> We need to create an inspection configuration for the TC suite `Inspections:
> Core` with enabled only these rules.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10012) Add Transactional SQL feature description to Ignite website
Prachi Garg created IGNITE-10012: Summary: Add Transactional SQL feature description to Ignite website Key: IGNITE-10012 URL: https://issues.apache.org/jira/browse/IGNITE-10012 Project: Ignite Issue Type: Task Reporter: Prachi Garg Assignee: Prachi Garg Fix For: 2.7 [~Artem Budnikov], Please provide some information/ link to the documentation about this feature so that some description can be added to the website. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10011) Pages leak suspicion in PDS
[ https://issues.apache.org/jira/browse/IGNITE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10011: -- Fix Version/s: 2.8 > Pages leak suspicion in PDS > --- > > Key: IGNITE-10011 > URL: https://issues.apache.org/jira/browse/IGNITE-10011 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ilya Kasnacheev >Priority: Major > Labels: performance > Fix For: 2.8 > > Attachments: Main.java > > > See the attached Main which adds 500k records to 3 caches, then clears them, > rinse, repeat. > When ran with default settings, totalAllocatedSize will slowly double over > the course of a few hours and then continue to grow. > When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> > 1800M -> etc. > See the userlist discussion -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10011) Pages leak suspicion in PDS
[ https://issues.apache.org/jira/browse/IGNITE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664003#comment-16664003 ] Alexey Goncharuk commented on IGNITE-10011: --- Confirming the issue. One of the issues is that an empty data page is actually not returned to the reuse bucket, but instead it is returned to the free list. The second suspicious behavior I observed when running with 2 buckets is that a completely empty data page is put into the bucket with the index 0, not 1. The correctness of this is yet to be confirmed. > Pages leak suspicion in PDS > --- > > Key: IGNITE-10011 > URL: https://issues.apache.org/jira/browse/IGNITE-10011 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ilya Kasnacheev >Priority: Major > Labels: performance > Fix For: 2.8 > > Attachments: Main.java > > > See the attached Main which adds 500k records to 3 caches, then clears them, > rinse, repeat. > When ran with default settings, totalAllocatedSize will slowly double over > the course of a few hours and then continue to grow. > When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> > 1800M -> etc. > See the userlist discussion -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10011) Pages leak suspicion in PDS
Ilya Kasnacheev created IGNITE-10011: Summary: Pages leak suspicion in PDS Key: IGNITE-10011 URL: https://issues.apache.org/jira/browse/IGNITE-10011 Project: Ignite Issue Type: Bug Components: persistence Reporter: Ilya Kasnacheev Attachments: Main.java See the attached Main which adds 500k records to 3 caches, then clears them, rinse, repeat. When ran with default settings, totalAllocatedSize will slowly double over the course of a few hours and then continue to grow. When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> 1800M -> etc. See the userlist discussion -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663920#comment-16663920
]
ASF GitHub Bot commented on IGNITE-10003:
-
GitHub user andrey-kuznetsov opened a pull request:
https://github.com/apache/ignite/pull/5084
IGNITE-10003 Changed checkpointReadLock timeout failure type.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andrey-kuznetsov/ignite ignite-10003
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5084.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 #5084
commit 61b26e4004bf70d40e8aae55422c8e60e11761ac
Author: Andrey Kuznetsov
Date: 2018-10-25T15:34:02Z
IGNITE-10003 Changed checkpointReadLock timeout failure type.
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8873) Optimize cache scans with enabled persistence.
[
https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663918#comment-16663918
]
Alexei Scherbakov commented on IGNITE-8873:
---
[~agoncharuk],
1) The main use case for this method is preloading for iteration using scan or
sql query over partition which is almost always done over primary partition.
Backup partitions are not intended for use from public API, so I do not think
it's necessary to preload backups.
I've added {{preloadPartitionLocal}} method as you suggested which could be
used for preloading of any local partition. By combining compute API and this
method backup partition can be preloaded if needed.
2) Done
3) Done. Added two new tests {{testPreloadPartitionInMemoryRemote,
testPreloadPartitionInMemoryLocal}}
Please review.
> Optimize cache scans with enabled persistence.
> --
>
> Key: IGNITE-8873
> URL: https://issues.apache.org/jira/browse/IGNITE-8873
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> Currently cache scans with enabled persistence involve link resolution, which
> can lead to radom disk access resulting in bad performace on SAS disks.
> One possibility is to preload cache data pages to remove slow random disk
> access.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9543) MVCC TX: Add Mvcc atomicity mode to ConfigVariations tests when full cache API support is implemented.
[
https://issues.apache.org/jira/browse/IGNITE-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-9543:
-
Issue Type: Sub-task (was: Task)
Parent: IGNITE-10001
> MVCC TX: Add Mvcc atomicity mode to ConfigVariations tests when full cache
> API support is implemented.
> --
>
> Key: IGNITE-9543
> URL: https://issues.apache.org/jira/browse/IGNITE-9543
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
>
> We need to add {{TRANSACTIONAL_SNAPSHOT}} atomicity mode to
> {{ConfigVariations#BASIC_CACHE_SET}} when full Cache API support is
> implemented for MVCC caches (i.e. near/local caches, read/write through,
> etc.).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10004) Parse error leads to leave the transaction
[
https://issues.apache.org/jira/browse/IGNITE-10004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10004:
-
Fix Version/s: 2.7
> Parse error leads to leave the transaction
> --
>
> Key: IGNITE-10004
> URL: https://issues.apache.org/jira/browse/IGNITE-10004
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.7
>
>
> 1. Start 2 nodes + connect sqlline
> 2. Execute following queries:
> {noformat}
> create table t10 (a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";
> begin;
> insert into t10 values(1); <- worng set
> insert into t10 values(2, '2'); <- coorect set
> commit;
> {noformat}
> The output:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t10 (a int, b varchar, primary
> key(a)) with "ATOMICITY=TRANSACTIONAL_SNAP
> SHOT,backups=1";
> No rows affected (0,032 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t10 values(1);
> Error: Failed to parse query. ═хтхЁэюх ъюышўхёЄтю ёЄюысЎют
> Column count does not match; SQL statement:
> insert into t10 values(1) [21002-197] (state=42000,code=1001)
> java.sql.SQLException: Failed to parse query. Неверное количество столбцов
> Column count does not match; SQL statement:
> insert into t10 values(1) [21002-197]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t10 values(2, '2');
> Error: Transaction is already completed. (state=25000,code=5004)
> java.sql.SQLException: Transaction is already completed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9986) TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky
[ https://issues.apache.org/jira/browse/IGNITE-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663887#comment-16663887 ] ASF GitHub Bot commented on IGNITE-9986: GitHub user SomeFire opened a pull request: https://github.com/apache/ignite/pull/5082 IGNITE-9986 TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky You can merge this pull request into a Git repository by running: $ git pull https://github.com/SomeFire/ignite IGNITE-9986 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5082.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 #5082 commit ee440d25e252fc36cae7b13de89d27a0febbc6c0 Author: Dmitrii Ryabov Date: 2018-10-25T15:14:22Z IGNITE-9986 TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is flaky > TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished is > flaky > -- > > Key: IGNITE-9986 > URL: https://issues.apache.org/jira/browse/IGNITE-9986 > Project: Ignite > Issue Type: Bug >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > > [TeamCity > fails|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-6988766947783986136=TEST_STATUS_DESC=50_IgniteTests24Java8=]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov reassigned IGNITE-10003:
-
Assignee: Andrey Kuznetsov
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9997) IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663878#comment-16663878
]
ASF GitHub Bot commented on IGNITE-9997:
GitHub user NSAmelchev opened a pull request:
https://github.com/apache/ignite/pull/5081
IGNITE-9997
Fix IgniteDiagnosticMessagesTest.testLongRunningTx test.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/NSAmelchev/ignite ignite-9997
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5081.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 #5081
commit 4d742f1004f915b4f3a255823db7d307ac3df66d
Author: NSAmelchev
Date: 2018-10-25T15:12:00Z
Fix the test.
> IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
> --
>
> Key: IGNITE-9997
> URL: https://issues.apache.org/jira/browse/IGNITE-9997
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> It fails with the assertion error. [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2157923=buildResultsDiv=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic#testNameId808105671819833392]
> Log:
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.internal.managers.IgniteDiagnosticMessagesTest.testLongRunningTx(IgniteDiagnosticMessagesTest.java:378){noformat}
> {code:java}
> assertTrue(log.contains("Cache entries [cacheId=" +
> CU.cacheId(DEFAULT_CACHE_NAME) + ", cacheName=" + DEFAULT_CACHE_NAME + "]:"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10009) ODBC: SQLColumns does not work for tables with escape sequences in name
[
https://issues.apache.org/jira/browse/IGNITE-10009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663870#comment-16663870
]
ASF GitHub Bot commented on IGNITE-10009:
-
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/5080
IGNITE-10009: ODBC fix for escaped table names
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10009
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5080.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 #5080
commit 7b7dccc26aa0ab308c873df4a28e533ecb3357fe
Author: Igor Sapego
Date: 2018-10-25T15:10:57Z
IGNITE-10009: ODBC fix for escaped table names
> ODBC: SQLColumns does not work for tables with escape sequences in name
> ---
>
> Key: IGNITE-10009
> URL: https://issues.apache.org/jira/browse/IGNITE-10009
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.6
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.8
>
>
> Table names with escaped underscore '\_' or percent '\%' characters is not
> recognized by the ODBC driver. I.e. the following table pattern:
> {noformat}
> TEST\_TABLE
> {noformat}
> Should match the following table:
> {noformat}
> TEST_TABLE
> {noformat}
> But currently it does not. Needs to be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10010) Node halted if table was dropped
Sergey Kozlov created IGNITE-10010:
--
Summary: Node halted if table was dropped
Key: IGNITE-10010
URL: https://issues.apache.org/jira/browse/IGNITE-10010
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 2.7
1. Start 2 nodes with PDS
2. Activate cluster
3. Connect sqlline.
4. Create table {{create table t1(a int, b varchar, primary key(a)) with
"ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
5. Stop node 1
6. Drop table {{drop table t1;}}
7. Start node 1
8. Node 2 stopped by handler:
{noformat}
c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\ignite.bat server.xml -v -J-DID=1
Ignite Command Line Startup, ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
2018 Copyright(C) Apache Software Foundation
[18:04:22,745][INFO][main][IgniteKernal]
>>>__
>>> / _/ ___/ |/ / _/_ __/ __/
>>> _/ // (7 7// / / / / _/
>>> /___/\___/_/|_/___/ /_/ /___/
>>>
>>> ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
>>> 2018 Copyright(C) Apache Software Foundation
>>>
>>> Ignite documentation: http://ignite.apache.org
[18:04:22,745][INFO][main][IgniteKernal] Config URL:
file:/c:/Work/apache-ignite-2.7.0-SNAPSHOT-bin/server.xml
[18:04:22,760][INFO][main][IgniteKernal] IgniteConfiguration
[igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, cal
lbackPoolSize=8, stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4,
igfsPoolSize=8, dataStreamerPoolSize=8, utilityCacheP
oolSize=8, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
igniteHome=c:\Work\apache-ignite-2.7.0-SNAPSHO
T-bin, igniteWorkDir=c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin\work,
mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@6f94
fa3e, nodeId=d02069db-6d0b-4a40-b185-1d95fa330853, marsh=BinaryMarshaller [],
marshLocJobs=false, daemon=false, p2pEnabl
ed=false, netTimeout=5000, sndRetryDelay=1000, sndRetryCnt=3,
metricsHistSize=1, metricsUpdateFreq=2000, metricsExpT
ime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null,
sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10,
reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
clientReconnectDisabled=false, internalLsnr=null], segPlc=ST
OP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true,
segChkFreq=1, commSpi=TcpCommunicationSp
i [connectGate=null,
connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@22ff4249,
enableForcibleNodeKill=false, enableTroubleshootingLog=false, locAddr=null,
locHost=null, locPort=47100, locPortRange=1
00, shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
connTimeout=5000, maxConnTimeout=60, r
econCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, us
ePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true,
filterReachableAddresses=false, ackSndThreshold=32, una
ckedMsgsBufSize=0, sockWriteTimeout=2000, boundTcpPort=-1,
boundTcpShmemPort=-1, selectorsCnt=4, selectorSpins=0, addrRs
lvr=null, ctxInitLatch=java.util.concurrent.CountDownLatch@2d1ef81a[Count = 1],
stopping=false], evtSpi=org.apache.ignit
e.spi.eventstorage.NoopEventStorageSpi@4c402120, colSpi=NoopCollisionSpi [],
deploySpi=LocalDeploymentSpi [], indexingSp
i=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@815b41f, addrRslvr=null,
encryptionSpi=org.apache.ignite.spi.encry
ption.noop.NoopEncryptionSpi@5542c4ed, clientMode=false,
rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration [txSe
rEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC,
dfltTxTimeout=0, txTimeoutOnPartitionMapExch
ange=0, pessimisticTxLogSize=0, pessimisticTxLogLinger=1,
tmLookupClsName=null, txManagerFactory=null, useJtaSync=fa
lse], cacheSanityCheckEnabled=true, discoStartupDelay=6, deployMode=SHARED,
p2pMissedCacheSize=100, locHost=127.0.0.
1, timeSrvPortBase=31100, timeSrvPortRange=100, failureDetectionTimeout=1,
sysWorkerBlockedTimeout=null, clientFailu
reDetectionTimeout=3, metricsLogFreq=6, hadoopCfg=null,
connectorCfg=ConnectorConfiguration [jettyPath=null, hos
t=null, port=11211, noDelay=true, directBuf=false, sndBufSize=32768,
rcvBufSize=32768, idleQryCurTimeout=60, idleQry
CurCheckFreq=6, sndQueueLimit=0, selectorCnt=4, idleTimeout=7000,
sslEnabled=false, sslClientAuth=false, sslCtxFacto
ry=null, sslFactory=null, portRange=100, threadPoolSize=8,
msgInterceptor=null], odbcCfg=null, warmupClos=null, atomicCf
g=AtomicConfiguration [seqReserveSize=1000, cacheMode=PARTITIONED, backups=1,
aff=null, grpName=null], classLdr=null, ss
lCtxFactory=null, platformCfg=null, binaryCfg=BinaryConfiguration
[idMapper=null, nameMapper=null, serializer=null, comp
actFooter=true], memCfg=null, pstCfg=null, dsCfg=DataStorageConfiguration
[sysRegionInitSize=52428800,
[jira] [Created] (IGNITE-10009) ODBC: SQLColumns does not work for tables with escape sequences in name
Igor Sapego created IGNITE-10009:
Summary: ODBC: SQLColumns does not work for tables with escape
sequences in name
Key: IGNITE-10009
URL: https://issues.apache.org/jira/browse/IGNITE-10009
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 2.6
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.8
Table names with escaped underscore '\_' or percent '\%' characters is not
recognized by the ODBC driver. I.e. the following table pattern:
{noformat}
TEST\_TABLE
{noformat}
Should match the following table:
{noformat}
TEST_TABLE
{noformat}
But currently it does not. Needs to be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10008) Need to investigate why these tests is failed after consistentID set
Alexey Platonov created IGNITE-10008: Summary: Need to investigate why these tests is failed after consistentID set Key: IGNITE-10008 URL: https://issues.apache.org/jira/browse/IGNITE-10008 Project: Ignite Issue Type: Bug Reporter: Alexey Platonov In these test method setConsistentID is overridden because setting of consistentID to nodes will let fail them: JdbcDistributedJoinsQueryTest GridCacheAbstractMetricsSelfTest IgniteCacheContinuousQueryNoUnsubscribeTest IgniteBinaryObjectFieldsQuerySelfTest IgniteSqlSkipReducerOnUpdateDmlSelfTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10007) Deactivation hangs if an open transaction exists
Sergey Kozlov created IGNITE-10007:
--
Summary: Deactivation hangs if an open transaction exists
Key: IGNITE-10007
URL: https://issues.apache.org/jira/browse/IGNITE-10007
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Sergey Kozlov
Fix For: 2.7
1. Start 2 node with PDS
2. Activate cluster
3. Connect sqlline
4. Create table {{create table t1(a int, b varchar, primary key(a)) with
"ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
3.Start TX and execute a DML commnd:
{noformat}
begin;
insert into t1 values (1, '1');
{noformat}
4. Try deactivate cluster {{bin/control.bat --deactivate}}. The scripts doesn't
return control.
5. Show LRT:
{noformat}
c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
2018 Copyright(C) Apache Software Foundation
User:
Matching transactions:
TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
order=1, ver=2.7.0#19700101-sha1:,
isClient=false, consistentId=1]
Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
state=ACTIVE, startTime=2018-10-25 17:34:35.5
22, duration=352, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
topVer=AffinityTopologyVersion [topVer=2, minorTop
Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
[5d3e8936]]
{noformat}
6. Complete TX:
{noformat}
0: jdbc:ignite:thin://127.0.0.1/> commit;
Error: class org.apache.ignite.IgniteException: Can not perform the operation
because the cluster is inactive. Note, tha
t the cluster is considered inactive by default if Ignite Persistent Store is
used to let all the nodes join the cluster
. To activate the cluster call Ignite.active(true). (state=5,code=1)
java.sql.SQLException: class org.apache.ignite.IgniteException: Can not perform
the operation because the cluster is ina
ctive. Note, that the cluster is considered inactive by default if Ignite
Persistent Store is used to let all the nodes
join the cluster. To activate the cluster call Ignite.active(true).
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
0: jdbc:ignite:thin://127.0.0.1/>
{noformat}
It.s ok but LRT is still presented and deactivation script doesn't return
control back to user:
{noformat}
c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
2018 Copyright(C) Apache Software Foundation
User:
Matching transactions:
TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
order=1, ver=2.7.0#19700101-sha1:,
isClient=false, consistentId=1]
Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
state=ACTIVE, startTime=2018-10-25 17:34:35.5
22, duration=510, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
topVer=AffinityTopologyVersion [topVer=2, minorTop
Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
[5d3e8936]]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10005) SQL table catalog documentation
[
https://issues.apache.org/jira/browse/IGNITE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10005:
-
Description:
When IGNITE-3467 is done, we need to add few words about possible catalog
tables catalog name.
What we need to document:
1) Thre are no tables/indexes without catalog (tables which catalog is equal to
empty string {{""}}, not null!).
2) The only possible catalog for tables is "IGNITE".
was:
When IGNITE-3467 is done, we need to add few words about possible catalog
tables catalog name.
What we need to document:
1) Thre are no tables without catalog (tables which catalog is equal to empty
string {{""}}, not null!).
2) The only possible catalog for tables is "IGNITE".
> SQL table catalog documentation
> ---
>
> Key: IGNITE-10005
> URL: https://issues.apache.org/jira/browse/IGNITE-10005
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> When IGNITE-3467 is done, we need to add few words about possible catalog
> tables catalog name.
> What we need to document:
> 1) Thre are no tables/indexes without catalog (tables which catalog is equal
> to empty string {{""}}, not null!).
> 2) The only possible catalog for tables is "IGNITE".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9982) SQLLine: can't run with option --autoCommit=false or true
[
https://issues.apache.org/jira/browse/IGNITE-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-9982:
--
Assignee: Ivan Pavlukhin
> SQLLine: can't run with option --autoCommit=false or true
> -
>
> Key: IGNITE-9982
> URL: https://issues.apache.org/jira/browse/IGNITE-9982
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> Trying to run sqlline with additional options
> {code}
> $ /bin/sqlline.sh --autoCommit=false --color=true --outputFormat=csv
> --showNestedErrs=true --showWarnings=true --verbose=true -u
> jdbc:ignite:thin://127.0.0.1:10800
> {code}
> SQLline is working but with exception on start:
> {code}
> issuing: !connect jdbc:ignite:thin://127.0.0.1:10800 '' ''
> org.apache.ignite.IgniteJdbcThinDriver
> Connecting to jdbc:ignite:thin://127.0.0.1:10800
> Connected to: Apache Ignite (version 2.7.1#20181023-sha1:0ccde7c4)
> Driver: Apache Ignite Thin JDBC Driver (version 2.7.1#20181023-sha1:0ccde7c4)
> Error: MVCC must be enabled in order to invoke transactional operation:
> COMMIT (state=25000,code=5002)
> java.sql.SQLException: MVCC must be enabled in order to invoke transactional
> operation: COMMIT
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.doCommit(JdbcThinConnection.java:369)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.setAutoCommit(JdbcThinConnection.java:328)
> at sqlline.DatabaseConnection.connect(DatabaseConnection.java:178)
> at
> sqlline.DatabaseConnection.getConnection(DatabaseConnection.java:204)
> at sqlline.Commands.connect(Commands.java:1095)
> at sqlline.Commands.connect(Commands.java:1001)
> 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
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:566)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> Transaction isolation: TRANSACTION_REPEATABLE_READ
> {code}
> Without --autoCommit option sqlline running without this exception
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9959) Set consistent id in tests
[
https://issues.apache.org/jira/browse/IGNITE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663818#comment-16663818
]
Ignite TC Bot commented on IGNITE-9959:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2138564buildTypeId=IgniteTests24Java8_RunAll]
> Set consistent id in tests
> --
>
> Key: IGNITE-9959
> URL: https://issues.apache.org/jira/browse/IGNITE-9959
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> We need to set consistent id for starting nodes in tests
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
[
https://issues.apache.org/jira/browse/IGNITE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-10003:
--
Issue Type: Task (was: Bug)
> Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read
> lock timeout detected
>
>
> Key: IGNITE-10003
> URL: https://issues.apache.org/jira/browse/IGNITE-10003
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> {{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
> {{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
> default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10002) MVCC: Create "Cache 2" test suite for MVCC mode.
[ https://issues.apache.org/jira/browse/IGNITE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10002: - Assignee: Andrew Mashenkov > MVCC: Create "Cache 2" test suite for MVCC mode. > > > Key: IGNITE-10002 > URL: https://issues.apache.org/jira/browse/IGNITE-10002 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Create MVCC version of IgniteCacheTestSuite2 and add it to TC. > All non-relevant tests should be marked as ignored. > Failed tests should be muted and tickets should be created for unknown > failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10005) SQL table catalog documentation
[
https://issues.apache.org/jira/browse/IGNITE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663811#comment-16663811
]
Pavel Kuznetsov commented on IGNITE-10005:
--
This ticket depends on IGNITE-3467
> SQL table catalog documentation
> ---
>
> Key: IGNITE-10005
> URL: https://issues.apache.org/jira/browse/IGNITE-10005
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> When IGNITE-3467 is done, we need to add few words about possible catalog
> tables catalog name.
> What we need to document:
> 1) Thre are no tables without catalog (tables which catalog is equal to empty
> string {{""}}, not null!).
> 2) The only possible catalog for tables is "IGNITE".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10001) MVCC: Make existed tests run in MVCC mode as well.
[ https://issues.apache.org/jira/browse/IGNITE-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10001: -- Description: This is umbrella ticket. We should add MVCC mode to all relevant existed tests, as MVCC is a new feature and integrations with other features haven't tested yet. Let's add separate suite with mvcc mode for each existed one at first and mute non-relevant and failed tests. (This way will not affects current tests TC statistics and will not broke current TC runs) Then we will be able to rearrange and\or refactor existed tests to add MVCC mode to tests properly. > MVCC: Make existed tests run in MVCC mode as well. > -- > > Key: IGNITE-10001 > URL: https://issues.apache.org/jira/browse/IGNITE-10001 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > This is umbrella ticket. > We should add MVCC mode to all relevant existed tests, as MVCC is a new > feature and integrations with other features haven't tested yet. > Let's add separate suite with mvcc mode for each existed one at first and > mute non-relevant and failed tests. > (This way will not affects current tests TC statistics and will not broke > current TC runs) > Then we will be able to rearrange and\or refactor existed tests to add MVCC > mode to tests properly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10005) SQL table catalog documentation
Pavel Kuznetsov created IGNITE-10005:
Summary: SQL table catalog documentation
Key: IGNITE-10005
URL: https://issues.apache.org/jira/browse/IGNITE-10005
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Pavel Kuznetsov
When IGNITE-3467 is done, we need to add few words about possible catalog
tables catalog name.
What we need to document:
1) Thre are no tables without catalog (tables which catalog is equal to empty
string {{""}}, not null!).
2) The only possible catalog for tables is "IGNITE".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10004) Parse error leads to leave the transaction
Sergey Kozlov created IGNITE-10004:
--
Summary: Parse error leads to leave the transaction
Key: IGNITE-10004
URL: https://issues.apache.org/jira/browse/IGNITE-10004
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Sergey Kozlov
1. Start 2 nodes + connect sqlline
2. Execute following queries:
{noformat}
create table t10 (a int, b varchar, primary key(a)) with
"ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";
begin;
insert into t10 values(1); <- worng set
insert into t10 values(2, '2'); <- coorect set
commit;
{noformat}
The output:
{noformat}
0: jdbc:ignite:thin://127.0.0.1/> create table t10 (a int, b varchar, primary
key(a)) with "ATOMICITY=TRANSACTIONAL_SNAP
SHOT,backups=1";
No rows affected (0,032 seconds)
0: jdbc:ignite:thin://127.0.0.1/> begin;
No rows affected (0 seconds)
0: jdbc:ignite:thin://127.0.0.1/> insert into t10 values(1);
Error: Failed to parse query. ═хтхЁэюх ъюышўхёЄтю ёЄюысЎют
Column count does not match; SQL statement:
insert into t10 values(1) [21002-197] (state=42000,code=1001)
java.sql.SQLException: Failed to parse query. Неверное количество столбцов
Column count does not match; SQL statement:
insert into t10 values(1) [21002-197]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
0: jdbc:ignite:thin://127.0.0.1/> insert into t10 values(2, '2');
Error: Transaction is already completed. (state=25000,code=5004)
java.sql.SQLException: Transaction is already completed.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10003) Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR when checkpoint read lock timeout detected
Andrey Kuznetsov created IGNITE-10003:
-
Summary: Raise SYSTEM_WORKER_BLOCKED instead of CRITICAL_ERROR
when checkpoint read lock timeout detected
Key: IGNITE-10003
URL: https://issues.apache.org/jira/browse/IGNITE-10003
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Andrey Kuznetsov
Fix For: 2.8
{{GridCacheDatabaseSharedManager#failCheckpointReadLock}} should report
{{SYSTEM_WORKER_BLOCKED}} to failure handler: it is closer to the truth and
default consequenses are not so severe as opposed to {{CRITICAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10002) MVCC: Create "Cache 2" test suite for MVCC mode.
Andrew Mashenkov created IGNITE-10002: - Summary: MVCC: Create "Cache 2" test suite for MVCC mode. Key: IGNITE-10002 URL: https://issues.apache.org/jira/browse/IGNITE-10002 Project: Ignite Issue Type: Sub-task Components: mvcc Reporter: Andrew Mashenkov Create MVCC version of IgniteCacheTestSuite2 and add it to TC. All non-relevant tests should be marked as ignored. Failed tests should be muted and tickets should be created for unknown failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10001) MVCC: Make existed tests run in MVCC mode as well.
Andrew Mashenkov created IGNITE-10001: - Summary: MVCC: Make existed tests run in MVCC mode as well. Key: IGNITE-10001 URL: https://issues.apache.org/jira/browse/IGNITE-10001 Project: Ignite Issue Type: Task Components: mvcc Reporter: Andrew Mashenkov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9428) MVCC TX: MvccQueryTrackerImpl.onDone() semantic is broken.
[
https://issues.apache.org/jira/browse/IGNITE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-9428:
Assignee: (was: Andrew Mashenkov)
> MVCC TX: MvccQueryTrackerImpl.onDone() semantic is broken.
> --
>
> Key: IGNITE-9428
> URL: https://issues.apache.org/jira/browse/IGNITE-9428
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
> Fix For: 2.8
>
>
> Due to IGNITE-9256 patch, multiple {{H2ResultSetIterator#onClose}} invocation
> becomes possible. This can be considered as a {{Closable}} contract violation
> and should be fixed.
> Also this case revealed a bug in {{MvccQueryTrackerImpl}} when multiple
> {{onDone()}} call leads to multiple query finished acks sent back to the
> {{MvccCoordinator}} which leads to the problems with the query tracking and
> assertion errors.
> Reproducer:
> {{CacheMvccSqlTxQueriesAbstractTest#testAccountsTxDmlSumSql_WithRemoves_SingleNode}}
>
>
> Upd: test was fixed in IGNITE-9373. But MvccQueryTrackerImpl.onDone() issue
> is still actual.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9999) Add verbose logging for node recovery
[ https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-: - Description: Sometimes we see some difficulties in understanding which state a node is after a binary recovery and what state it has after applying all logical records from WAL. We need to add more information on the state of partitions (update counter, size, maybe more additional info) after the binary recovery (can be validated against checkpoint records) and after logical recovery (can help to validate the correctness of rebalance). > Add verbose logging for node recovery > - > > Key: IGNITE- > URL: https://issues.apache.org/jira/browse/IGNITE- > Project: Ignite > Issue Type: Task >Reporter: Alexey Goncharuk >Priority: Major > > Sometimes we see some difficulties in understanding which state a node is > after a binary recovery and what state it has after applying all logical > records from WAL. > We need to add more information on the state of partitions (update counter, > size, maybe more additional info) after the binary recovery (can be validated > against checkpoint records) and after logical recovery (can help to validate > the correctness of rebalance). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9780) SQL system view for cache groups
[
https://issues.apache.org/jira/browse/IGNITE-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663766#comment-16663766
]
ASF GitHub Bot commented on IGNITE-9780:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4985
> SQL system view for cache groups
>
>
> Key: IGNITE-9780
> URL: https://issues.apache.org/jira/browse/IGNITE-9780
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-13
> Fix For: 2.8
>
>
> Implement SQL system view to show list of cache groups.
> View must contain information: cache group id, cache group name, caches
> count, and attributes related to cache group from CacheConfiguration (at
> least attributes checked in
> {{ClusterCachesInfo#validateCacheGroupConfiguration()}} method)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10000) Document IGNITE.CACHE_GROUPS view
Vladimir Ozerov created IGNITE-1: Summary: Document IGNITE.CACHE_GROUPS view Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 New SQL view was introduced in IGNITE-9780. It lists cluster cache groups. Most fields are self-descriptive, their names and data types could be found in the code [1]. [1] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sys/view/SqlSystemViewCacheGroups.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9999) Add verbose logging for node recovery
Alexey Goncharuk created IGNITE-: Summary: Add verbose logging for node recovery Key: IGNITE- URL: https://issues.apache.org/jira/browse/IGNITE- Project: Ignite Issue Type: Task Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9990) Control.sh utility should request a password if necessary.
[
https://issues.apache.org/jira/browse/IGNITE-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663750#comment-16663750
]
ASF GitHub Bot commented on IGNITE-9990:
GitHub user a-polyakov opened a pull request:
https://github.com/apache/ignite/pull/5079
IGNITE-9990 Control.sh utility should request a password if necessary.
Signed-off-by: a-polyakov
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/a-polyakov/ignite IGNITE-9990
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5079.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 #5079
commit 538d3d2ef924a5ad8f653c3d0c37397eec405da7
Author: a-polyakov
Date: 2018-10-25T13:46:44Z
IGNITE-9990 Control.sh utility should request a password if necessary.
Signed-off-by: a-polyakov
> Control.sh utility should request a password if necessary.
> --
>
> Key: IGNITE-9990
> URL: https://issues.apache.org/jira/browse/IGNITE-9990
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Assignee: Alexand Polyakov
>Priority: Major
> Labels: security
>
> Since password in line parameters may not be safe (stored in console history
> in open form).
> Use hidden input
> {code:java}
> Console console = System.console();
> char passwordArray[] = console.readPassword("password: ");
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9780) SQL system view for cache groups
[
https://issues.apache.org/jira/browse/IGNITE-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9780:
Fix Version/s: 2.8
> SQL system view for cache groups
>
>
> Key: IGNITE-9780
> URL: https://issues.apache.org/jira/browse/IGNITE-9780
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: iep-13
> Fix For: 2.8
>
>
> Implement SQL system view to show list of cache groups.
> View must contain information: cache group id, cache group name, caches
> count, and attributes related to cache group from CacheConfiguration (at
> least attributes checked in
> {{ClusterCachesInfo#validateCacheGroupConfiguration()}} method)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9673) Timeout in Java Client suite.
[
https://issues.apache.org/jira/browse/IGNITE-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663744#comment-16663744
]
Sergey Chugunov commented on IGNITE-9673:
-
[~NSAmelchev],
I'm OK with moving *makeResponse* call of all handlers from striped pool but
let's use REST executor service instead of system one:
*GridKernalContext::getRestExecutorService*.
Could you please make this change and run TC again to make sure deadlock won't
pop up again? If this is the case then please proceed with merging.
> Timeout in Java Client suite.
> -
>
> Key: IGNITE-9673
> URL: https://issues.apache.org/jira/browse/IGNITE-9673
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Attachments: ThreadDump.txt
>
>
> Example of timeout: [TC
> build|[https://ci.ignite.apache.org/viewLog.html?buildId=1919405=buildResultsDiv=IgniteTests24Java8_JavaClient].]
> The possible reason is non-interruptable future and starvation in stripped
> pool:
> {noformat}
> "test-runner-#2440%redis.RedisProtocolStringSelfTest%" #3843 prio=5 os_prio=0
> tid=0x7f8f053fb000 nid=0x7b19 waiting on condition [0x7f8d74f8f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2465)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2463)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4228)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2463)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2444)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2421)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1089)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.RedisProtocolStringSelfTest.testStrlen(RedisProtocolStringSelfTest.java:310)
> 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)
> [grid-timeout-worker-#2323%redis.RedisProtocolStringSelfTest0%][G] >>>
> Possible starvation in striped pool.
> Thread name: sys-stripe-3-#2304%redis.RedisProtocolStringSelfTest0%
> Queue: [Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE,
> topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false,
> msg=GridCacheIdMessage [cacheId=1481046058]GridDistributedBaseMessage
> [ver=GridCacheVersion [topVer=148979816, order=1537499815759, nodeOrder=1],
> committedVers=ArrayList [], rolledbackVers=ArrayList [], cnt=0,
> super=]GridDistributedLockResponse
> [futId=e739f1af561-9bc10183-74c7-4b9a-a525-aef32c002efc, err=null,
> vals=ArrayList [null], super=]GridNearLockResponse [pending=ArrayList [],
> miniId=1, dhtVers=GridCacheVersion[] [GridCacheVersion [topVer=0, order=0,
> nodeOrder=0]], mappedVers=GridCacheVersion[] [GridCacheVersion
> [topVer=148979816, order=1537499815760, nodeOrder=2]], clientRemapVer=null,
> super=]]], Message closure [msg=GridIoMessage [plc=2, topic=TOPIC_CACHE,
> topicOrd=8, ordered=false, timeout=0, skipOnTimeout=false,
> msg=GridDistributedTxFinishResponse [txId=GridCacheVersion [topVer=148979816,
> order=1537499815765, nodeOrder=1],
> futId=e849f1af561-9bc10183-74c7-4b9a-a525-aef32c002efc,
> part=-1]GridNearTxFinishResponse [err=null, miniId=1, nearThreadId=3843,
> super=
> Deadlock: false
[jira] [Reopened] (IGNITE-9791) Document: SQL query lazy mode is used by default
[
https://issues.apache.org/jira/browse/IGNITE-9791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reopened IGNITE-9791:
--
Please revert documentation changes because IGNITE-9171 is reverted and moved
to 2.8.
> Document: SQL query lazy mode is used by default
>
>
> Key: IGNITE-9791
> URL: https://issues.apache.org/jira/browse/IGNITE-9791
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> We need to document changes in 'lazy' mode SQL query execution:
> - since Ignite 2.7 the lazy mode is ON by default and user should use
> explicit {{lazy=false}} to disable it.
> - but for JDBC, ODBC drivers and thin clients with version less than 2.7 lazy
> mode is false by default because the the default value is kept on the client
> side too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9963) Tests with mvn command invocation failed if path to M2_HOME contains spaces.
[
https://issues.apache.org/jira/browse/IGNITE-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov closed IGNITE-9963.
--
> Tests with mvn command invocation failed if path to M2_HOME contains spaces.
>
>
> Key: IGNITE-9963
> URL: https://issues.apache.org/jira/browse/IGNITE-9963
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: windows
>
> If path to M2_HOME contains spaces, tests with mvn invocation are failed with
> following exception:
> {code}
> Command='C:\Program Files\apache-maven-3.5.4/bin/mvn help:effective-settings'
> couldn't be executed: 'C:\Program' is not recognized as an internal or
> external command, operable program or batch file. UTF-8 java.lang.Exception:
> Abnormal exit value of 1 for pid 4652 [2018-10-22 14:49:28,032][INFO
> ][main][root] >>> Stopping test:
> PersistenceBasicCompatibilityTest#testNodeStartByOldVersionPersistenceData_2_1
> in 968 ms <<< [2018-10-22 14:49:28,028][ERROR][main][root] Test failed.
> java.lang.Exception: Abnormal exit value of 1 for pid 4652 at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.exec(MavenUtils.java:191)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.defineMavenLocalRepositoryPath(MavenUtils.java:132)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.getMavenLocalRepositoryPath(MavenUtils.java:120)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.getPathToArtifact(MavenUtils.java:101)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.getPathToIgniteArtifact(MavenUtils.java:70)
> at
> org.apache.ignite.compatibility.testframework.junits.IgniteCompatibilityAbstractTest$1.filteredJvmArgs(IgniteCompatibilityAbstractTest.java:186)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy.(IgniteProcessProxy.java:173)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy.(IgniteProcessProxy.java:148)
> at
> org.apache.ignite.compatibility.testframework.junits.IgniteCompatibilityAbstractTest$1.(IgniteCompatibilityAbstractTest.java:143)
> at
> org.apache.ignite.compatibility.testframework.junits.IgniteCompatibilityAbstractTest.startGrid(IgniteCompatibilityAbstractTest.java:143)
> at
> org.apache.ignite.compatibility.testframework.junits.IgniteCompatibilityAbstractTest.startGrid(IgniteCompatibilityAbstractTest.java:116)
> at
> org.apache.ignite.compatibility.persistence.PersistenceBasicCompatibilityTest.doTestStartupWithOldVersion(PersistenceBasicCompatibilityTest.java:113)
> at
> org.apache.ignite.compatibility.persistence.PersistenceBasicCompatibilityTest.doTestStartupWithOldVersion(PersistenceBasicCompatibilityTest.java:139)
> at
> org.apache.ignite.compatibility.persistence.PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_1(PersistenceBasicCompatibilityTest.java:89)
> 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:2176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:142)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2091)
> at java.lang.Thread.run(Thread.java:748) java.lang.Exception: Abnormal exit
> value of 1 for pid 4652 at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.exec(MavenUtils.java:191)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.defineMavenLocalRepositoryPath(MavenUtils.java:132)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.getMavenLocalRepositoryPath(MavenUtils.java:120)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.getPathToArtifact(MavenUtils.java:101)
> at
> org.apache.ignite.compatibility.testframework.util.MavenUtils.getPathToIgniteArtifact(MavenUtils.java:70)
> at
> org.apache.ignite.compatibility.testframework.junits.IgniteCompatibilityAbstractTest$1.filteredJvmArgs(IgniteCompatibilityAbstractTest.java:186)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy.(IgniteProcessProxy.java:173)
> at
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy.(IgniteProcessProxy.java:148)
> at
>
[jira] [Commented] (IGNITE-9959) Set consistent id in tests
[
https://issues.apache.org/jira/browse/IGNITE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663734#comment-16663734
]
Ignite TC Bot commented on IGNITE-9959:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2138564buildTypeId=IgniteTests24Java8_RunAll]
> Set consistent id in tests
> --
>
> Key: IGNITE-9959
> URL: https://issues.apache.org/jira/browse/IGNITE-9959
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> We need to set consistent id for starting nodes in tests
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9864) CacheQueriesTest test fails in .NET
[ https://issues.apache.org/jira/browse/IGNITE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov resolved IGNITE-9864. -- Resolution: Duplicate This case must be fixed by new patch of the IGNITE-9171. > CacheQueriesTest test fails in .NET > --- > > Key: IGNITE-9864 > URL: https://issues.apache.org/jira/browse/IGNITE-9864 > Project: Ignite > Issue Type: Bug > Components: platforms, sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8331) SQL: Add Decimal precision and scale constraint
[ https://issues.apache.org/jira/browse/IGNITE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663724#comment-16663724 ] Vladimir Ozerov commented on IGNITE-8331: - [~NIzhikov], my only concern was test coverage. So if it is extended sufficiently, I have no more comments. > SQL: Add Decimal precision and scale constraint > --- > > Key: IGNITE-8331 > URL: https://issues.apache.org/jira/browse/IGNITE-8331 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: PetrovMikhail >Priority: Major > Labels: sql-engine > > We should support DECIMAL(X, Y) syntax. > Currently, we ignore it. > It affects semantics. > E.g., one can insert a DECIMAL with greater precision into a cache/table > without any problems. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9997) IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663723#comment-16663723
]
Amelchev Nikita commented on IGNITE-9997:
-
[~zstan], Hi,
the error can be reproduced locally. I'll investigate this issue. Moreover,
deprecated GridStringLogger should be replaced with the ListeningLogger.
> IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
> --
>
> Key: IGNITE-9997
> URL: https://issues.apache.org/jira/browse/IGNITE-9997
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> It fails with the assertion error. [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2157923=buildResultsDiv=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic#testNameId808105671819833392]
> Log:
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.internal.managers.IgniteDiagnosticMessagesTest.testLongRunningTx(IgniteDiagnosticMessagesTest.java:378){noformat}
> {code:java}
> assertTrue(log.contains("Cache entries [cacheId=" +
> CU.cacheId(DEFAULT_CACHE_NAME) + ", cacheName=" + DEFAULT_CACHE_NAME + "]:"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-9165:
--
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2155730]]
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2155732]]
* dll: CachePartitionedTest.TestEnumerators - 3,1% fails in last 100 master
runs.
* dll: CachePartitionedTest.TestLocalSize - 3,1% fails in last 100 master runs.
* dll: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* dll: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* dll: CacheQueriesTestSimpleName.TestSqlFieldsQueryTimeout - 0,0% fails in
last 100 master runs.
* dll: CacheQueriesTestSimpleName.TestSqlQueryTimeout - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2067910buildTypeId=IgniteTests24Java8_RunAll])
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-9165:
--
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2155730]]
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2155732]]
* dll: CachePartitionedTest.TestEnumerators - 3,1% fails in last 100 master
runs.
* dll: CachePartitionedTest.TestLocalSize - 3,1% fails in last 100 master runs.
* dll: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* dll: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* dll: CacheQueriesTestSimpleName.TestSqlFieldsQueryTimeout - 0,0% fails in
last 100 master runs.
* dll: CacheQueriesTestSimpleName.TestSqlQueryTimeout - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2067910buildTypeId=IgniteTests24Java8_RunAll])
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8639) Query with a lot of nesting causes NPE in org.h2.util.StringUtils.indent
[
https://issues.apache.org/jira/browse/IGNITE-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663717#comment-16663717
]
Taras Ledkov commented on IGNITE-8639:
--
[~vozerov], great comment. I move the force persistence disable to the top of
the {{createTable}} method.
We need in this change because CTE table is created with {{persistData==true}}.
> Query with a lot of nesting causes NPE in org.h2.util.StringUtils.indent
>
>
> Key: IGNITE-8639
> URL: https://issues.apache.org/jira/browse/IGNITE-8639
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: test
> Fix For: 2.8
>
> Attachments: SqlNestedQuerySelfTest.java
>
>
> Worked in 1.7!
> But now:
> {code}
> sql("WITH cacheJoin (txId, stage, tStamp)" +
> " AS (SELECT t.txId, o.stage, o.tStamp FROM txs t INNER JOIN
> ops o ON t.txId = o.txId)" +
> " SELECT ou.stage, COUNT(*) as cou, SUM(CASE WHEN ou.stage =
> in.stage THEN 1 ELSE 0 END) AS ttl" +
> " FROM (SELECT txId, stage FROM cacheJoin cte GROUP BY txId,
> stage) ou" +
> " INNER JOIN (SELECT mx.txId, mx.stage FROM (SELECT txId,
> tStamp, stage FROM cacheJoin cte) mx" +
> " INNER JOIN (SELECT txId, MAX(tStamp) AS maxTStamp FROM
> cacheJoin cte GROUP BY txId) mix" +
> " ON mx.txId = mix.txId AND mx.tStamp = mix.maxTStamp) in
> ON ou.txId = in.txId" +
> " GROUP BY ou.stage");
> {code}
> {code}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to parse query. Внутренняя ошибка: "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException" [5-195]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2026)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1796)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1652)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1990)
> at
> org.apache.ignite.internal.processors.query.SqlNestedQuerySelfTest.sql(SqlNestedQuerySelfTest.java:73)
> at
> org.apache.ignite.internal.processors.query.SqlNestedQuerySelfTest.testNestingQuery(SqlNestedQuerySelfTest.java:54)
> 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:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.h2.jdbc.JdbcSQLException: Внутренняя ошибка:
> "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException" [5-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at org.h2.message.DbException.toSQLException(DbException.java:268)
> at org.h2.message.TraceObject.logAndConvert(TraceObject.java:352)
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:292)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepare0(IgniteH2Indexing.java:484)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:452)
> at
>
[jira] [Commented] (IGNITE-9753) Control.sh validate index work long and with errors
[
https://issues.apache.org/jira/browse/IGNITE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663712#comment-16663712
]
Ignite TC Bot commented on IGNITE-9753:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2160887buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh validate index work long and with errors
> ---
>
> Key: IGNITE-9753
> URL: https://issues.apache.org/jira/browse/IGNITE-9753
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: ARomantsov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.8
>
>
> Errors -
> [12:19:54][:666] IndexValidationIssue [key=null, cacheName=cache_name_1,
> idxName=_key_PK_hash], class java.lang.NullPointerException: null
> [12:19:54][:666] IndexValidationIssue [key=null, cacheName=cache_name_2,
> idxName=_key_PK_hash], class java.lang.NullPointerException: null
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9454) SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE
[ https://issues.apache.org/jira/browse/IGNITE-9454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663709#comment-16663709 ] Alexey Kukushkin commented on IGNITE-9454: -- [~ilyak], the fix looks good to me. > SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE > --- > > Key: IGNITE-9454 > URL: https://issues.apache.org/jira/browse/IGNITE-9454 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.5 >Reporter: Alexey Kukushkin >Assignee: Ilya Kasnacheev >Priority: Major > Labels: easyfix > > SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE, > CACHE_DESTROY and JOIN_AS_SERVER > +*Reproducer*+: > SecurityPermissionSetBuilder.create().appendSystemPermission(SecurityPermission.CACHE_CREATE) > The code above throw IgniteException saying that a security permission name > should begin with either EVENTS_ or ADMIN_ > *+Solution+:* > Update SecurityPermissionSetBuilder to: > # allow system permissions CACHE_CREATE, CACHE_DESTROY and JOIN_AS_SERVER > # restrict cache presmissions CACHE_CREATE, CACHE_DESTROY > # add automated tests > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663710#comment-16663710
]
PetrovMikhail commented on IGNITE-9165:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2155730]]
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2155732]]
* dll: CachePartitionedTest.TestEnumerators - 3,1% fails in last 100 master
runs.
* dll: CachePartitionedTest.TestLocalSize - 3,1% fails in last 100 master runs.
* dll: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* dll: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* dll: CacheQueriesTestSimpleName.TestSqlFieldsQueryTimeout - 0,0% fails in
last 100 master runs.
* dll: CacheQueriesTestSimpleName.TestSqlQueryTimeout - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2067910buildTypeId=IgniteTests24Java8_RunAll]
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-5689) IgniteCommunicationBalanceTest hangs on Windows
[
https://issues.apache.org/jira/browse/IGNITE-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov reassigned IGNITE-5689:
Assignee: Semen Boikov
> IgniteCommunicationBalanceTest hangs on Windows
> ---
>
> Key: IGNITE-5689
> URL: https://issues.apache.org/jira/browse/IGNITE-5689
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Semen Boikov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> Test runner is waiting for ComputeTask to finish:
> {noformat}
> "test-runner-#40602%communication.IgniteCommunicationBalanceMultipleConnectionsTest%"
> prio=6 tid=0x766d6000 nid=0x7934 waiting on condition
> [0xeacfe000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:315)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:176)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at
> org.apache.ignite.internal.AsyncSupportAdapter.saveOrGet(AsyncSupportAdapter.java:112)
> at
> org.apache.ignite.internal.IgniteComputeImpl.call(IgniteComputeImpl.java:785)
> at
> org.apache.ignite.internal.managers.communication.IgniteCommunicationBalanceTest$1.apply(IgniteCommunicationBalanceTest.java:158)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1603)
> at
> org.apache.ignite.internal.managers.communication.IgniteCommunicationBalanceTest.testBalance1(IgniteCommunicationBalanceTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1997)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1912)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> While thread that tried to send job result got stuck in
> IgniteUtils.reachable(...):
> {noformat}
> "pub-#40657%communication.IgniteCommunicationBalanceMultipleConnectionsTest5%"
> prio=6 tid=0x11b8 nid=0x3868 runnable [0xeecfe000]
>java.lang.Thread.State: RUNNABLE
> at java.net.Inet4AddressImpl.isReachable0(Native Method)
> at java.net.Inet4AddressImpl.isReachable(Inet4AddressImpl.java:70)
> at java.net.InetAddress.isReachable(InetAddress.java:475)
> at java.net.InetAddress.isReachable(InetAddress.java:434)
> at
> org.apache.ignite.internal.util.IgniteUtils.reachable(IgniteUtils.java:2113)
> at
> org.apache.ignite.internal.util.IgniteUtils.filterReachable(IgniteUtils.java:1877)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2955)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2763)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2655)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2516)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2480)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1643)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1715)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:928)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:773)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:625)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1181)
> at
>
[jira] [Commented] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663707#comment-16663707
]
PetrovMikhail commented on IGNITE-9165:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2155730]]
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2155732]]
* dll: CachePartitionedTest.TestEnumerators - 3,1% fails in last 100 master
runs.
* dll: CachePartitionedTest.TestLocalSize - 3,1% fails in last 100 master runs.
* dll: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* dll: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* dll: CacheQueriesTestSimpleName.TestSqlFieldsQueryTimeout - 0,0% fails in
last 100 master runs.
* dll: CacheQueriesTestSimpleName.TestSqlQueryTimeout - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run
All|http://ci.ignite.apache.org/viewLog.html?buildId=2067910buildTypeId=IgniteTests24Java8_RunAll]
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9786) MVCC: simplify TX wait list management
[ https://issues.apache.org/jira/browse/IGNITE-9786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663704#comment-16663704 ] Vladimir Ozerov commented on IGNITE-9786: - Re-run: https://ci.ignite.apache.org/viewQueued.html?itemId=2162968 > MVCC: simplify TX wait list management > -- > > Key: IGNITE-9786 > URL: https://issues.apache.org/jira/browse/IGNITE-9786 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > > It seems that instead of having a lot of classes and complex synchronization > mechanics for MvccProcessorImpl.waitMap, we can use single wrapper with a > list of waiters. > Resulting code will be much more simpler and less prone to concurrency issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9937) Primary response error info can be lost due to unwrapping a key
[
https://issues.apache.org/jira/browse/IGNITE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663706#comment-16663706
]
ASF GitHub Bot commented on IGNITE-9937:
GitHub user gromtech opened a pull request:
https://github.com/apache/ignite/pull/5078
IGNITE-9937 Primary response error can be lost due to unwrapping a key
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9937
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5078.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 #5078
commit e9d3827026bbd3f3c30c0a88f31a41528ecc200d
Author: Roman Guseinov
Date: 2018-10-25T12:52:52Z
IGNITE-9937 Primary response error can be lost due to unwrapping a key
> Primary response error info can be lost due to unwrapping a key
> ---
>
> Key: IGNITE-9937
> URL: https://issues.apache.org/jira/browse/IGNITE-9937
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>
> It can happen when we use SQL DDL to create a table or some dummy values for
> QueryEntity.keyType. Without using Cache API (only SQL), key and value should
> not be deserialized/unwrapped.
> If primary update error happens onPrimaryError call may try to unwrap keys,
> get ClassNotFoundException and hide the original error.
> Here is a stack trace example:
> {code:java}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> TestTableKey
>at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:706)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:797)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:404)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:416)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1832)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1633)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:812)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:664)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1067)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1065)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
>
[jira] [Commented] (IGNITE-7164) SQL TX: Remap protocol
[ https://issues.apache.org/jira/browse/IGNITE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663702#comment-16663702 ] ASF GitHub Bot commented on IGNITE-7164: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/5077 IGNITE-7164: SQL TX: Remap protocol You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7164 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5077.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 #5077 commit 576fbccece8862770d117ff3c3ca516004636fc0 Author: Andrey V. Mashenkov Date: 2018-10-24T14:16:02Z IGNITE-7164: Fix tx remap. commit 21b140a67018399fdef222fbb2d5437961c2c070 Author: Andrey V. Mashenkov Date: 2018-10-24T16:37:40Z IGNITE-7164: Fix tx remap. commit bcf621e3f0aba2b1ca6bda12d6a805a1fce2605a Author: Andrey V. Mashenkov Date: 2018-10-25T09:33:52Z IGNITE-7164: Minors. commit 07286cfe5f8080fdc8381508761ef29c0a9f4c5b Author: Andrey V. Mashenkov Date: 2018-10-25T09:33:52Z IGNITE-7164: Minors. commit d8b7fc48180810d513f8d284b53ec9664eacbcab Author: Andrey V. Mashenkov Date: 2018-10-25T12:23:05Z IGNITE-7164: Minors. Test added. commit 69b507e6239503bf6a8492927ffbd7d98aeb1180 Author: Andrey V. Mashenkov Date: 2018-10-25T12:36:37Z IGNITE-7164: Minors. Test added. commit 7a9a224fd5783a7708d6cc8793783e16bc523c7d Author: Andrey V. Mashenkov Date: 2018-10-25T12:48:18Z IGNITE-7164: Minors. > SQL TX: Remap protocol > -- > > Key: IGNITE-7164 > URL: https://issues.apache.org/jira/browse/IGNITE-7164 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Andrew Mashenkov >Priority: Major > > We need to provide remap protocol on topology changes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9884) Some tests are incorrectly muted
[
https://issues.apache.org/jira/browse/IGNITE-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663694#comment-16663694
]
Ignite TC Bot commented on IGNITE-9884:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests 0 TIMEOUT
, Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=2148955]]
* IgniteSqlSplitterSelfTest.testIndexSegmentationPartitionedReplicated (last
started)
{color:#d04437}Basic 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2148901]]
* GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange (last
started)
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2148896]]
* ZookeeperDiscoverySpiTestSuite2: GridEventConsumeSelfTest.testAllEvents -
0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2: GridEventConsumeSelfTest.testApiAsyncOld -
0,0% fails in last 100 master runs.
* ZookeeperDiscoverySpiTestSuite2:
GridEventConsumeSelfTest.testEventsByTypeAndFilter - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2148958buildTypeId=IgniteTests24Java8_RunAll]
> Some tests are incorrectly muted
>
>
> Key: IGNITE-9884
> URL: https://issues.apache.org/jira/browse/IGNITE-9884
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> The following tests pass when unmuted. It looks like the reasons that made
> them fail in the past were somehow resolved by later code changes but tests
> were forgotten to unmute:
> {panel}
> GridCacheStoreManagerDeserializationTest#_testBinaryStream
> IgniteCacheConfigVariationsFullApiTest#_testDeletedEntriesFlag
> IgniteCacheConfigVariationsFullApiTest#_testEvictExpired
> PageIdDistributionTest#_testRealHistory
> GridEventConsumeSelfTest#_testMultithreadedWithNodeRestart
> BPlusTreeSelfTest#_testBenchInvoke
> IgniteClientReconnectMassiveShutdownTest#_testMassiveServersShutdown1
> IgniteClientReconnectMassiveShutdownTest#_testMassiveServersShutdown3
> TcpDiscoveryMultiThreadedTest#_testMultiThreadedServersRestart
> GridServiceProcessorBatchDeploySelfTest#_testDeployAllTopologyChange
> GridServiceProcessorBatchDeploySelfTest#_testDeployAllTopologyChangeFail
> GridServiceProcessorBatchDeploySelfTest#_testCancelAllTopologyChange
> {panel}
> The following tests are muted by renaming (prefixing with underscore,
> {{_test...}}, should use standard muting by known JIRA tickets instead:
> {panel}
> - CacheMvccTransactionsTest#_testNodesRestartNoHang
> should fail with the reference to IGNITE-5935
> - GridCacheAbstractFullApiSelfTest#_testInvokeAllMultithreaded
> should fail with the reference to IGNITE-4380{panel}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail updated IGNITE-9165:
--
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2155730]]
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2155732]]
* dll: CachePartitionedTest.TestEnumerators - 3,6% fails in last 100 master
runs.
* dll: CachePartitionedTest.TestLocalSize - 3,6% fails in last 100 master runs.
* dll: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* dll: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* dll: CacheQueriesTestSimpleName.TestSqlFieldsQueryTimeout - 0,0% fails in
last 100 master runs.
* dll: CacheQueriesTestSimpleName.TestSqlQueryTimeout - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2067910buildTypeId=IgniteTests24Java8_RunAll])
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8873) Optimize cache scans with enabled persistence.
[
https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663690#comment-16663690
]
Alexey Goncharuk commented on IGNITE-8873:
--
[~ascherbakov], a few comments:
1) From the change I see that the method {{preloadPartition()}} is supposed to
be cluster-wide, however {{affinityRun}} will send the runnable only to one
node, instead of primary and backups. Is it how it is supposed to work? I think
it makes sense to preload both primary and backups. Also, should we add
{{preloadPartitionLocal()}} method which will not broadcast any jobs but
preload partition only if it exists locally?
2) Please add a proper javadoc to public API methods so a user understands what
they do and what drawbacks it may have on page memory and performance
3) I think the methods should throw/return failed future with an
{{IgniteException}} if the method is called on a non-persistent cache.
> Optimize cache scans with enabled persistence.
> --
>
> Key: IGNITE-8873
> URL: https://issues.apache.org/jira/browse/IGNITE-8873
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> Currently cache scans with enabled persistence involve link resolution, which
> can lead to radom disk access resulting in bad performace on SAS disks.
> One possibility is to preload cache data pages to remove slow random disk
> access.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9655) SQL: Create benchmark suite for DML operations.
[ https://issues.apache.org/jira/browse/IGNITE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663689#comment-16663689 ] ASF GitHub Bot commented on IGNITE-9655: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4821 > SQL: Create benchmark suite for DML operations. > --- > > Key: IGNITE-9655 > URL: https://issues.apache.org/jira/browse/IGNITE-9655 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > Create benchmark configuration that contains benchmark runs for DML > operations. > 1) insert + delete > 2) update (single, range -with-/without contention). > Currently we have benchmark code for 1 and 2 without contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9655) SQL: Create benchmark suite for DML operations.
[ https://issues.apache.org/jira/browse/IGNITE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9655: Component/s: yardstick > SQL: Create benchmark suite for DML operations. > --- > > Key: IGNITE-9655 > URL: https://issues.apache.org/jira/browse/IGNITE-9655 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > Create benchmark configuration that contains benchmark runs for DML > operations. > 1) insert + delete > 2) update (single, range -with-/without contention). > Currently we have benchmark code for 1 and 2 without contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9655) SQL: Create benchmark suite for DML operations.
[ https://issues.apache.org/jira/browse/IGNITE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9655: Ignite Flags: (was: Docs Required) > SQL: Create benchmark suite for DML operations. > --- > > Key: IGNITE-9655 > URL: https://issues.apache.org/jira/browse/IGNITE-9655 > Project: Ignite > Issue Type: Task >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > Create benchmark configuration that contains benchmark runs for DML > operations. > 1) insert + delete > 2) update (single, range -with-/without contention). > Currently we have benchmark code for 1 and 2 without contention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8639) Query with a lot of nesting causes NPE in org.h2.util.StringUtils.indent
[
https://issues.apache.org/jira/browse/IGNITE-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8639:
Fix Version/s: 2.8
> Query with a lot of nesting causes NPE in org.h2.util.StringUtils.indent
>
>
> Key: IGNITE-8639
> URL: https://issues.apache.org/jira/browse/IGNITE-8639
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: test
> Fix For: 2.8
>
> Attachments: SqlNestedQuerySelfTest.java
>
>
> Worked in 1.7!
> But now:
> {code}
> sql("WITH cacheJoin (txId, stage, tStamp)" +
> " AS (SELECT t.txId, o.stage, o.tStamp FROM txs t INNER JOIN
> ops o ON t.txId = o.txId)" +
> " SELECT ou.stage, COUNT(*) as cou, SUM(CASE WHEN ou.stage =
> in.stage THEN 1 ELSE 0 END) AS ttl" +
> " FROM (SELECT txId, stage FROM cacheJoin cte GROUP BY txId,
> stage) ou" +
> " INNER JOIN (SELECT mx.txId, mx.stage FROM (SELECT txId,
> tStamp, stage FROM cacheJoin cte) mx" +
> " INNER JOIN (SELECT txId, MAX(tStamp) AS maxTStamp FROM
> cacheJoin cte GROUP BY txId) mix" +
> " ON mx.txId = mix.txId AND mx.tStamp = mix.maxTStamp) in
> ON ou.txId = in.txId" +
> " GROUP BY ou.stage");
> {code}
> {code}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to parse query. Внутренняя ошибка: "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException" [5-195]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2026)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1796)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1652)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1990)
> at
> org.apache.ignite.internal.processors.query.SqlNestedQuerySelfTest.sql(SqlNestedQuerySelfTest.java:73)
> at
> org.apache.ignite.internal.processors.query.SqlNestedQuerySelfTest.testNestingQuery(SqlNestedQuerySelfTest.java:54)
> 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:2086)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2001)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.h2.jdbc.JdbcSQLException: Внутренняя ошибка:
> "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException" [5-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:168)
> at org.h2.message.DbException.convert(DbException.java:295)
> at org.h2.message.DbException.toSQLException(DbException.java:268)
> at org.h2.message.TraceObject.logAndConvert(TraceObject.java:352)
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:292)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepare0(IgniteH2Indexing.java:484)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:452)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:419)
> at
>
[jira] [Commented] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
[ https://issues.apache.org/jira/browse/IGNITE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663672#comment-16663672 ] Ilya Kasnacheev commented on IGNITE-9843: - [~agoncharuk] please review changes in binary > IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta > without losing data > -- > > Key: IGNITE-9843 > URL: https://issues.apache.org/jira/browse/IGNITE-9843 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.8 > > >
[jira] [Commented] (IGNITE-8873) Optimize cache scans with enabled persistence.
[ https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663670#comment-16663670 ] Alexei Scherbakov commented on IGNITE-8873: --- [~agoncharuk], Please review. > Optimize cache scans with enabled persistence. > -- > > Key: IGNITE-8873 > URL: https://issues.apache.org/jira/browse/IGNITE-8873 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > > Currently cache scans with enabled persistence involve link resolution, which > can lead to radom disk access resulting in bad performace on SAS disks. > One possibility is to preload cache data pages to remove slow random disk > access. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8873) Optimize cache scans with enabled persistence.
[
https://issues.apache.org/jira/browse/IGNITE-8873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663668#comment-16663668
]
Ignite TC Bot commented on IGNITE-8873:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2154428buildTypeId=IgniteTests24Java8_RunAll]
> Optimize cache scans with enabled persistence.
> --
>
> Key: IGNITE-8873
> URL: https://issues.apache.org/jira/browse/IGNITE-8873
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> Currently cache scans with enabled persistence involve link resolution, which
> can lead to radom disk access resulting in bad performace on SAS disks.
> One possibility is to preload cache data pages to remove slow random disk
> access.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9454) SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE
[ https://issues.apache.org/jira/browse/IGNITE-9454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663656#comment-16663656 ] Ilya Kasnacheev commented on IGNITE-9454: - [~kukushal] please review proposed fix. > SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE > --- > > Key: IGNITE-9454 > URL: https://issues.apache.org/jira/browse/IGNITE-9454 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.5 >Reporter: Alexey Kukushkin >Assignee: Ilya Kasnacheev >Priority: Major > Labels: easyfix > > SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE, > CACHE_DESTROY and JOIN_AS_SERVER > +*Reproducer*+: > SecurityPermissionSetBuilder.create().appendSystemPermission(SecurityPermission.CACHE_CREATE) > The code above throw IgniteException saying that a security permission name > should begin with either EVENTS_ or ADMIN_ > *+Solution+:* > Update SecurityPermissionSetBuilder to: > # allow system permissions CACHE_CREATE, CACHE_DESTROY and JOIN_AS_SERVER > # restrict cache presmissions CACHE_CREATE, CACHE_DESTROY > # add automated tests > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9997) IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
[
https://issues.apache.org/jira/browse/IGNITE-9997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663655#comment-16663655
]
Stanilovsky Evgeny commented on IGNITE-9997:
maybe need to log full message if assert fires?
> IgniteDiagnosticMessagesTest.testLongRunningTx fails on TC
> --
>
> Key: IGNITE-9997
> URL: https://issues.apache.org/jira/browse/IGNITE-9997
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> It fails with the assertion error. [Example of
> fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2157923=buildResultsDiv=IgniteTests24Java8_BinaryObjectsSimpleMapperBasic#testNameId808105671819833392]
> Log:
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.ignite.internal.managers.IgniteDiagnosticMessagesTest.testLongRunningTx(IgniteDiagnosticMessagesTest.java:378){noformat}
> {code:java}
> assertTrue(log.contains("Cache entries [cacheId=" +
> CU.cacheId(DEFAULT_CACHE_NAME) + ", cacheName=" + DEFAULT_CACHE_NAME + "]:"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9171) Use lazy mode with results pre-fetch
[
https://issues.apache.org/jira/browse/IGNITE-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663653#comment-16663653
]
ASF GitHub Bot commented on IGNITE-9171:
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/5076
IGNITE-9171 Use lazy mode with results pre-fetch
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9171
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5076.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 #5076
commit 044e1e51e6609e92ff46b0650ec8d69afb2b424d
Author: tledkov-gridgain
Date: 2018-10-23T09:10:02Z
IGNITE-9171: save the progress
commit 05ee7dba340395208ab040c7e13710433e44fe1e
Author: tledkov-gridgain
Date: 2018-10-24T13:22:02Z
IGNITE-9171: lazy mode performance optimization for one-page results
commit e2ffb4a9cc83242e3e6c4283319582c1933eb6b2
Author: tledkov-gridgain
Date: 2018-10-24T14:25:58Z
Merge branch '_master' into ignite-9171
commit 7ddcacbfcf484ed359fd1f9e2cbcc6aff414249d
Author: tledkov-gridgain
Date: 2018-10-25T12:01:25Z
IGNITE-9171: lazy mode performance optimization
commit 70be3700b47a1e367f365b049e7872f4ab84efa8
Author: tledkov-gridgain
Date: 2018-10-25T12:06:49Z
Merge master into ignite-9171
> Use lazy mode with results pre-fetch
>
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Blocker
> Labels: sql-stability
> Fix For: 2.8
>
>
> Current implementation of the {{lazy}} mode always starts separate thread for
> {{MapQueryLazyWorker}}. It causes excessive overhead for requests that
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch
> first page of the results. In case results set is bigger than one page
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle
> next pages lazy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9557) Assert exception on explain of DELETE query.
[
https://issues.apache.org/jira/browse/IGNITE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9557:
Fix Version/s: 2.8
> Assert exception on explain of DELETE query.
>
>
> Key: IGNITE-9557
> URL: https://issues.apache.org/jira/browse/IGNITE-9557
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vasiliy Sisko
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> On execution of an query:
> {code:java}
> explain delete from "schema".type {code}
> received exception:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2309)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2105)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2083)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:94)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:59)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1125)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1420)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:488)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:468)
> at
> org.apache.ignite.internal.visor.compute.VisorGatewayTask$VisorGatewayJob.execute(VisorGatewayTask.java:462)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1125)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1420)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:489)
> at
>
[jira] [Updated] (IGNITE-9557) Assert exception on explain of DELETE query.
[
https://issues.apache.org/jira/browse/IGNITE-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9557:
Ignite Flags: (was: Docs Required)
> Assert exception on explain of DELETE query.
>
>
> Key: IGNITE-9557
> URL: https://issues.apache.org/jira/browse/IGNITE-9557
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vasiliy Sisko
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> On execution of an query:
> {code:java}
> explain delete from "schema".type {code}
> received exception:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2309)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2105)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2139)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2134)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2711)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2148)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2083)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:94)
> at
> org.apache.ignite.internal.visor.query.VisorQueryTask$VisorQueryJob.run(VisorQueryTask.java:59)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1125)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1420)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:488)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:468)
> at
> org.apache.ignite.internal.visor.compute.VisorGatewayTask$VisorGatewayJob.execute(VisorGatewayTask.java:462)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6765)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1125)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1420)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:489)
> at
>
[jira] [Commented] (IGNITE-6811) JDBC Thin: SQLException("Batch is empty.") when batch list is empty
[
https://issues.apache.org/jira/browse/IGNITE-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663647#comment-16663647
]
ASF GitHub Bot commented on IGNITE-6811:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5051
> JDBC Thin: SQLException("Batch is empty.") when batch list is empty
> ---
>
> Key: IGNITE-6811
> URL: https://issues.apache.org/jira/browse/IGNITE-6811
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.3
>Reporter: Vasily Bukharev
>Assignee: Pavel Kuznetsov
>Priority: Trivial
> Fix For: 2.8
>
>
> The method executeBatch() throws SQLException("Batch is empty.") when batch
> list is empty.
> The api doc of java.sql.Statement.executeBatch()
> does not require an exception to be thrown in such situation.
> I guess it is more convinient for client code if the exception is not thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
[ https://issues.apache.org/jira/browse/IGNITE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-9989: Affects Version/s: 2.6 > JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME > - > > Key: IGNITE-9989 > URL: https://issues.apache.org/jira/browse/IGNITE-9989 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: jdbc > > Jdbc v2 driver has hardcoded values for meta attibutes : > COLUMN_NAME = _KEY > KEY_SEQ = 1 > PK_NAME = _KEY > But this values should be different for different tables. > how to reproduce: > 1) connect to the cluser using jdbcv2 driver > 2) CREATE TABLE TAB (ID LONG, SEC_ID LONG, VAL LONG, PRIMARY KEY(ID, SEC_ID)) > 3) check result of connection.getMetadata().getPrimaryKeys() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
[ https://issues.apache.org/jira/browse/IGNITE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-9989: Labels: jdbc (was: ) > JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME > - > > Key: IGNITE-9989 > URL: https://issues.apache.org/jira/browse/IGNITE-9989 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Labels: jdbc > > Jdbc v2 driver has hardcoded values for meta attibutes : > COLUMN_NAME = _KEY > KEY_SEQ = 1 > PK_NAME = _KEY > But this values should be different for different tables. > how to reproduce: > 1) connect to the cluser using jdbcv2 driver > 2) CREATE TABLE TAB (ID LONG, SEC_ID LONG, VAL LONG, PRIMARY KEY(ID, SEC_ID)) > 3) check result of connection.getMetadata().getPrimaryKeys() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
[ https://issues.apache.org/jira/browse/IGNITE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-9989: Priority: Major (was: Minor) > JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME > - > > Key: IGNITE-9989 > URL: https://issues.apache.org/jira/browse/IGNITE-9989 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > Jdbc v2 driver has hardcoded values for meta attibutes : > COLUMN_NAME = _KEY > KEY_SEQ = 1 > PK_NAME = _KEY > But this values should be different for different tables. > how to reproduce: > 1) connect to the cluser using jdbcv2 driver > 2) CREATE TABLE TAB (ID LONG, SEC_ID LONG, VAL LONG, PRIMARY KEY(ID, SEC_ID)) > 3) check result of connection.getMetadata().getPrimaryKeys() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9989) JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME
[ https://issues.apache.org/jira/browse/IGNITE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov reassigned IGNITE-9989: --- Assignee: Pavel Kuznetsov > JDBC v2: getPrimaryKeys always returns constant COLUMN_NAME, KEY_SEQ, PK_NAME > - > > Key: IGNITE-9989 > URL: https://issues.apache.org/jira/browse/IGNITE-9989 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Minor > > Jdbc v2 driver has hardcoded values for meta attibutes : > COLUMN_NAME = _KEY > KEY_SEQ = 1 > PK_NAME = _KEY > But this values should be different for different tables. > how to reproduce: > 1) connect to the cluser using jdbcv2 driver > 2) CREATE TABLE TAB (ID LONG, SEC_ID LONG, VAL LONG, PRIMARY KEY(ID, SEC_ID)) > 3) check result of connection.getMetadata().getPrimaryKeys() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9447) Benchmarks hangs intemittently due to distributed race condition.
[
https://issues.apache.org/jira/browse/IGNITE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663640#comment-16663640
]
ASF GitHub Bot commented on IGNITE-9447:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4879
> Benchmarks hangs intemittently due to distributed race condition.
> -
>
> Key: IGNITE-9447
> URL: https://issues.apache.org/jira/browse/IGNITE-9447
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Fix For: 2.8
>
>
> If we run more than one yardstick driver, benchmark hangs intermittently.
> We've got yardstick's base driver class
> org.apache.ignite.yardstick.IgniteAbstractBenchmark it has logic to wait all
> the nodes in the cluster.
> {noformat}
> final CountDownLatch nodesStartedLatch = new CountDownLatch(1);
> ignite().events().localListen(new IgnitePredicate() {
> @Override public boolean apply(Event gridEvt) {
> if (nodesStarted())
> nodesStartedLatch.countDown();
> return true;
> }
> }, EVT_NODE_JOINED);
> if (!nodesStarted()) {
> println(cfg, "Waiting for " + (args.nodes() - 1) + " nodes to
> start...");
> nodesStartedLatch.await();
> }
> {noformat}
> This code is executed on every driver node.
> If we want to close local ignite instance just after cluster is ready
> (containing expected number of nodes), sometimes we'll have dead lock:
> 1) cluster contains N-1 nodes, all nodes are waiting for the Nth node.
> 2) Nth node is connected, cluster receives message, waitForNodes code of Nth
> node is not executed.
> 3) N-1 nodes got this message and stop waiting.
> 4) N-1 thinks that cluster is ready and call ignite.close() on their local
> instances
> 5) Nth node starts waiting for cluster to contain number of nodes, but N-1 of
> them closed their instances
> 6) Nth node is waiting infinitely.
> We can avoid this problem if we use distributed CountDownLatch
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9447) Benchmarks hangs intemittently due to distributed race condition.
[
https://issues.apache.org/jira/browse/IGNITE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9447:
Component/s: (was: sql)
yardstick
> Benchmarks hangs intemittently due to distributed race condition.
> -
>
> Key: IGNITE-9447
> URL: https://issues.apache.org/jira/browse/IGNITE-9447
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Fix For: 2.8
>
>
> If we run more than one yardstick driver, benchmark hangs intermittently.
> We've got yardstick's base driver class
> org.apache.ignite.yardstick.IgniteAbstractBenchmark it has logic to wait all
> the nodes in the cluster.
> {noformat}
> final CountDownLatch nodesStartedLatch = new CountDownLatch(1);
> ignite().events().localListen(new IgnitePredicate() {
> @Override public boolean apply(Event gridEvt) {
> if (nodesStarted())
> nodesStartedLatch.countDown();
> return true;
> }
> }, EVT_NODE_JOINED);
> if (!nodesStarted()) {
> println(cfg, "Waiting for " + (args.nodes() - 1) + " nodes to
> start...");
> nodesStartedLatch.await();
> }
> {noformat}
> This code is executed on every driver node.
> If we want to close local ignite instance just after cluster is ready
> (containing expected number of nodes), sometimes we'll have dead lock:
> 1) cluster contains N-1 nodes, all nodes are waiting for the Nth node.
> 2) Nth node is connected, cluster receives message, waitForNodes code of Nth
> node is not executed.
> 3) N-1 nodes got this message and stop waiting.
> 4) N-1 thinks that cluster is ready and call ignite.close() on their local
> instances
> 5) Nth node starts waiting for cluster to contain number of nodes, but N-1 of
> them closed their instances
> 6) Nth node is waiting infinitely.
> We can avoid this problem if we use distributed CountDownLatch
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9447) Benchmarks hangs intemittently due to distributed race condition.
[
https://issues.apache.org/jira/browse/IGNITE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9447:
Fix Version/s: 2.8
> Benchmarks hangs intemittently due to distributed race condition.
> -
>
> Key: IGNITE-9447
> URL: https://issues.apache.org/jira/browse/IGNITE-9447
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Fix For: 2.8
>
>
> If we run more than one yardstick driver, benchmark hangs intermittently.
> We've got yardstick's base driver class
> org.apache.ignite.yardstick.IgniteAbstractBenchmark it has logic to wait all
> the nodes in the cluster.
> {noformat}
> final CountDownLatch nodesStartedLatch = new CountDownLatch(1);
> ignite().events().localListen(new IgnitePredicate() {
> @Override public boolean apply(Event gridEvt) {
> if (nodesStarted())
> nodesStartedLatch.countDown();
> return true;
> }
> }, EVT_NODE_JOINED);
> if (!nodesStarted()) {
> println(cfg, "Waiting for " + (args.nodes() - 1) + " nodes to
> start...");
> nodesStartedLatch.await();
> }
> {noformat}
> This code is executed on every driver node.
> If we want to close local ignite instance just after cluster is ready
> (containing expected number of nodes), sometimes we'll have dead lock:
> 1) cluster contains N-1 nodes, all nodes are waiting for the Nth node.
> 2) Nth node is connected, cluster receives message, waitForNodes code of Nth
> node is not executed.
> 3) N-1 nodes got this message and stop waiting.
> 4) N-1 thinks that cluster is ready and call ignite.close() on their local
> instances
> 5) Nth node starts waiting for cluster to contain number of nodes, but N-1 of
> them closed their instances
> 6) Nth node is waiting infinitely.
> We can avoid this problem if we use distributed CountDownLatch
--
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 ] Vladimir Ozerov updated IGNITE-9637: Component/s: yardstick > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > 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] [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 ] Vladimir Ozerov updated IGNITE-9637: Ignite Flags: (was: Docs Required) > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > 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-9454) SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE
[
https://issues.apache.org/jira/browse/IGNITE-9454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663630#comment-16663630
]
Ignite TC Bot commented on IGNITE-9454:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2157119]]
* IgniteCacheMvccTestSuite:
CacheMvccReplicatedCoordinatorFailoverTest.testReadInProgressCoordinatorFailsSimple_FromClientPutGet
- 0,0% fails in last 100 master runs.
{color:#d04437}Queries 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2157097]]
* IgniteBinaryCacheQueryTestSuite2:
DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
- 0,0% fails in last 100 master runs.
{color:#d04437}Cache (Failover) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2157129]]
* IgniteCacheFailoverTestSuite2:
GridCacheReplicatedFailoverSelfTest.testPessimisticRepeatableReadTxConstantTopologyChange
- 0,0% fails in last 100 master runs.
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2157159]]
* IgnitePdsTestSuite:
IgnitePdsDestroyCacheWithoutCheckpointsTest.testDestroyCachesAbruptlyWithoutCheckpoints
- 0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2157173buildTypeId=IgniteTests24Java8_RunAll]
> SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE
> ---
>
> Key: IGNITE-9454
> URL: https://issues.apache.org/jira/browse/IGNITE-9454
> Project: Ignite
> Issue Type: Bug
> Components: security
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: easyfix
>
> SecurityPermissionSetBuilder fails to append system permission CACHE_CREATE,
> CACHE_DESTROY and JOIN_AS_SERVER
> +*Reproducer*+:
> SecurityPermissionSetBuilder.create().appendSystemPermission(SecurityPermission.CACHE_CREATE)
> The code above throw IgniteException saying that a security permission name
> should begin with either EVENTS_ or ADMIN_
> *+Solution+:*
> Update SecurityPermissionSetBuilder to:
> # allow system permissions CACHE_CREATE, CACHE_DESTROY and JOIN_AS_SERVER
> # restrict cache presmissions CACHE_CREATE, CACHE_DESTROY
> # add automated tests
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9753) Control.sh validate index work long and with errors
[ https://issues.apache.org/jira/browse/IGNITE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663632#comment-16663632 ] Vladislav Pyatkov commented on IGNITE-9753: --- Looks good to me. > Control.sh validate index work long and with errors > --- > > Key: IGNITE-9753 > URL: https://issues.apache.org/jira/browse/IGNITE-9753 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.8 > > > Errors - > [12:19:54][:666] IndexValidationIssue [key=null, cacheName=cache_name_1, > idxName=_key_PK_hash], class java.lang.NullPointerException: null > [12:19:54][:666] IndexValidationIssue [key=null, cacheName=cache_name_2, > idxName=_key_PK_hash], class java.lang.NullPointerException: null -- 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=16663628#comment-16663628 ] ASF GitHub Bot commented on IGNITE-9637: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4796 > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > 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-9769) IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663626#comment-16663626
]
Ilya Lantukh commented on IGNITE-9769:
--
[~SomeFire],
The name *equalsPrimaryAffNodes* is misleading, because it will be *true* if
primary nodes are *not equal*. Also, I think it will be more readable if you
simply add something like this to *if* condition:
{noformat}
|| !dht.context().affinity().primaryByPartition(p,
readyVer).equals(affNodes.get(0))
{noformat}
With these check added you should be able to rollback other changes you did in
this PR and the test should pass.
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
> ---
>
> Key: IGNITE-9769
> URL: https://issues.apache.org/jira/browse/IGNITE-9769
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Trivial
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate1}} and
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate2}} are flaky.
> In the {{#readerUpdateDhtFails}} method we blocks
> {{GridDhtAtomicNearResponse}} messages and do put operation. Put should hangs
> always, but sometimes it doesn't.
--
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=16663620#comment-16663620 ] Vladimir Ozerov commented on IGNITE-9637: - Merged to master. > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > 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] [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 ] Vladimir Ozerov updated IGNITE-9637: Fix Version/s: 2.8 > SQL: Create suite for data load benchmarks > -- > > Key: IGNITE-9637 > URL: https://issues.apache.org/jira/browse/IGNITE-9637 > Project: Ignite > Issue Type: Task > Components: yardstick >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > Fix For: 2.8 > > > 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] [Assigned] (IGNITE-9972) Deleted entries remain in local partition internal map
[ https://issues.apache.org/jira/browse/IGNITE-9972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-9972: - Assignee: Ivan Bessonov > Deleted entries remain in local partition internal map > -- > > Key: IGNITE-9972 > URL: https://issues.apache.org/jira/browse/IGNITE-9972 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Anton Kurbanov >Assignee: Ivan Bessonov >Priority: Major > Attachments: IgniteTxConcurrentRemoveObjectsTest.java > > > Concurrent transactions leave entries in deleted state in local partition map. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9769) IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663549#comment-16663549
]
Ryabov Dmitrii commented on IGNITE-9769:
[~ilantukh], I added check for primaries. Can you review the changes?
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
> ---
>
> Key: IGNITE-9769
> URL: https://issues.apache.org/jira/browse/IGNITE-9769
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Trivial
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate1}} and
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate2}} are flaky.
> In the {{#readerUpdateDhtFails}} method we blocks
> {{GridDhtAtomicNearResponse}} messages and do put operation. Put should hangs
> always, but sometimes it doesn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9940) [TC Bot ] TC Bot Sort pull requests by update time
[ https://issues.apache.org/jira/browse/IGNITE-9940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PetrovMikhail resolved IGNITE-9940. --- Resolution: Fixed > [TC Bot ] TC Bot Sort pull requests by update time > -- > > Key: IGNITE-9940 > URL: https://issues.apache.org/jira/browse/IGNITE-9940 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9547) Document DML operations prohibited inside transaction
[ https://issues.apache.org/jira/browse/IGNITE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-9547: -- Assignee: Artem Budnikov > Document DML operations prohibited inside transaction > - > > Key: IGNITE-9547 > URL: https://issues.apache.org/jira/browse/IGNITE-9547 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Yury Gerzhedovich >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > Docs 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"" > However it's wrong. > We need to document that now any DML operations is prohibited and throw > Exception in case it will be executed inside a transaction. > > Also appeared new boolean property IGNITE_ALLOW_DML_INSIDE_TRANSACTION. it is > necessary to emulate the old behavior. In case value is true then DML > operation is allowed, but it be applied only after transaction will be > commited. > By default value is false. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9890) Refactor CachePartitionPartialCountersMap#fromCountersMap, no need to sort partitions any time it called.
[
https://issues.apache.org/jira/browse/IGNITE-9890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663537#comment-16663537
]
Stanilovsky Evgeny commented on IGNITE-9890:
Looks good, please proceed.
> Refactor CachePartitionPartialCountersMap#fromCountersMap, no need to sort
> partitions any time it called.
> -
>
> Key: IGNITE-9890
> URL: https://issues.apache.org/jira/browse/IGNITE-9890
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.6
>Reporter: Stanilovsky Evgeny
>Assignee: Vladislav Pyatkov
>Priority: Minor
> Fix For: 2.8
>
>
> {code:java}
> CachePartitionPartialCountersMap#fromCountersMap{code}
> we need to store sorted partitions for
> {code:java}
> partitionIndex(int partId) {return Arrays.binarySearch{code}
> method. Hope need some refactoring here, no need to sort it any time it
> called, we just need to store already sorted collection here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9959) Set consistent id in tests
[
https://issues.apache.org/jira/browse/IGNITE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663527#comment-16663527
]
Ignite TC Bot commented on IGNITE-9959:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests 0 Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=2156537]]
{color:#d04437}Continuous Query 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2156539]]
{color:#d04437}PDS 2{color} [[tests 7 TC_ADD_MSG
|https://ci.ignite.apache.org/viewLog.html?buildId=2156555]]
* IgnitePdsTestSuite2: IgniteWalReaderTest.testFillWalAndReadRecords - 0,0%
fails in last 100 master runs.
* IgnitePdsTestSuite2: IgniteWalReaderTest.testFillWalForExactSegmentsCount -
0,0% fails in last 100 master runs.
* IgnitePdsTestSuite2: IgniteWalReaderTest.testFillWalWithDifferentTypes - 0,0%
fails in last 100 master runs.
* IgnitePdsTestSuite2: IgniteWalReaderTest.testPutAllTxIntoTwoNodes - 0,0%
fails in last 100 master runs.
* IgnitePdsTestSuite2:
IgniteWalReaderTest.testRemoveOperationPresentedForDataEntryForAtomic - 0,0%
fails in last 100 master runs.
* IgnitePdsTestSuite2: IgniteWalReaderTest.testTxFillWalAndExtractDataRecords -
0,0% fails in last 100 master runs.
* IgnitePdsTestSuite2: IgniteWalReaderTest.testTxRecordsReadWoBinaryMeta - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2138564buildTypeId=IgniteTests24Java8_RunAll]
> Set consistent id in tests
> --
>
> Key: IGNITE-9959
> URL: https://issues.apache.org/jira/browse/IGNITE-9959
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Platonov
>Assignee: Alexey Platonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> We need to set consistent id for starting nodes in tests
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9890) Refactor CachePartitionPartialCountersMap#fromCountersMap, no need to sort partitions any time it called.
[
https://issues.apache.org/jira/browse/IGNITE-9890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663525#comment-16663525
]
Ignite TC Bot commented on IGNITE-9890:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2155600buildTypeId=IgniteTests24Java8_RunAll]
> Refactor CachePartitionPartialCountersMap#fromCountersMap, no need to sort
> partitions any time it called.
> -
>
> Key: IGNITE-9890
> URL: https://issues.apache.org/jira/browse/IGNITE-9890
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.6
>Reporter: Stanilovsky Evgeny
>Assignee: Vladislav Pyatkov
>Priority: Minor
> Fix For: 2.8
>
>
> {code:java}
> CachePartitionPartialCountersMap#fromCountersMap{code}
> we need to store sorted partitions for
> {code:java}
> partitionIndex(int partId) {return Arrays.binarySearch{code}
> method. Hope need some refactoring here, no need to sort it any time it
> called, we just need to store already sorted collection here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9679) Document critical workers liveness checking implementation
[
https://issues.apache.org/jira/browse/IGNITE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Budnikov reassigned IGNITE-9679:
--
Assignee: Artem Budnikov
> Document critical workers liveness checking implementation
> --
>
> Key: IGNITE-9679
> URL: https://issues.apache.org/jira/browse/IGNITE-9679
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Andrey Kuznetsov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Newly implemented critical worker thread liveness checks should be mentioned
> in Ignite Documentation. Brief description of the functionality follows.
> Ignite node has a number of critical worker threads that should be alive and
> responsive, otherwise node's health is not guaranteed. These threads monitor
> each other periodically and track two aspects for a thread being checked:
> - whether it's alive;
> - whether it updates its internal heartbeat timestamp.
> Whenever at least one of the above conditions is violated, checker thread
> logs the error and calls currently configured {{FailureHandler}}.
> {{IgniteConfiguration.SystemWorkerBlockedTimeout}} configuration property
> affects monitoring behavior. At runtime monitoring settings can be changed
> via {{FailureHandlingMxBean}}.
> By default, liveness checks are enabled, but blocked system worker detection
> will not lead to failure handler invocation, see
> {{FailureProcessor#getDefaultFailureHandler}} .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
[ https://issues.apache.org/jira/browse/IGNITE-9843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663519#comment-16663519 ] Vladimir Ozerov commented on IGNITE-9843: - Changes in indexing looks good to me. > IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta > without losing data > -- > > Key: IGNITE-9843 > URL: https://issues.apache.org/jira/browse/IGNITE-9843 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.8 > > >
[jira] [Assigned] (IGNITE-9470) MVCC TX: Mvcc transactions should throw proper exception when rolled back.
[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-9470:
--
Assignee: Ivan Pavlukhin
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9998) .NET: Implement partition preload API
[ https://issues.apache.org/jira/browse/IGNITE-9998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-9998: -- Description: ICache.PreloadPartition ICache.PreloadPartitionAsync > .NET: Implement partition preload API > - > > Key: IGNITE-9998 > URL: https://issues.apache.org/jira/browse/IGNITE-9998 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > > ICache.PreloadPartition > ICache.PreloadPartitionAsync -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module
[
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663466#comment-16663466
]
PetrovMikhail commented on IGNITE-9165:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2155730]]
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* exe: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* exe: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2155732]]
* dll: CachePartitionedTest.TestEnumerators - 3,6% fails in last 100 master
runs.
* dll: CachePartitionedTest.TestLocalSize - 3,6% fails in last 100 master runs.
* dll: CacheQueriesTest.TestSqlFieldsQueryTimeout - 0,0% fails in last 100
master runs.
* dll: CacheQueriesTest.TestSqlQueryTimeout - 0,0% fails in last 100 master
runs.
* dll: CacheQueriesTestSimpleName.TestSqlFieldsQueryTimeout - 0,0% fails in
last 100 master runs.
* dll: CacheQueriesTestSimpleName.TestSqlQueryTimeout - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2067910buildTypeId=IgniteTests24Java8_RunAll]
> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Attachments:
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields,
> pass it to other methods that might close it, or return it, and does not
> appear to close the stream on all paths out of the method. This may result
> in a file descriptor leak.
> Example:
>
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
> props.load(new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
>
> One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>
> +org.apache.ignite.internal:+
> * *BinaryContext*#classesInPackage(String)
> * *GridClientJdkMarshaller*#marshal(Object, int)
> *
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
> * *OptimizedObjectStreamSelfTest*#testReadLine()
> * *PageIdDistributionTest*#_testRealHistory()
> * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
> * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
> * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
> * *GridTestUtils*.sslContext()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
