[jira] [Assigned] (IGNITE-7894) Web console: extract new design collapsible panels into component

[Ilya Borisov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Borisov reassigned IGNITE-7894:


Assignee: Dmitriy Shabalin  (was: Andrey Novikov)

> Web console: extract new design collapsible panels into component
> -
>
> Key: IGNITE-7894
> URL: https://issues.apache.org/jira/browse/IGNITE-7894
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Dmitriy Shabalin
>Priority: Minor
> Attachments: image-2018-03-07-10-39-32-857.png, 
> image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png
>
>
> Collapsible panels in new design still don't have a reusable component that 
> encapsulates it's behavior and styles.
> Where such panels are/will be used:
> 1. Redesigned cluster configuration forms.
>  !image-2018-03-07-10-42-44-368.png! 
> 2. Current user profile.
>  !image-2018-03-07-10-42-01-013.png! 
> 3. Upcoming queries screen redesign.
> !image-2018-03-07-10-39-32-857.png! 
> New component should:
> 1. Have bindings for opened state and opened/closed events.
> 2. Have a way to insert buttons to the right of header. 
> Make sure that there are no leftover unused styles/code left.
> What to test when the issue's done:
> 1. Panels on user profile page.
> 2. Panels on configuration screens should still have lazy panel content 
> loading.
> 3. Legacy validation in clutser configuration / advanced / domain model form.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8028) Implement unit test for reseting password.

[Ilya Borisov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416768#comment-16416768
 ] 

Ilya Borisov commented on IGNITE-8028:
--

[~alexdel] yesterday I tried to unit test the reset password scenario for 
{{page-sign-in}} component and, while technically possible, I did not like how 
complex the task turned out: the page uses several dependencies, which you'd 
have to manually look for each one and import it into the mock AngularJS 
module. I think we should consider the following options:
1. Implement a minimal viable SMTP server run by envtools.js. It might also 
provide a basic way to read received emails. This will allow to run existing 
e2e/acceptance test in both development and CI environments.
2. Cover {{page-sign-in}} controller with basic unit tests OR move all the 
business logic into ngrx-style store/effects/service which should be easier to 
test and simplify the {{page-sign-in}} as much as possible.

> Implement unit test for reseting password.
> --
>
> Key: IGNITE-8028
> URL: https://issues.apache.org/jira/browse/IGNITE-8028
> Project: Ignite
>  Issue Type: Test
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Minor
>
> We need to cover the case of reseting password in Web Console. For this we 
> should mock backend mailing services.
> Question to think over:
> 1) Whether we should mock it on backend or frontend
> 2) Should we process a reseting link from response.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7526) SQL: Introduce memory region for reducer merge results with disk offload

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416350#comment-16416350
 ] 

Denis Magda commented on IGNITE-7526:
-

[~vozerov], according to the summary the optimizations will be applied to the 
client applications (who are reducers in 95% of the time). However, don't we 
need to do the same on the mappers side? I do remember the reportings when 
servers went down just because someone executed "SELECT * FROM table;" query. 

> SQL: Introduce memory region for reducer merge results with disk offload
> 
>
> Key: IGNITE-7526
> URL: https://issues.apache.org/jira/browse/IGNITE-7526
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
>
> Currently all results received from map nodes are stored inside reducer's 
> heap memory. What is worse, in case of complex queries, such as having sorts 
> or groupings, need to collect all results from mappers first before final 
> processing could be applied. In case of big results set (or intermediate 
> results) this could easily lead to OOME on reducer. 
> To mitigate this we should introduce special memory area where intermediate 
> results could be stored. All final processing should be stored in the same 
> area as well. This area should be of limited size and should be able to 
> offload results to disk in case of overflow.
> We could start with our B+Tree and free list and store results in some K-V 
> form. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7918) Huge memory leak when data streamer used together with local cache

[Mikhail Cherkasov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Cherkasov updated IGNITE-7918:
--
Fix Version/s: 2.5

> Huge memory leak when data streamer used together with local cache
> --
>
> Key: IGNITE-7918
> URL: https://issues.apache.org/jira/browse/IGNITE-7918
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Zbyszek B
>Priority: Blocker
> Fix For: 2.5
>
> Attachments: Demo.java, MemLeak-Ignite.png, MemLeak-Ignite.txt
>
>
> Dear Igniters,
> We observe huge memory leak when data streamer used together with local cache.
> In the attached demo producer produces local cache with single binary object 
> and passes this to the queue. Consumer picks up the cache from the queue, 
> constructs different binary object from it, adds it to global partitioned 
> cache and destroys local cache.
> This design causes a significant leak - the whole heap is used within minutes 
> (no matter if this is 4G or 24G).
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-4193) SQL TX: ODBC driver support

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416050#comment-16416050
 ] 

ASF GitHub Bot commented on IGNITE-4193:


GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/3708

IGNITE-4193: Added transaction support for ODBC



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-4193

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3708.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 #3708


commit 3155f6bc8884f61d786dc4ef24c4925fd10fc8c5
Author: sboikov 
Date:   2017-10-25T09:39:23Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/RowStore.java
#   
modules/yardstick/src/main/java/org/apache/ignite/yardstick/IgniteBenchmarkArguments.java

commit 00bd4794ab33725d9bca22eaf1b29bb3f0e71c2b
Author: sboikov 
Date:   2017-10-25T09:40:14Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/RowStore.java
#   
modules/yardstick/src/main/java/org/apache/ignite/yardstick/IgniteBenchmarkArguments.java

commit 6150f3a0ad310810606ec5bafbd007804808ff25
Author: sboikov 
Date:   2017-10-25T12:15:56Z

ignite-3478 Mvcc support for sql indexes

commit 2a2a2c4593bdf1708894ccbe5031708a60b097e7
Author: sboikov 
Date:   2017-10-26T08:15:34Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit 980517fb1a905447471b53a8fdae1eea46331c7d
Author: sboikov 
Date:   2017-10-26T10:11:02Z

ignite-3478 Tests with persistence enabled.

commit 987a57e3371c4f82fc51706539746fcd2736a034
Author: sboikov 
Date:   2017-10-26T13:07:18Z

ignite-3478 Support for cache groups.

commit e37dfa3b9a96d13ba38dc4c564ebeb4d0bccefa1
Author: sboikov 
Date:   2017-10-27T07:53:33Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java

commit 39f7ae974a222b63c6a91b1df6cf669266a3e911
Author: sboikov 
Date:   2017-10-27T07:58:14Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java

commit 68b61f6f59279f2ea01f152018a33b0f878f75b4
Author: sboikov 
Date:   2017-10-27T08:22:20Z

ignite-3478 Added missed serialVersionUID

commit f8c5cc5dcce9c2219b68c923221e901cae35733b
Author: sboikov 
Date:   2017-10-27T08:47:24Z

ignite-3478 Fixed compilation

commit b04849ea6e1313b0e9d8b2646b08914f8cfa3a7b
Author: sboikov 
Date:   2017-10-27T10:40:26Z

ignite-3478 Fix tests

commit d46a039506be32c1b472903525392fd3500e9c13
Author: sboikov 
Date:   2017-10-27T11:52:13Z

ignite-3478 Fix tests

commit 6466adf54f017219a16cf9835ee0214853db269e
Author: sboikov 
Date:   2017-10-27T12:14:39Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-3478

commit ecdeff85ebc63dfee02635113dbfcad98d235a31
Author: sboikov 
Date:   2017-10-27T14:09:47Z

ignite-3478 add test

commit 84f5c0f2d8d48be207b9094fc3812f31f1c12b15
Author: Igor Seliverstov 
Date:   2017-11-02T12:38:20Z

Merge branch 'master' into ignite-3478

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/reader/StandaloneGridKernalContext.java

commit 066f0aed9484160a39e75e4e3c4a92b285707e9e
Author: Igor Seliverstov 
Date:   2017-11-08T09:47:14Z

IGNITE-6709 Support mvcc filter for H2TreeIndex.findFirstOrLast

commit e1d80187a17b9a926511cc9fb316896a3c60e3d1
Author: Igor Seliverstov 
Date:   2017-11-09T16:03:11Z

Merge branch 'master' into ignite-3478

commit 694b94c6ad9fe119fddecc72aa67bbf49413e10b
Author: Igor Seliverstov 
Date:   2017-11-10T08:34:50Z

   

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416049#comment-16416049
 ] 

ASF GitHub Bot commented on IGNITE-7791:


Github user Mmuzaf closed the pull request at:

https://github.com/apache/ignite/pull/3618


> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
> Attachments: IgniteClientReconnectCacheDelayExchangeTest.java
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertTrue(Assert.java:31)
>   at junit.framework.TestCase.assertTrue(TestCase.java:201)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> 

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416010#comment-16416010
 ] 

Pavel Kuznetsov commented on IGNITE-7743:
-

using sqlline.sh 
{noformat}
$ ./sqlline.sh -u jdbc:ignite:thin://127.0.0.1/something_not_existing
sqlline version 1.3.0
0: jdbc:ignite:thin://127.0.0.1/something_not> select * from missed_table;
Error: Failed to set schema for DB connection for thread 
[schema=SOMETHING_NOT_EXISTING] (state=5,code=0)
{noformat}

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes

[Denis Mekhanikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415979#comment-16415979
 ] 

Denis Mekhanikov commented on IGNITE-7794:
--

[~dpavlov], thank you! I'll take a look. Let it be muted for now.

> Marshaller mappings are not saved to disk on joining nodes
> --
>
> Key: IGNITE-7794
> URL: https://issues.apache.org/jira/browse/IGNITE-7794
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.5
>
> Attachments: GridMarshallerMappingConsistencyTest.java
>
>
> Find attached test class.
> When a node connects to a cluster, that already has some marshaller mappings, 
> they are not saved to disk on the joining node. It may result in "Unknown 
> pair" error, if a cluster has persistence enabled, and a nodes without needed 
> mappings start and try to read persisted data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8053) Exception during checkpoint concurrent changes in topology

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk reassigned IGNITE-8053:


Assignee: Alexey Goncharuk

> Exception during checkpoint concurrent changes in topology
> --
>
> Key: IGNITE-8053
> URL: https://issues.apache.org/jira/browse/IGNITE-8053
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Sergey Kosarev
>Assignee: Alexey Goncharuk
>Priority: Major
>
> Excpetion in checkpoint thread 
> {code}
> 2018-03-23 15:25:19.085 
> [ERROR][db-checkpoint-thread-#256%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.GridCacheDatabaseSharedManager]
>  Runtime error caught during grid runnable execution: GridWorker [name=
> db-checkpoint-thread, igniteInstanceName=DPL_GRID%DplGridNodeName, 
> finished=false, hashCode=981946370, interrupted=false, 
> runner=db-checkpoint-thread-#256%DPL_GRID%DplGridNodeName%]
> java.lang.IllegalStateException: Failed to add new partition to the 
> partitions state (no enough space reserved) [partId=32321, reserved=5416]
>   at 
> org.apache.ignite.internal.pagemem.wal.record.CacheState.addPartitionState(CacheState.java:64)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2955)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2704)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2629)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> threre are 2 sequential invocations grp.topology().currentLocalPartitions() in
> GridCacheDatabaseSharedManager.Checkpointer#markCheckpointBegin
> it's assumed that results must be equal, but they doesn't actually.
> Possible problem is in
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#forceCreatePartition
> it does not check for checkpoint lock
> ctx.database().checkpointLockIsHeldByThread();



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7754) WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415945#comment-16415945
 ] 

ASF GitHub Bot commented on IGNITE-7754:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3656


> WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin
> --
>
> Key: IGNITE-7754
> URL: https://issues.apache.org/jira/browse/IGNITE-7754
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Ilya Lantukh
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.5
>
> Attachments: image-2018-03-20-19-08-42-234.png, screenshot-1.png, 
> screenshot-2.png
>
>
> On checkpoint begin method IgniteWriteAheadLogManager.fsync(WALPointer ptr) 
> will be called, but it won't actually perform fsync because mode isn't FSYNC. 
> It might lead to LFS corruption if OS or hardware failed until checkpoint had 
> been finished.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415924#comment-16415924
 ] 

Pavel Kuznetsov edited comment on IGNITE-7743 at 3/27/18 4:58 PM:
--

according to the test 
org/apache/ignite/jdbc/thin/JdbcThinConnectionSelfTest.java:359  this behaviour 
is currently expected


was (Author: pkouznet):
according to the test 
org/apache/ignite/jdbc/thin/JdbcThinConnectionSelfTest.java:359 currently this 
behaviour is currently expected

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415924#comment-16415924
 ] 

Pavel Kuznetsov commented on IGNITE-7743:
-

according to the test 
org/apache/ignite/jdbc/thin/JdbcThinConnectionSelfTest.java:359 currently this 
behaviour is currently expected

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415922#comment-16415922
 ] 

Anton Vinogradov commented on IGNITE-6846:
--

[~Alexey Kuznetsov]
Let's try to fix as a part of this issue.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415914#comment-16415914
 ] 

Dmitriy Pavlov commented on IGNITE-6846:


[~avinogradov], to be sure if it is related or not, issue needs to be deeply 
investigated.

Deep investigation usually brings fix as result.

So I prefer simultaneously. 

Number of tickets we will have is not significiant, so you can create 2 if it 
seems more reasonable to you.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415908#comment-16415908
 ] 

Anton Vinogradov edited comment on IGNITE-6846 at 3/27/18 4:49 PM:
---

[~dpavlov]
Found issue can be fixed simultaneously with this fix or later 
But we have to have another issue for that


was (Author: avinogradov):
[~dpavlov]
Found issue can be fixed simultaneously with this fix or later 

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415908#comment-16415908
 ] 

Anton Vinogradov commented on IGNITE-6846:
--

[~dpavlov]
Found issue can be fixed simultaneously with this fix or later 

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415904#comment-16415904
 ] 

Anton Vinogradov commented on IGNITE-6846:
--

[~dpavlov]
Once again. It's ok to write test for one task and find it fails because of 
another issue. 
In that case we have to create initially failing test + issue + mute TC. 
So, you'll gain no failing issues after this.

That's not ok to mix fixes since found is not trivial 

[~Alexey Kuznetsov]
Is found issue really not trivial?


> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415902#comment-16415902
 ] 

Dmitriy Pavlov commented on IGNITE-6846:


[~avinogradov], please also consider following solution - fixing this test 
before issue merge. WDYT?

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7754) WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin

[Eduard Shangareev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415899#comment-16415899
 ] 

Eduard Shangareev commented on IGNITE-7754:
---

Ivan, I have checked your code and TC state, everything is OK.

> WAL in LOG_ONLY mode doesn't execute fsync on checkpoint begin
> --
>
> Key: IGNITE-7754
> URL: https://issues.apache.org/jira/browse/IGNITE-7754
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Ilya Lantukh
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.5
>
> Attachments: image-2018-03-20-19-08-42-234.png, screenshot-1.png, 
> screenshot-2.png
>
>
> On checkpoint begin method IgniteWriteAheadLogManager.fsync(WALPointer ptr) 
> will be called, but it won't actually perform fsync because mode isn't FSYNC. 
> It might lead to LFS corruption if OS or hardware failed until checkpoint had 
> been finished.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415896#comment-16415896
 ] 

Dmitriy Pavlov commented on IGNITE-6846:


[~avinogradov], why this test became failing while was passed?

Please see https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
- it requires by default tests are passed.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Anton Vinogradov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415878#comment-16415878
 ] 

Anton Vinogradov commented on IGNITE-6846:
--

[~dpavlov]
Looks like bug not related to the issue.
In that case it's ok to create new issue, add test with fail(https:/...) and 
mute it on merge.

[~Alexey Kuznetsov]
please don't forget to link issues and set muted label.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415875#comment-16415875
 ] 

Alexey Kuznetsov commented on IGNITE-6846:
--

[~dpavlov] `read` metric bug fix is nontrivial and doesn't relate to this task.
I propose to create another new ticket and write fail("IGNITE-XYZ") in 
GridCacheNearAtomicMetricsSelfTest.testNearRead.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-809) Old value can be missed for tx near cache entry

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-809:
---

Assignee: (was: Alexey Kuznetsov)

> Old value can be missed for tx near cache entry
> ---
>
> Key: IGNITE-809
> URL: https://issues.apache.org/jira/browse/IGNITE-809
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Artem Shutak
>Priority: Major
>  Labels: Muted_test
>
> GridCacheMultinodeUpdateNearEnabledSelfTest fails.
> {noformat}
> junit.framework.AssertionFailedError: Got null in processor.
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest.testInvoke(GridCacheMultinodeUpdateAbstractSelfTest.java:98)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1361)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:67)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$2.run(GridAbstractTest.java:1304)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-809) Old value can be missed for tx near cache entry

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-809:
---

Assignee: Alexey Kuznetsov

> Old value can be missed for tx near cache entry
> ---
>
> Key: IGNITE-809
> URL: https://issues.apache.org/jira/browse/IGNITE-809
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Artem Shutak
>Assignee: Alexey Kuznetsov
>Priority: Major
>  Labels: Muted_test
>
> GridCacheMultinodeUpdateNearEnabledSelfTest fails.
> {noformat}
> junit.framework.AssertionFailedError: Got null in processor.
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMultinodeUpdateAbstractSelfTest.testInvoke(GridCacheMultinodeUpdateAbstractSelfTest.java:98)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1361)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:67)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$2.run(GridAbstractTest.java:1304)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7884) Ship SQL scripts with same database in Ignite

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415864#comment-16415864
 ] 

Denis Magda commented on IGNITE-7884:
-

[~vozerov],
* Let's add {{STREAMING ON/OFF}} commands to the SQL file with INSERTS. It's a 
best practice for the data preloading stage, and we should demonstrate it in 
the file.
* The whole goal of {{ignite_world.sql}} separation on 2 different files (DDL 
and INSERTS) was to reuse the DDL file for a COPY command example and create a 
CSV out of INSERTS file. Can you generate the CSV from the INSERTS and use that 
CSV in our {{SqlJdbcCopyExample}}? Without that there is no need to split 
{{ignite_world.sql}} into 2 pieces at all. Plus, current CSV data is not 
representative (too small data set).

> Ship SQL scripts with same database in Ignite
> -
>
> Key: IGNITE-7884
> URL: https://issues.apache.org/jira/browse/IGNITE-7884
> Project: Ignite
>  Issue Type: New Feature
>  Components: examples, sql
>Affects Versions: 2.5
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.5
>
>
> As per discussion on @dev list, let's ship two kind of SQL scripts that can 
> be used to create and populate a database quickly:
> [http://apache-ignite-developers.2346864.n4.nabble.com/Shipping-SQL-script-CSV-files-in-Ignite-examples-td27440.html]
>  
> The database below is suggested to be used because it represents real data, 
> allows setting up affinity collocation and demonstrate meaningful SQL queries 
> with joins:
> [https://github.com/dmagda/ignite_world_demo/blob/master/ignite_world.sql]
>  
> First, this script can be used as is and executed in any SQL tool such as 
> SQLline.
> Second, to demonstrate the use of {{COPY}} command we should take the same 
> script, create a file that will store DDL statements and turn INSERTS into a 
> CSV file.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8017) Disable WAL during initial preloading

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415847#comment-16415847
 ] 

ASF GitHub Bot commented on IGNITE-8017:


GitHub user ilantukh opened a pull request:

https://github.com/apache/ignite/pull/3707

IGNITE-8017



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8017

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3707.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 #3707






> Disable WAL during initial preloading
> -
>
> Key: IGNITE-8017
> URL: https://issues.apache.org/jira/browse/IGNITE-8017
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> While handling SupplyMessage, node handles each supplied data entry 
> separately, which causes a WAL record for each entry to be written. It 
> significantly limits preloading speed.
> We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
> until all data is loaded. The disadvantage of this approach is that data 
> might get corrupted if node crashes - but node that crashed during preloading 
> has to clear all it's data anyway. However, it is important to distinguish 
> situations when new node joined cluster or added to baseline topology (and 
> doesn't hold any data) and when additional partitions got assigned to node 
> after baseline topology changed (in this case node has to keep all data in 
> consistent state).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8049) Limit the number of operation cycles in B+Tree

[Alexey Stelmak (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Stelmak reassigned IGNITE-8049:
--

Assignee: Alexey Stelmak

> Limit the number of operation cycles in B+Tree
> --
>
> Key: IGNITE-8049
> URL: https://issues.apache.org/jira/browse/IGNITE-8049
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.5
>
>
> When a tree is corrupted, a B+Tree operation may result in an infinite loop. 
> We should limit the number of retries and fail if this limit is exceeded.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6807) NPE is thrown if local query is executed on client

[Taras Ledkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415816#comment-16415816
 ] 

Taras Ledkov commented on IGNITE-6807:
--

[~pkouznet], I've pushed a few cosmetic changes. The patch is OK with me.

> NPE is thrown if local query is executed on client
> --
>
> Key: IGNITE-6807
> URL: https://issues.apache.org/jira/browse/IGNITE-6807
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
>
> If a local query is executed on client node by mistake, ugly NPE is thrown:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.segmentsCount(H2TreeIndex.java:162)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.threadLocalSegment(GridH2IndexBase.java:172)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find(H2TreeIndex.java:177)
>   at org.h2.index.BaseIndex.find(BaseIndex.java:128)
>   at org.h2.index.IndexCursor.find(IndexCursor.java:169)
>   at org.h2.table.TableFilter.next(TableFilter.java:468)
>   at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1452)
>   at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
>   at org.h2.result.LazyResult.next(LazyResult.java:59)
>   at org.h2.command.dml.Select.queryFlat(Select.java:519)
>   at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
>   at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
>   at org.h2.command.dml.Query.query(Query.java:352)
>   at org.h2.command.dml.Query.query(Query.java:333)
>   at org.h2.command.CommandContainer.query(CommandContainer.java:113)
>   at org.h2.command.Command.executeQuery(Command.java:201)
>   ... 21 more
> {noformat}
> We should detect this situation and throw proper exception instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown

[Andrey Aleksandrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Aleksandrov updated IGNITE-8060:
---
Attachment: ignite-76cc6387.log

> Sqline creating tables on client nodes works incorrect in case of node's 
> shutdown
> -
>
> Key: IGNITE-8060
> URL: https://issues.apache.org/jira/browse/IGNITE-8060
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
> Attachments: ignite-76cc6387.log, ignite-a1c90af9.log
>
>
> For reproducing:
> You should start one local server and one local client nodes and follow the 
> instructions:
> 1)Connect to client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 2)Create new table on client node:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> 3)Check that table exists from server node:
> !tables
> On this step table should be shown in the response.
> 4)Drop the client node
> 5)Create new client node
> 6)Connect to new client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 7)Check that table exists from server node:
> !tables
> *On this step there is no "city" table in the list.*
> 8)Try to drop the table:
> DROP TABLE City;
> java.sql.SQLException: Table doesn't exist: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  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)
> 9)Try to create new table:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> java.sql.SQLException: Table already exists: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  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)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown

[Andrey Aleksandrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Aleksandrov updated IGNITE-8060:
---
Attachment: ignite-a1c90af9.log

> Sqline creating tables on client nodes works incorrect in case of node's 
> shutdown
> -
>
> Key: IGNITE-8060
> URL: https://issues.apache.org/jira/browse/IGNITE-8060
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
> Attachments: ignite-a1c90af9.log
>
>
> For reproducing:
> You should start one local server and one local client nodes and follow the 
> instructions:
> 1)Connect to client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 2)Create new table on client node:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> 3)Check that table exists from server node:
> !tables
> On this step table should be shown in the response.
> 4)Drop the client node
> 5)Create new client node
> 6)Connect to new client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 7)Check that table exists from server node:
> !tables
> *On this step there is no "city" table in the list.*
> 8)Try to drop the table:
> DROP TABLE City;
> java.sql.SQLException: Table doesn't exist: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  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)
> 9)Try to create new table:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> java.sql.SQLException: Table already exists: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  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)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown

[Andrey Aleksandrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Aleksandrov updated IGNITE-8060:
---
Summary: Sqline creating tables on client nodes works incorrect in case of 
node's shutdown  (was: Sqline creating tables on client nodes works incorrect 
in case if node shutdown)

> Sqline creating tables on client nodes works incorrect in case of node's 
> shutdown
> -
>
> Key: IGNITE-8060
> URL: https://issues.apache.org/jira/browse/IGNITE-8060
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
>
> For reproducing:
> You should start one local server and one local client nodes and follow the 
> instructions:
> 1)Connect to client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 2)Create new table on client node:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> 3)Check that table exists from server node:
> !tables
> On this step table should be shown in the response.
> 4)Drop the client node
> 5)Create new client node
> 6)Connect to new client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 7)Check that table exists from server node:
> !tables
> *On this step there is no "city" table in the list.*
> 8)Try to drop the table:
> DROP TABLE City;
> java.sql.SQLException: Table doesn't exist: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  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)
> 9)Try to create new table:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> java.sql.SQLException: Table already exists: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  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)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case if node shutdown

[Andrey Aleksandrov (JIRA)]

Andrey Aleksandrov created IGNITE-8060:
--

 Summary: Sqline creating tables on client nodes works incorrect in 
case if node shutdown
 Key: IGNITE-8060
 URL: https://issues.apache.org/jira/browse/IGNITE-8060
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.4
Reporter: Andrey Aleksandrov


For reproducing:

You should start one local server and one local client nodes and follow the 
instructions:

1)Connect to client node:

sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801

2)Create new table on client node:

CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated";

3)Check that table exists from server node:

!tables

On this step table should be shown in the response.

4)Drop the client node

5)Create new client node

6)Connect to new client node:

sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801

7)Check that table exists from server node:

!tables

*On this step there is no "city" table in the list.*

8)Try to drop the table:
DROP TABLE City;
java.sql.SQLException: Table doesn't exist: CITY
 at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
 at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
 at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
 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)



9)Try to create new table:
CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated";

java.sql.SQLException: Table already exists: CITY
 at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
 at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
 at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
 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)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Kuznetsov updated IGNITE-7743:

Labels: usability  (was: )

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Kuznetsov reassigned IGNITE-7743:
---

Assignee: Pavel Kuznetsov

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8059) Integrate decision tree with partition based dataset

[Anton Dmitriev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Dmitriev updated IGNITE-8059:
---
Fix Version/s: 2.5

> Integrate decision tree with partition based dataset
> 
>
> Key: IGNITE-8059
> URL: https://issues.apache.org/jira/browse/IGNITE-8059
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Anton Dmitriev
>Assignee: Anton Dmitriev
>Priority: Major
> Fix For: 2.5
>
>
> A partition based dataset (new underlying infrastructure component) was added 
> as part of IGNITE-7437 and now we need to adopt decision tree algorithm to 
> work on top of this infrastructure. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8059) Integrate decision tree with partition based dataset

[Anton Dmitriev (JIRA)]

Anton Dmitriev created IGNITE-8059:
--

 Summary: Integrate decision tree with partition based dataset
 Key: IGNITE-8059
 URL: https://issues.apache.org/jira/browse/IGNITE-8059
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Anton Dmitriev
Assignee: Anton Dmitriev


A partition based dataset (new underlying infrastructure component) was added 
as part of IGNITE-7437 and now we need to adopt decision tree algorithm to work 
on top of this infrastructure. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415716#comment-16415716
 ] 

Dmitriy Pavlov commented on IGNITE-6846:


[~Alexey Kuznetsov], please see TC results:

  Cache [3] [ tests 1 ]  
No fail rate info, probably new failure 
IgniteBinaryObjectsCacheTestSuite3: 
GridCacheNearAtomicMetricsSelfTest.testNearRead 

why do you think it should be fixed separately. Please see 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - it 
requires by default tests are passed.

GridVersionSelfTest#testVersions - is known flaky. testOperationChaining  was 
failed before. Retriggered both builds for PR.


> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-637) Implement IgniteReentrantReadWriteLock data structure

[Alexey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415713#comment-16415713
 ] 

Alexey Kuznetsov commented on IGNITE-637:
-

New implementation of ignite reentrant lock will be provided in 
https://issues.apache.org/jira/browse/IGNITE-4908
ignite reentrant read write lock should be based on this implementation.

> Implement IgniteReentrantReadWriteLock data structure
> -
>
> Key: IGNITE-637
> URL: https://issues.apache.org/jira/browse/IGNITE-637
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> We need to add {{IgniteReentrantReadWriteLock}} data structure in addition to 
> other data structures provided by Ignite. {{IgniteReentrantReadWriteLock}} 
> should have similar API to 
> {{java.util.concurrent.locks.ReentrantReadWriteLock}} class in JDK.
> As an example, you can see how 
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
>  is implemented in 
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
>  class.
> In general we need to have an entity in ATOMIC cache storing number of 
> readers and writers and allow user threads to block whenever needed to wait 
> for a lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6807) NPE is thrown if local query is executed on client

[Pavel Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415708#comment-16415708
 ] 

Pavel Kuznetsov commented on IGNITE-6807:
-

https://github.com/apache/ignite/pull/3706

> NPE is thrown if local query is executed on client
> --
>
> Key: IGNITE-6807
> URL: https://issues.apache.org/jira/browse/IGNITE-6807
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
>
> If a local query is executed on client node by mistake, ugly NPE is thrown:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.segmentsCount(H2TreeIndex.java:162)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.threadLocalSegment(GridH2IndexBase.java:172)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find(H2TreeIndex.java:177)
>   at org.h2.index.BaseIndex.find(BaseIndex.java:128)
>   at org.h2.index.IndexCursor.find(IndexCursor.java:169)
>   at org.h2.table.TableFilter.next(TableFilter.java:468)
>   at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1452)
>   at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
>   at org.h2.result.LazyResult.next(LazyResult.java:59)
>   at org.h2.command.dml.Select.queryFlat(Select.java:519)
>   at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
>   at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
>   at org.h2.command.dml.Query.query(Query.java:352)
>   at org.h2.command.dml.Query.query(Query.java:333)
>   at org.h2.command.CommandContainer.query(CommandContainer.java:113)
>   at org.h2.command.Command.executeQuery(Command.java:201)
>   ... 21 more
> {noformat}
> We should detect this situation and throw proper exception instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-4401) TouchedExpiryPolicy works incorrect in some cases

[Alexey Kuznetsov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-4401:


Assignee: (was: Alexey Kuznetsov)

> TouchedExpiryPolicy works incorrect in some cases
> -
>
> Key: IGNITE-4401
> URL: https://issues.apache.org/jira/browse/IGNITE-4401
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Kholodov
>Priority: Major
> Attachments: Expirypolicy.zip
>
>
> Test which reproduced the issue in attachment [^Expirypolicy.zip].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8048) Dynamic indexes are not stored to cache data on node join

[Anton Kalashnikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Kalashnikov reassigned IGNITE-8048:
-

Assignee: Anton Kalashnikov

> Dynamic indexes are not stored to cache data on node join
> -
>
> Key: IGNITE-8048
> URL: https://issues.apache.org/jira/browse/IGNITE-8048
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
> Attachments: IgniteDynamicIndexRestoreTest.java
>
>
> Consider the following scenario:
> 1) Start nodes, add some data
> 2) Shutdown a node, create a dynamic index
> 3) Shutdown the whole cluster, startup with the absent node, activate from 
> the absent node
> 4) Since the absent node did not 'see' the create index, index will not be 
> active after cluster activation
> 5) Update some data in the cluster
> 6) Restart the cluster, but activate from the node which did 'see' the create 
> index
> 7) Attempt to update data. Depending on the updates in (5), this will either 
> hang or result in an exception



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415698#comment-16415698
 ] 

ASF GitHub Bot commented on IGNITE-7774:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3567


> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> 

[jira] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415695#comment-16415695
 ] 

Dmitriy Pavlov commented on IGNITE-7774:


Hi [~guseinov], thank you for your contribution, merged to master.

[~vveider], thank you for review. Let's keep an eye on TeamCity.

> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> 

[jira] [Updated] (IGNITE-8058) GridMarshallerMappingConsistencyTest.testPersistedMappingsSharedOnJoin is flaky in master

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8058:
---
Labels: MakeTeamcityGreenAgain Muted_test  (was: MakeTeamcityGreenAgain)

> GridMarshallerMappingConsistencyTest.testPersistedMappingsSharedOnJoin  is 
> flaky in master
> --
>
> Key: IGNITE-8058
> URL: https://issues.apache.org/jira/browse/IGNITE-8058
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Denis Mekhanikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=408332895682007527=%3Cdefault%3E=testDetails
> Test introduced in [IGNITE-7794] is flaky, fail rate ~33%
> {noformat}
> org.apache.ignite.IgniteException: Can not perform the operation because the 
> cluster is inactive. 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.marshaller.GridMarshallerMappingConsistencyTest.testPersistedMappingsSharedOnJoin(GridMarshallerMappingConsistencyTest.java:160)
> {noformat}
> Please fix. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415668#comment-16415668
 ] 

Dmitriy Pavlov commented on IGNITE-7794:


I've created https://issues.apache.org/jira/browse/IGNITE-8058 and muted this 
test.

> Marshaller mappings are not saved to disk on joining nodes
> --
>
> Key: IGNITE-7794
> URL: https://issues.apache.org/jira/browse/IGNITE-7794
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.5
>
> Attachments: GridMarshallerMappingConsistencyTest.java
>
>
> Find attached test class.
> When a node connects to a cluster, that already has some marshaller mappings, 
> they are not saved to disk on the joining node. It may result in "Unknown 
> pair" error, if a cluster has persistence enabled, and a nodes without needed 
> mappings start and try to read persisted data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8058) GridMarshallerMappingConsistencyTest.testPersistedMappingsSharedOnJoin is flaky in master

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8058:
--

 Summary: 
GridMarshallerMappingConsistencyTest.testPersistedMappingsSharedOnJoin  is 
flaky in master
 Key: IGNITE-8058
 URL: https://issues.apache.org/jira/browse/IGNITE-8058
 Project: Ignite
  Issue Type: Test
Reporter: Dmitriy Pavlov
Assignee: Denis Mekhanikov


https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=408332895682007527=%3Cdefault%3E=testDetails

Test introduced in [IGNITE-7794] is flaky, fail rate ~33%

{noformat}
org.apache.ignite.IgniteException: Can not perform the operation because the 
cluster is inactive. 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.marshaller.GridMarshallerMappingConsistencyTest.testPersistedMappingsSharedOnJoin(GridMarshallerMappingConsistencyTest.java:160)
{noformat}
Please fix. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7149) Gradient boosting for decision tree

[Yury Babak (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Babak reassigned IGNITE-7149:
--

Assignee: Artem Malykh

> Gradient boosting for decision tree
> ---
>
> Key: IGNITE-7149
> URL: https://issues.apache.org/jira/browse/IGNITE-7149
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Yury Babak
>Assignee: Artem Malykh
>Priority: Major
>
> We want to implement gradient boosting for decision trees. It should be new 
> implementation of Trainer interface and we should keep possibility to choose 
> which trainer we want to use for our tree.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Vyacheslav Daradur (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415606#comment-16415606
 ] 

Vyacheslav Daradur commented on IGNITE-5979:


[~dpavlov], thank you for the note, I resumed progress to reproduce.

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8037) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart is flaky

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415602#comment-16415602
 ] 

Dmitriy Pavlov commented on IGNITE-8037:


[~vozerov], could you pick up this fix? IMO Sergey's reseach should make it 
easier.

> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
>  is flaky
> ---
>
> Key: IGNITE-8037
> URL: https://issues.apache.org/jira/browse/IGNITE-8037
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Priority: Major
>
> Test fails on TC as well as locally (although local runs reproduce failure 
> rarely: 1-3 failed tests for 100 runs).
> There are suspicious errors in logs:
> {noformat}
> [2018-03-23 
> 18:55:19,371][ERROR][exchange-worker-#630%index.DynamicColumnsConcurrentTransactionalPartitionedSelfTest4%][GridQueryProcessor]
>  Failed to clear indexing on cache unregister (will ignore): idx
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=idx]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:542)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:705)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2794)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1630)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:799)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:860)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1768)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.h2.jdbc.JdbcSQLException: Schema "idx" not found; SQL 
> statement:
> SET SCHEMA "idx" [90079-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.engine.Database.getSchema(Database.java:1755)
> at org.h2.command.dml.Set.update(Set.java:408)
> at org.h2.command.CommandContainer.update(CommandContainer.java:101)
> at org.h2.command.Command.executeUpdate(Command.java:260)
> at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
> at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:534)
> ... 14 more{noformat}
> Test fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.waitReconnectEvent(IgniteClientReconnectAbstractTest.java:120)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:297)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:238)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.reconnectClientNode(DynamicColumnsAbstractConcurrentSelfTest.java:804)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.checkClientReconnect(DynamicColumnsAbstractConcurrentSelfTest.java:781)
> at 
> 

[jira] [Commented] (IGNITE-8037) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart is flaky

[Sergey Chugunov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415599#comment-16415599
 ] 

Sergey Chugunov commented on IGNITE-8037:
-

I found out the cause of test failure but haven't fixed it yet.

Here is what happens in the test when it fails: 
# When client node discovers that it disconnected it tries to stop all caches 
started on it. 
# For some reason H2 Database cannot find schema for a cache and throws an 
exception.
# Exception is only logged, no further actions are executed to recover from the 
situation.
# When connectivity to the grid restores client node tries to start all 
configured caches, but situation with lacking schema repeats.
# Exchange triggered by client fails so no RECONNECT event is triggered; 
therefore test fails with outcome from description.

The root cause of the issue lies in step#2 - one needs to figure out what 
happens with schema registry inside H2 and fix it.

> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
>  is flaky
> ---
>
> Key: IGNITE-8037
> URL: https://issues.apache.org/jira/browse/IGNITE-8037
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> Test fails on TC as well as locally (although local runs reproduce failure 
> rarely: 1-3 failed tests for 100 runs).
> There are suspicious errors in logs:
> {noformat}
> [2018-03-23 
> 18:55:19,371][ERROR][exchange-worker-#630%index.DynamicColumnsConcurrentTransactionalPartitionedSelfTest4%][GridQueryProcessor]
>  Failed to clear indexing on cache unregister (will ignore): idx
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=idx]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:542)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:705)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2794)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1630)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:799)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:860)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1768)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.h2.jdbc.JdbcSQLException: Schema "idx" not found; SQL 
> statement:
> SET SCHEMA "idx" [90079-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.engine.Database.getSchema(Database.java:1755)
> at org.h2.command.dml.Set.update(Set.java:408)
> at org.h2.command.CommandContainer.update(CommandContainer.java:101)
> at org.h2.command.Command.executeUpdate(Command.java:260)
> at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
> at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:534)
> ... 14 more{noformat}
> Test fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at 
> 

[jira] [Assigned] (IGNITE-8037) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart is flaky

[Sergey Chugunov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov reassigned IGNITE-8037:
---

Assignee: (was: Sergey Chugunov)

> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
>  is flaky
> ---
>
> Key: IGNITE-8037
> URL: https://issues.apache.org/jira/browse/IGNITE-8037
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Priority: Major
>
> Test fails on TC as well as locally (although local runs reproduce failure 
> rarely: 1-3 failed tests for 100 runs).
> There are suspicious errors in logs:
> {noformat}
> [2018-03-23 
> 18:55:19,371][ERROR][exchange-worker-#630%index.DynamicColumnsConcurrentTransactionalPartitionedSelfTest4%][GridQueryProcessor]
>  Failed to clear indexing on cache unregister (will ignore): idx
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=idx]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:542)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:705)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2794)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1630)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:799)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:860)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1768)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.h2.jdbc.JdbcSQLException: Schema "idx" not found; SQL 
> statement:
> SET SCHEMA "idx" [90079-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.engine.Database.getSchema(Database.java:1755)
> at org.h2.command.dml.Set.update(Set.java:408)
> at org.h2.command.CommandContainer.update(CommandContainer.java:101)
> at org.h2.command.Command.executeUpdate(Command.java:260)
> at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
> at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:534)
> ... 14 more{noformat}
> Test fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.waitReconnectEvent(IgniteClientReconnectAbstractTest.java:120)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:297)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:238)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.reconnectClientNode(DynamicColumnsAbstractConcurrentSelfTest.java:804)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.checkClientReconnect(DynamicColumnsAbstractConcurrentSelfTest.java:781)
> at 
> 

[jira] [Commented] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415597#comment-16415597
 ] 

Dmitriy Pavlov commented on IGNITE-5979:


By the way, why ticket is in PA state, I can't find any PR

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415592#comment-16415592
 ] 

Dmitriy Pavlov commented on IGNITE-5979:


[~daradurvs], No, sorry, this test is muted , 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6248548165747570497=testDetails

Report does not contain it because already muted failures not included into 
report.

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415589#comment-16415589
 ] 

Dmitriy Pavlov commented on IGNITE-5979:


Hi [~daradurvs], sure ,lets close as cannot reproduce.

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off

[Alexander Paschenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Paschenko reassigned IGNITE-8050:
---

Assignee: Alexander Paschenko

> Throw a meaningful exception when user issues TX SQL keyword with MVCC turned 
> off
> -
>
> Key: IGNITE-8050
> URL: https://issues.apache.org/jira/browse/IGNITE-8050
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> An exception must be thrown when the user issues TX SQL command (BEGIN, 
> COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and 
> can lead to SQL engine behavior to behaving quite differently from what the 
> user expects, esp. in terms of data consistency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8047) SQL: optimize simple COUNT with DISTINCT query.

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8047:
-
Description: 
"Select COUNT(DISTINCT ) From table;" will fetch full data set to reduce 
node.
 Looks like we can -add group by ''- push down DISTINCT into map query to 
reduce network pressure.

See details on nabble [1].

[1] 
[http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html]

  was:
"Select COUNT(DISTINCT ) From table;" will fetch full data set to reduce 
node.
 Looks like we can add group by '' into map query to reduce network 
pressure.

See details on nabble [1].

[1] 
[http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html]


> SQL: optimize simple COUNT with DISTINCT query.
> ---
>
> Key: IGNITE-8047
> URL: https://issues.apache.org/jira/browse/IGNITE-8047
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrew Mashenkov
>Priority: Major
>
> "Select COUNT(DISTINCT ) From table;" will fetch full data set to 
> reduce node.
>  Looks like we can -add group by ''- push down DISTINCT into map query 
> to reduce network pressure.
> See details on nabble [1].
> [1] 
> [http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8019) During rebalancing checkpoint read lock is acquired for each entry (twice).

[Pavel Kovalenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415560#comment-16415560
 ] 

Pavel Kovalenko commented on IGNITE-8019:
-

Changes are good from my perspective.

> During rebalancing checkpoint read lock is acquired for each entry (twice).
> ---
>
> Key: IGNITE-8019
> URL: https://issues.apache.org/jira/browse/IGNITE-8019
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> In GridDhtPartitionDemander.preloadEntry(...) checkpointReadLock is acquired 
> twice, which is definitely a mistake. But even acquiring it once per entry 
> causes unnecessary contention - it should be taken once for SupplyMessage.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415530#comment-16415530
 ] 

Dmitriy Pavlov commented on IGNITE-7794:


[~dmekhanikov], what would be our next step? 

Would you prefer standalone issue creation? Or is it better to revert commit?

> Marshaller mappings are not saved to disk on joining nodes
> --
>
> Key: IGNITE-7794
> URL: https://issues.apache.org/jira/browse/IGNITE-7794
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.5
>
> Attachments: GridMarshallerMappingConsistencyTest.java
>
>
> Find attached test class.
> When a node connects to a cluster, that already has some marshaller mappings, 
> they are not saved to disk on the joining node. It may result in "Unknown 
> pair" error, if a cluster has persistence enabled, and a nodes without needed 
> mappings start and try to read persisted data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7902) Enable either swap space or persistence but not both

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415525#comment-16415525
 ] 

ASF GitHub Bot commented on IGNITE-7902:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3682


> Enable either swap space or persistence but not both 
> -
>
> Key: IGNITE-7902
> URL: https://issues.apache.org/jira/browse/IGNITE-7902
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Enabling both swap and persistence at the same time for a data region does 
> not make sense. An exception should be thrown in this case.
> See discussion - 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-swap-space-and-Ignite-Persistence-td27595.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7902) Enable either swap space or persistence but not both

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415505#comment-16415505
 ] 

Dmitriy Pavlov commented on IGNITE-7902:


[~ivan.glukos], [~aealeksandrov], thank you for review and contribution, merged 
to master.

> Enable either swap space or persistence but not both 
> -
>
> Key: IGNITE-7902
> URL: https://issues.apache.org/jira/browse/IGNITE-7902
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Enabling both swap and persistence at the same time for a data region does 
> not make sense. An exception should be thrown in this case.
> See discussion - 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-swap-space-and-Ignite-Persistence-td27595.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8057) Execute WAL fsync preventively before checkpoint begin

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8057:
---
Summary: Execute WAL fsync preventively before checkpoint begin  (was: 
Execute WAL fsync preventively before checkpoint beginCheckpoint started)

> Execute WAL fsync preventively before checkpoint begin
> --
>
> Key: IGNITE-8057
> URL: https://issues.apache.org/jira/browse/IGNITE-8057
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Rakov
>Priority: Major
>
> After fix of IGNITE-7754, we execute explicit WAL fsync on checkpoint begin:
> {noformat}
> if (hasPages) {
> assert cpPtr != null;
> tracker.onWalCpRecordFsyncStart();
> // Sync log outside the checkpoint write lock.
> cctx.wal().flush(cpPtr, true);
> tracker.onWalCpRecordFsyncEnd();
> {noformat}
> It's executed outside of checkpoint write lock. However, it still can 
> decrease overall throughput by suspending writing of dirty pages by 
> checkpoint threads.
> We can decrease time of this fsync by executing it preventively, before 
> acquiring checkpoint write lock. 
> We should prioritize this ticket if value of walCpRecordFsyncDuration metric 
> in "Checkpoint started" message will be too big.
> Note: it's possible to give a fsync hint to WAL manager in single-writer mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415497#comment-16415497
 ] 

Ryabov Dmitrii commented on IGNITE-6879:


Next time try to reset your master for an older commit and update it carefully.

Now start the tests and let me know when they will be finished.

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7647) Apache Ignite RPM packages (Stage II)

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7647:
-
Description: 
(/) Repack RPM specification to:
* -(x) be able to build package from source code-
* (/) divide single package into multiple packages (core + optional).

  was:
# (/) Repack RPM specification to:
#* -(x) be able to build package from source code-
#* (/) divide single package into multiple packages (core + optional).
# Introduce process of PRM building in release procedure.
# Introduce repository update scheme.


> Apache Ignite RPM packages (Stage II)
> -
>
> Key: IGNITE-7647
> URL: https://issues.apache.org/jira/browse/IGNITE-7647
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> (/) Repack RPM specification to:
> * -(x) be able to build package from source code-
> * (/) divide single package into multiple packages (core + optional).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8044) IgniteQueryGenerator.getOptions() method should properly handle empty list of parameters.

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8044:

Description: 
{{IgniteQueryGenerator.getOptions()}} method does not check that the parameters 
list may be {{null}} or empty.

Initial discussion of the issue is available on the user-list: 
http://apache-ignite-users.70518.x6.nabble.com/ArrayIndexOutOfBoundsException-1-in-IgniteQueryGenerator-getOptions-tt20801.html

  was:
{{IgniteQueryGenerator.getOptions()}} method does not check that the parameters 
list may be {{null}} or empty.

Initial disscussion of the issue is available on the user-list: 
http://apache-ignite-users.70518.x6.nabble.com/ArrayIndexOutOfBoundsException-1-in-IgniteQueryGenerator-getOptions-tt20801.html


> IgniteQueryGenerator.getOptions() method should properly handle empty list of 
> parameters.
> -
>
> Key: IGNITE-8044
> URL: https://issues.apache.org/jira/browse/IGNITE-8044
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
>
> {{IgniteQueryGenerator.getOptions()}} method does not check that the 
> parameters list may be {{null}} or empty.
> Initial discussion of the issue is available on the user-list: 
> http://apache-ignite-users.70518.x6.nabble.com/ArrayIndexOutOfBoundsException-1-in-IgniteQueryGenerator-getOptions-tt20801.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8044) IgniteQueryGenerator.getOptions() method should properly handle empty list of parameters.

[Vyacheslav Koptilin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-8044:

Description: 
{{IgniteQueryGenerator.getOptions()}} method does not check that the parameters 
list can be empty.

Initial discussion of the issue is available on the user-list: 
http://apache-ignite-users.70518.x6.nabble.com/ArrayIndexOutOfBoundsException-1-in-IgniteQueryGenerator-getOptions-tt20801.html

  was:
{{IgniteQueryGenerator.getOptions()}} method does not check that the parameters 
list may be {{null}} or empty.

Initial discussion of the issue is available on the user-list: 
http://apache-ignite-users.70518.x6.nabble.com/ArrayIndexOutOfBoundsException-1-in-IgniteQueryGenerator-getOptions-tt20801.html


> IgniteQueryGenerator.getOptions() method should properly handle empty list of 
> parameters.
> -
>
> Key: IGNITE-8044
> URL: https://issues.apache.org/jira/browse/IGNITE-8044
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
>
> {{IgniteQueryGenerator.getOptions()}} method does not check that the 
> parameters list can be empty.
> Initial discussion of the issue is available on the user-list: 
> http://apache-ignite-users.70518.x6.nabble.com/ArrayIndexOutOfBoundsException-1-in-IgniteQueryGenerator-getOptions-tt20801.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7902) Enable either swap space or persistence but not both

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415489#comment-16415489
 ] 

Ivan Rakov commented on IGNITE-7902:


[~aealeksandrov], [~dpavlov],
Code changes look good to me. Please, proceed with merge.

> Enable either swap space or persistence but not both 
> -
>
> Key: IGNITE-7902
> URL: https://issues.apache.org/jira/browse/IGNITE-7902
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Enabling both swap and persistence at the same time for a data region does 
> not make sense. An exception should be thrown in this case.
> See discussion - 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-swap-space-and-Ignite-Persistence-td27595.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Roman Meerson (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415486#comment-16415486
 ] 

Roman Meerson commented on IGNITE-6879:
---

[~SomeFire] was problem with reverting, so pull request automatically closed, i 
made merging and open new one

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6557) Test IgniteTxRemoveTimeoutObjectsTest has flaky fails

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415487#comment-16415487
 ] 

ASF GitHub Bot commented on IGNITE-6557:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/2803


> Test IgniteTxRemoveTimeoutObjectsTest has flaky fails
> -
>
> Key: IGNITE-6557
> URL: https://issues.apache.org/jira/browse/IGNITE-6557
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Build log:
> {noformat}
> [org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.testTxRemoveTimeoutObjects]
>  junit.framework.AssertionFailedError: Grids contain LockTimeoutObjects.
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.assertDoesNotContainLockTimeoutObjects(IgniteTxRemoveTimeoutObjectsTest.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.testTxRemoveTimeoutObjects(IgniteTxRemoveTimeoutObjectsTest.java:92)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415485#comment-16415485
 ] 

Ryabov Dmitrii commented on IGNITE-6879:


[~homich], you can do it! I believe in you!

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415484#comment-16415484
 ] 

ASF GitHub Bot commented on IGNITE-6879:


GitHub user homich1991 opened a pull request:

https://github.com/apache/ignite/pull/3704

IGNITE-6879 and migration to spring-data 2.0.5.RELEASE

Fixed IGNITE-6879
Migrated to spring-data 2.0.5.RELEASE
Migrated to spring 5.0.4.RELEASE
Fixed overrided methods naming
--

was problem with merging master in previous one 
https://github.com/apache/ignite/pull/3628, so created this one

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/homich1991/ignite ignite-6879

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3704.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 #3704


commit ae280108fad94d42a04d8b955262178ef6a365dd
Author: Roman_Meerson 
Date:   2018-03-13T15:32:46Z

Fixed IGNITE-6879
Migrated to spring-data 2.0.5.RELEASE
Migrated to spring 5.0.4.RELEASE
Fixed overrided methods naming

commit f090873961609dc0177172b0ea0a05efc4c462f8
Author: Roman_Meerson 
Date:   2018-03-13T18:34:17Z

Fixed tests

commit 2b16d5224290f81cd7949643c8c98b8a4e2b3c4f
Author: Roman_Meerson 
Date:   2018-03-13T20:46:19Z

Fixed sorting problem (added UNSORTED option)
Fixed bean loading order. Now repositories are loaded only via factory and 
not by them selves.

commit 4ca587129cc91d0a10642ab88e8469bdec4a5d92
Author: Roman_Meerson 
Date:   2018-03-22T18:44:17Z

Fixed comments on PR

commit 62f57f920eb3e57f036e664d3334dc9f3f6f599d
Author: Roman_Meerson 
Date:   2018-03-25T15:10:54Z

Fixed comments on PR

commit e4c443198d52b70912d4ce06fb74c1acd726dad3
Author: Roman_Meerson 
Date:   2018-03-25T18:30:55Z

Fixed spring data examples

commit df3fc87a815b816ad599a9872d479b3d63cd028f
Author: Roman_Meerson 
Date:   2018-03-25T18:34:50Z

Fixed check style comments in ConditionFalse class

commit 1ab3d63cceff5646f9d9d24cec952bd02615a818
Author: Roman_Meerson 
Date:   2018-03-25T19:25:24Z

Return null instead of exception throwing

commit b118dc23b65d2d6a28512ec19fa90cb779ffc793
Author: Roman_Meerson 
Date:   2018-03-27T11:56:54Z

Merge branch 'master' into ignite-6879




> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov resolved IGNITE-7300.
--
Resolution: Fixed

> Allow expressions in SQL INSERTs within transactions
> 
>
> Key: IGNITE-7300
> URL: https://issues.apache.org/jira/browse/IGNITE-7300
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexander Paschenko
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.5
>
>
> The problem is related to IGNITE-7267 - the latter honors raw rows, but drops 
> support for inserts with expressions which yield local subqueries. To fix 
> this, {{UpdatePlan.isLocalSubquery()}} must be honored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions

[Igor Seliverstov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415469#comment-16415469
 ] 

Igor Seliverstov commented on IGNITE-7300:
--

Fixed in scope of IGNITE-7604

> Allow expressions in SQL INSERTs within transactions
> 
>
> Key: IGNITE-7300
> URL: https://issues.apache.org/jira/browse/IGNITE-7300
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexander Paschenko
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.5
>
>
> The problem is related to IGNITE-7267 - the latter honors raw rows, but drops 
> support for inserts with expressions which yield local subqueries. To fix 
> this, {{UpdatePlan.isLocalSubquery()}} must be honored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions

[Igor Seliverstov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Igor Seliverstov reassigned IGNITE-7300:


Assignee: Igor Seliverstov  (was: Sergey Kalashnikov)

> Allow expressions in SQL INSERTs within transactions
> 
>
> Key: IGNITE-7300
> URL: https://issues.apache.org/jira/browse/IGNITE-7300
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexander Paschenko
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.5
>
>
> The problem is related to IGNITE-7267 - the latter honors raw rows, but drops 
> support for inserts with expressions which yield local subqueries. To fix 
> this, {{UpdatePlan.isLocalSubquery()}} must be honored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7771) Names of Ignite JMX beans should not be quoted unless required

[Stanislav Lukyanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415467#comment-16415467
 ] 

Stanislav Lukyanov commented on IGNITE-7771:


[~aealeksandrov], sure, go ahead. Big thanks!

> Names of Ignite JMX beans should not be quoted unless required
> --
>
> Key: IGNITE-7771
> URL: https://issues.apache.org/jira/browse/IGNITE-7771
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
>
> Names of Ignite JMX beans and bean groups are currently quoted if they 
> contain non-alphanumeric characters. This leads to names with spaces, e.g. 
> Thread Pools, appearing as "Thread Pools". Moreover, Thread Pools and "Thread 
> Pools" are recognized by JMX as distinct names, so code accessing that MBean 
> needs to take that into account.
> It would be better not to quote the bean and group names unless they contain 
> specific control characters. That way users won't need to quote names in 
> their JMX clients.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8057) Execute WAL fsync preventively before checkpoint beginCheckpoint started

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8057:
---
Description: 
After fix of IGNITE-7754, we execute explicit WAL fsync on checkpoint begin:
{noformat}
if (hasPages) {
assert cpPtr != null;

tracker.onWalCpRecordFsyncStart();

// Sync log outside the checkpoint write lock.
cctx.wal().flush(cpPtr, true);

tracker.onWalCpRecordFsyncEnd();
{noformat}
It's executed outside of checkpoint write lock. However, it still can decrease 
overall throughput by suspending writing of dirty pages by checkpoint threads.
We can decrease time of this fsync by executing it preventively, before 
acquiring checkpoint write lock. 
We should prioritize this ticket if value of walCpRecordFsyncDuration metric in 
"Checkpoint started" message will be too big.
Note: it's possible to give a fsync hint to WAL manager in single-writer mode.

  was:
After fix of IGNITE-7754, we execute explicit WAL fsync on checkpoint begin:
{noformat}
if (hasPages) {
assert cpPtr != null;

tracker.onWalCpRecordFsyncStart();

// Sync log outside the checkpoint write lock.
cctx.wal().flush(cpPtr, true);

tracker.onWalCpRecordFsyncEnd();
{noformat}
It's executed outside of checkpoint write lock. However, it still can decrease 
overall throughput by suspending writing of dirty pages by checkpoint threads.
We can decrease time of this fsync by executing it preemptevely, before 
acquiring checkpoint write lock. 
We should prioritize this ticket if value of walCpRecordFsyncDuration metric in 
"Checkpoint started" message will be too big.
Note: it's possible to give a fsync hint to WAL manager in single-writer mode.


> Execute WAL fsync preventively before checkpoint beginCheckpoint started
> 
>
> Key: IGNITE-8057
> URL: https://issues.apache.org/jira/browse/IGNITE-8057
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Rakov
>Priority: Major
>
> After fix of IGNITE-7754, we execute explicit WAL fsync on checkpoint begin:
> {noformat}
> if (hasPages) {
> assert cpPtr != null;
> tracker.onWalCpRecordFsyncStart();
> // Sync log outside the checkpoint write lock.
> cctx.wal().flush(cpPtr, true);
> tracker.onWalCpRecordFsyncEnd();
> {noformat}
> It's executed outside of checkpoint write lock. However, it still can 
> decrease overall throughput by suspending writing of dirty pages by 
> checkpoint threads.
> We can decrease time of this fsync by executing it preventively, before 
> acquiring checkpoint write lock. 
> We should prioritize this ticket if value of walCpRecordFsyncDuration metric 
> in "Checkpoint started" message will be too big.
> Note: it's possible to give a fsync hint to WAL manager in single-writer mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8057) Execute WAL fsync preventively before checkpoint begin

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8057:
--

 Summary: Execute WAL fsync preventively before checkpoint begin
 Key: IGNITE-8057
 URL: https://issues.apache.org/jira/browse/IGNITE-8057
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.5
Reporter: Ivan Rakov


After fix of IGNITE-7754, we execute explicit WAL fsync on checkpoint begin:
{noformat}
if (hasPages) {
assert cpPtr != null;

tracker.onWalCpRecordFsyncStart();

// Sync log outside the checkpoint write lock.
cctx.wal().flush(cpPtr, true);

tracker.onWalCpRecordFsyncEnd();
{noformat}
It's executed outside of checkpoint write lock. However, it still can decrease 
overall throughput by suspending writing of dirty pages by checkpoint threads.
We can decrease time of this fsync by executing it preemptevely, before 
acquiring checkpoint write lock. 
We should prioritize this ticket if value of walCpRecordFsyncDuration metric in 
"Checkpoint started" message will be too big.
Note: it's possible to give a fsync hint to WAL manager in single-writer mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8057) Execute WAL fsync preventively before checkpoint beginCheckpoint started

[Ivan Rakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Rakov updated IGNITE-8057:
---
Summary: Execute WAL fsync preventively before checkpoint beginCheckpoint 
started  (was: Execute WAL fsync preventively before checkpoint begin)

> Execute WAL fsync preventively before checkpoint beginCheckpoint started
> 
>
> Key: IGNITE-8057
> URL: https://issues.apache.org/jira/browse/IGNITE-8057
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ivan Rakov
>Priority: Major
>
> After fix of IGNITE-7754, we execute explicit WAL fsync on checkpoint begin:
> {noformat}
> if (hasPages) {
> assert cpPtr != null;
> tracker.onWalCpRecordFsyncStart();
> // Sync log outside the checkpoint write lock.
> cctx.wal().flush(cpPtr, true);
> tracker.onWalCpRecordFsyncEnd();
> {noformat}
> It's executed outside of checkpoint write lock. However, it still can 
> decrease overall throughput by suspending writing of dirty pages by 
> checkpoint threads.
> We can decrease time of this fsync by executing it preemptevely, before 
> acquiring checkpoint write lock. 
> We should prioritize this ticket if value of walCpRecordFsyncDuration metric 
> in "Checkpoint started" message will be too big.
> Note: it's possible to give a fsync hint to WAL manager in single-writer mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-4756) Print info about partition distribution to log

[Vyacheslav Daradur (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Daradur updated IGNITE-4756:
---
Fix Version/s: 2.5

> Print info about partition distribution to log 
> ---
>
> Key: IGNITE-4756
> URL: https://issues.apache.org/jira/browse/IGNITE-4756
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Taras Ledkov
>Assignee: Vyacheslav Daradur
>Priority: Minor
>  Labels: newbie
> Fix For: 2.5
>
>
> Summarize discussions:
> Add log message in case partitions distribution is not close to even 
> distribution:
>  # Add system property IGNITE_PART_DISTRIBUTION_WARN_THRESHOLD with default 
> value 0.1 to print warn message only when nodes count differs more then 
> threshold;
>  # The statistic is calculated and printed only for the local node;
>  # Statistic is placed at the {{GridAffinityAssignmentCache#calculate}} and 
> calculated for new {{idealAssignment}}.
>  # Message format is
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=, 
> expectedPrimary=, 
> exectedBackups=, 
> primary=, backups=].
> {noformat}
> e.g. for cache with name "test", 2 backups, 4 partition, 3 nodes:
> {noformat}
> Local node affinity assignment distribution is not ideal [cache=test, 
> expectedPrimary=1.33 (33.3%), exectedBackups=2.66 (66.66%), primary=1 (25%), 
> backups=3(75%)].
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7771) Names of Ignite JMX beans should not be quoted unless required

[Andrey Aleksandrov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415458#comment-16415458
 ] 

Andrey Aleksandrov commented on IGNITE-7771:


[~slukyanov], I am going to fix this issue if you don't mind.

> Names of Ignite JMX beans should not be quoted unless required
> --
>
> Key: IGNITE-7771
> URL: https://issues.apache.org/jira/browse/IGNITE-7771
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
>
> Names of Ignite JMX beans and bean groups are currently quoted if they 
> contain non-alphanumeric characters. This leads to names with spaces, e.g. 
> Thread Pools, appearing as "Thread Pools". Moreover, Thread Pools and "Thread 
> Pools" are recognized by JMX as distinct names, so code accessing that MBean 
> needs to take that into account.
> It would be better not to quote the bean and group names unless they contain 
> specific control characters. That way users won't need to quote names in 
> their JMX clients.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415455#comment-16415455
 ] 

ASF GitHub Bot commented on IGNITE-6879:


Github user homich1991 closed the pull request at:

https://github.com/apache/ignite/pull/3628


> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7771) Names of Ignite JMX beans should not be quoted unless required

[Andrey Aleksandrov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Aleksandrov reassigned IGNITE-7771:
--

Assignee: Andrey Aleksandrov  (was: Stanislav Lukyanov)

> Names of Ignite JMX beans should not be quoted unless required
> --
>
> Key: IGNITE-7771
> URL: https://issues.apache.org/jira/browse/IGNITE-7771
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
>
> Names of Ignite JMX beans and bean groups are currently quoted if they 
> contain non-alphanumeric characters. This leads to names with spaces, e.g. 
> Thread Pools, appearing as "Thread Pools". Moreover, Thread Pools and "Thread 
> Pools" are recognized by JMX as distinct names, so code accessing that MBean 
> needs to take that into account.
> It would be better not to quote the bean and group names unless they contain 
> specific control characters. That way users won't need to quote names in 
> their JMX clients.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7902) Enable either swap space or persistence but not both

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415448#comment-16415448
 ] 

Dmitriy Pavlov commented on IGNITE-7902:


[~aalexandrov], I've checked tests. TC is red as usual. 

[~ivan.glukos], could you see PR changes itself?

> Enable either swap space or persistence but not both 
> -
>
> Key: IGNITE-7902
> URL: https://issues.apache.org/jira/browse/IGNITE-7902
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Enabling both swap and persistence at the same time for a data region does 
> not make sense. An exception should be thrown in this case.
> See discussion - 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-swap-space-and-Ignite-Persistence-td27595.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7647) Apache Ignite RPM packages (Stage II)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415437#comment-16415437
 ] 

ASF GitHub Bot commented on IGNITE-7647:


GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/3703

IGNITE-7647



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7647

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3703.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 #3703


commit 795d8ac6b56162b5f4e4c4897496c753a41f6347
Author: Ivanov Petr 
Date:   2018-03-20T15:26:54Z

IGNITE-7647




> Apache Ignite RPM packages (Stage II)
> -
>
> Key: IGNITE-7647
> URL: https://issues.apache.org/jira/browse/IGNITE-7647
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # (/) Repack RPM specification to:
> #* -(x) be able to build package from source code-
> #* (/) divide single package into multiple packages (core + optional).
> # Introduce process of PRM building in release procedure.
> # Introduce repository update scheme.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Vyacheslav Daradur (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415434#comment-16415434
 ] 

Vyacheslav Daradur commented on IGNITE-5979:


Hi, [~dpavlov],

This test is included to {{IgniteCacheFailoverTestSuite}}, as I can see the 
history of [Cache Failover 
1|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheFailover1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv]
 history is clear and this test is absent in your the latest report of TC 
Run-All. 

I'd suggest closing this ticket.

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8056) Ignite Cassandra integration doesn't correctly handle Inet4Address and Inet6Address objects

[Nick Jacobsen (JIRA)]

Nick Jacobsen created IGNITE-8056:
-

 Summary: Ignite Cassandra integration doesn't correctly handle 
Inet4Address and Inet6Address objects
 Key: IGNITE-8056
 URL: https://issues.apache.org/jira/browse/IGNITE-8056
 Project: Ignite
  Issue Type: Bug
  Components: cache, cassandra
Affects Versions: 2.4
Reporter: Nick Jacobsen


PropertyMappingHelper.getCassandraType correctly handles the inet <-> 
java.net.InetAddress type, but not it's sub classes of java.net.Inet4Address or 
java.net.Inet6Address.  As there is no standard way to directly create an 
InetAddress, this makes it very difficult to use an inet data types for keys in 
cassandra.

 

In general, shouldn't Cassandra types handle any subclasses of supported 
classes?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8054) Let serialize only valuable part of GridLongList

[Alexander Menshikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Menshikov updated IGNITE-8054:

Issue Type: Improvement  (was: Bug)

> Let serialize only valuable part of GridLongList
> 
>
> Key: IGNITE-8054
> URL: https://issues.apache.org/jira/browse/IGNITE-8054
> Project: Ignite
>  Issue Type: Improvement
>  Components: messaging
>Affects Versions: 2.4
>Reporter: Alexander Menshikov
>Priority: Major
>  Labels: easyfix
> Fix For: 2.5
>
>
> Here in GridLongList we serialize all elements and don't take into account 
> `idx` value:
> {code:java}
> @Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 
>     writer.setBuffer(buf); 
>   
>     if (!writer.isHeaderWritten()) { 
>     if (!writer.writeHeader(directType(), fieldsCount())) 
>     return false; 
>   
>     writer.onHeaderWritten(); 
>     } 
>   
>     switch (writer.state()) { 
>     case 0: 
>     if (!writer.writeLongArray("arr", arr)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     case 1: 
>     if (!writer.writeInt("idx", idx)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     } 
>   
>     return true; 
>     } {code}
> Which is not happening in another serialization method in the same class:
> {code:java}
> public static void writeTo(DataOutput out, @Nullable GridLongList list) 
> throws IOException { 
>     out.writeInt(list != null ? list.idx : -1); 
>   
>     if (list != null) { 
>     for (int i = 0; i < list.idx; i++) 
>     out.writeLong(list.arr[i]); 
>     } 
> } {code}
> So, we can simply reduce messages size by sending only a valuable part of the 
> array.
> I created this issue according to a discussion on the mailing list:
> [http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8054) Let serialize only valuable part of GridLongList

[Alexander Menshikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Menshikov updated IGNITE-8054:

Description: 
Here in GridLongList we serialize all elements and don't take into account 
`idx` value:
{code:java}
@Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 

    writer.setBuffer(buf); 

  

    if (!writer.isHeaderWritten()) { 

    if (!writer.writeHeader(directType(), fieldsCount())) 

    return false; 

  

    writer.onHeaderWritten(); 

    } 

  

    switch (writer.state()) { 

    case 0: 
    if (!writer.writeLongArray("arr", arr)) 

    return false; 

  

    writer.incrementState(); 

  

    case 1: 

    if (!writer.writeInt("idx", idx)) 

    return false; 

  

    writer.incrementState(); 

  

    } 

  

    return true; 

    } {code}
Which is not happening in another serialization method in the same class:
{code:java}
public static void writeTo(DataOutput out, @Nullable GridLongList list) throws 
IOException { 

    out.writeInt(list != null ? list.idx : -1); 

  

    if (list != null) { 

    for (int i = 0; i < list.idx; i++) 

    out.writeLong(list.arr[i]); 

    } 

} {code}
So, we can simply reduce messages size by sending only a valuable part of the 
array.

I created this issue according to a discussion on the mailing list:

[http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html]

  was:
Here in GridLongList we serialize all elements and don't take into account 
`idx` value:


{code:java}
@Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 

    writer.setBuffer(buf); 

  

    if (!writer.isHeaderWritten()) { 

    if (!writer.writeHeader(directType(), fieldsCount())) 

    return false; 

  

    writer.onHeaderWritten(); 

    } 

  

    switch (writer.state()) { 

    case 0: 
    if (!writer.writeLongArray("arr", arr)) 

    return false; 

  

    writer.incrementState(); 

  

    case 1: 

    if (!writer.writeInt("idx", idx)) 

    return false; 

  

    writer.incrementState(); 

  

    } 

  

    return true; 

    } {code}

Which is not happening in another serialization method in the same class: 


{code:java}
public static void writeTo(DataOutput out, @Nullable GridLongList list) throws 
IOException { 

    out.writeInt(list != null ? list.idx : -1); 

  

    if (list != null) { 

    for (int i = 0; i < list.idx; i++) 

    out.writeLong(list.arr[i]); 

    } 

} {code}

So, we can simply reduce messages size by sending only a valuable part of the 
array.

 

 

I created this issue according to a discussion on the mailing list:

http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html


> Let serialize only valuable part of GridLongList
> 
>
> Key: IGNITE-8054
> URL: https://issues.apache.org/jira/browse/IGNITE-8054
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 2.4
>Reporter: Alexander Menshikov
>Priority: Major
>  Labels: easyfix
> Fix For: 2.5
>
>
> Here in GridLongList we serialize all elements and don't take into account 
> `idx` value:
> {code:java}
> @Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 
>     writer.setBuffer(buf); 
>   
>     if (!writer.isHeaderWritten()) { 
>     if (!writer.writeHeader(directType(), fieldsCount())) 
>     return false; 
>   
>     writer.onHeaderWritten(); 
>     } 
>   
>     switch (writer.state()) { 
>     case 0: 
>     if (!writer.writeLongArray("arr", arr)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     case 1: 
>     if (!writer.writeInt("idx", idx)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     } 
>   
>     return true; 
>     } {code}
> Which is not happening in another serialization method in the same class:
> {code:java}
> public static void writeTo(DataOutput out, @Nullable GridLongList list) 
> throws IOException { 
>     out.writeInt(list != null ? list.idx : -1); 
>   
>     if (list != null) { 
>     for (int i = 0; i < list.idx; i++) 
>     out.writeLong(list.arr[i]); 
>     } 
> } {code}
> So, we can simply reduce messages size by sending only a 

[jira] [Assigned] (IGNITE-5979) [Test Failed] GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync

[Vyacheslav Daradur (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Daradur reassigned IGNITE-5979:
--

Assignee: Vyacheslav Daradur  (was: Vadim Opolski)

> [Test Failed]  
> GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync 
> 
>
> Key: IGNITE-5979
> URL: https://issues.apache.org/jira/browse/IGNITE-5979
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Example of failing  - 
> http://ci.ignite.apache.org/viewLog.html?buildId=760709=buildResultsDiv=Ignite20Tests_IgniteDataGridFailover#testNameId6248548165747570497
> {noformat}
> junit.framework.AssertionFailedError: Failed to check value for key 
> [key=72625, node=0671e5c8-8bd5-4f2a-b1b8-9e945742, primary=false, 
> recNodeId=101770ef-a622-4f7c-b714-70ecf1f1] expected:<0> but 
> was:<-1994497644>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.checkRestarts(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridCacheAtomicInvalidPartitionHandlingSelfTest.testPrimaryFullAsync(GridCacheAtomicInvalidPartitionHandlingSelfTest.java:154)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8048) Dynamic indexes are not stored to cache data on node join

[Alexey Goncharuk (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415400#comment-16415400
 ] 

Alexey Goncharuk commented on IGNITE-8048:
--

Attached reproducer.

> Dynamic indexes are not stored to cache data on node join
> -
>
> Key: IGNITE-8048
> URL: https://issues.apache.org/jira/browse/IGNITE-8048
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
> Attachments: IgniteDynamicIndexRestoreTest.java
>
>
> Consider the following scenario:
> 1) Start nodes, add some data
> 2) Shutdown a node, create a dynamic index
> 3) Shutdown the whole cluster, startup with the absent node, activate from 
> the absent node
> 4) Since the absent node did not 'see' the create index, index will not be 
> active after cluster activation
> 5) Update some data in the cluster
> 6) Restart the cluster, but activate from the node which did 'see' the create 
> index
> 7) Attempt to update data. Depending on the updates in (5), this will either 
> hang or result in an exception



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8048) Dynamic indexes are not stored to cache data on node join

[Alexey Goncharuk (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-8048:
-
Attachment: IgniteDynamicIndexRestoreTest.java

> Dynamic indexes are not stored to cache data on node join
> -
>
> Key: IGNITE-8048
> URL: https://issues.apache.org/jira/browse/IGNITE-8048
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
> Attachments: IgniteDynamicIndexRestoreTest.java
>
>
> Consider the following scenario:
> 1) Start nodes, add some data
> 2) Shutdown a node, create a dynamic index
> 3) Shutdown the whole cluster, startup with the absent node, activate from 
> the absent node
> 4) Since the absent node did not 'see' the create index, index will not be 
> active after cluster activation
> 5) Update some data in the cluster
> 6) Restart the cluster, but activate from the node which did 'see' the create 
> index
> 7) Attempt to update data. Depending on the updates in (5), this will either 
> hang or result in an exception



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8055) Sqline command !tables works incorrect for client node

[Andrey Aleksandrov (JIRA)]

Andrey Aleksandrov created IGNITE-8055:
--

 Summary: Sqline command !tables works incorrect for client node
 Key: IGNITE-8055
 URL: https://issues.apache.org/jira/browse/IGNITE-8055
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.4
Reporter: Andrey Aleksandrov


For reproducing:

You should start one local server and one local client nodes and follow the 
instructions:


1)Connect to server node:

sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10800

2)Create new table on server node:

CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated";

3)Check that table exists from server node:

!tables

On this step table should be shown in the response.

4)Connect to client node:

sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801

5)Check that table exists from server node:

!tables

*On this step there is no "city" table in the list.*

Next commands work from client node as well:
SELECT * FROM City
DROP TABLE City
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7986) GridPartitionStateMap.entrySet() optimization.

[Vitaliy Biryukov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vitaliy Biryukov updated IGNITE-7986:
-
Fix Version/s: 2.5

> GridPartitionStateMap.entrySet() optimization.
> --
>
> Key: IGNITE-7986
> URL: https://issues.apache.org/jira/browse/IGNITE-7986
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Fix For: 2.5
>
> Attachments: GridPartitionStateMapBench.java, fullResult.txt
>
>
> GridPartitionStateMap based on BitSet. And the size of a BitSet depends on 
> the maximum key element, and not on the number of elements. 
> Just using the "BitSet.nextSetBit" method, will improve the performance of 
> the iterator for big clusters or caches with a large number of partitions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off

[Alexander Paschenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Paschenko updated IGNITE-8050:

Component/s: jdbc

> Throw a meaningful exception when user issues TX SQL keyword with MVCC turned 
> off
> -
>
> Key: IGNITE-8050
> URL: https://issues.apache.org/jira/browse/IGNITE-8050
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> An exception must be thrown when the user issues TX SQL command (BEGIN, 
> COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and 
> can lead to SQL engine behavior to behaving quite differently from what the 
> user expects, esp. in terms of data consistency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off

[Alexander Paschenko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Paschenko updated IGNITE-8050:

Component/s: sql

> Throw a meaningful exception when user issues TX SQL keyword with MVCC turned 
> off
> -
>
> Key: IGNITE-8050
> URL: https://issues.apache.org/jira/browse/IGNITE-8050
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> An exception must be thrown when the user issues TX SQL command (BEGIN, 
> COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and 
> can lead to SQL engine behavior to behaving quite differently from what the 
> user expects, esp. in terms of data consistency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415355#comment-16415355
 ] 

Ryabov Dmitrii commented on IGNITE-6879:


Now your PR contains 86 commits) Try this way [1]. Your PR should contain only 
your changes, but not changes already peresented in the master branch.

[1] https://help.github.com/articles/syncing-a-fork/

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7894) Web console: extract new design collapsible panels into component

[Ilya Borisov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415269#comment-16415269
 ] 

Ilya Borisov commented on IGNITE-7894:
--

[~Dmitriyff], I've added unit tests for {{panel-collapsible}}, please review. 
This set of tests will serve as a reference implementation for component unit 
tests in the future, we did not have any before now.

> Web console: extract new design collapsible panels into component
> -
>
> Key: IGNITE-7894
> URL: https://issues.apache.org/jira/browse/IGNITE-7894
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>Priority: Minor
> Attachments: image-2018-03-07-10-39-32-857.png, 
> image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png
>
>
> Collapsible panels in new design still don't have a reusable component that 
> encapsulates it's behavior and styles.
> Where such panels are/will be used:
> 1. Redesigned cluster configuration forms.
>  !image-2018-03-07-10-42-44-368.png! 
> 2. Current user profile.
>  !image-2018-03-07-10-42-01-013.png! 
> 3. Upcoming queries screen redesign.
> !image-2018-03-07-10-39-32-857.png! 
> New component should:
> 1. Have bindings for opened state and opened/closed events.
> 2. Have a way to insert buttons to the right of header. 
> Make sure that there are no leftover unused styles/code left.
> What to test when the issue's done:
> 1. Panels on user profile page.
> 2. Panels on configuration screens should still have lazy panel content 
> loading.
> 3. Legacy validation in clutser configuration / advanced / domain model form.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7647) Apache Ignite RPM packages (Stage II)

[Peter Ivanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Ivanov updated IGNITE-7647:
-
Description: 
# (/) Repack RPM specification to:
#* -(x) be able to build package from source code-
#* (/) divide single package into multiple packages (core + optional).
# Introduce process of PRM building in release procedure.
# Introduce repository update scheme.

  was:
# Repack RPM specification to:
#* -(x) be able to build package from source code-
#* divide single package into multiple packages (core + optional).
# Introduce process of PRM building in release procedure.
# Introduce repository update scheme.


> Apache Ignite RPM packages (Stage II)
> -
>
> Key: IGNITE-7647
> URL: https://issues.apache.org/jira/browse/IGNITE-7647
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.5
>
>
> # (/) Repack RPM specification to:
> #* -(x) be able to build package from source code-
> #* (/) divide single package into multiple packages (core + optional).
> # Introduce process of PRM building in release procedure.
> # Introduce repository update scheme.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8054) Let serialize only valuable part of GridLongList

[Alexander Menshikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Menshikov updated IGNITE-8054:

Labels: easyfix  (was: )

> Let serialize only valuable part of GridLongList
> 
>
> Key: IGNITE-8054
> URL: https://issues.apache.org/jira/browse/IGNITE-8054
> Project: Ignite
>  Issue Type: Bug
>  Components: messaging
>Affects Versions: 2.4
>Reporter: Alexander Menshikov
>Priority: Major
>  Labels: easyfix
> Fix For: 2.5
>
>
> Here in GridLongList we serialize all elements and don't take into account 
> `idx` value:
> {code:java}
> @Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 
>     writer.setBuffer(buf); 
>   
>     if (!writer.isHeaderWritten()) { 
>     if (!writer.writeHeader(directType(), fieldsCount())) 
>     return false; 
>   
>     writer.onHeaderWritten(); 
>     } 
>   
>     switch (writer.state()) { 
>     case 0: 
>     if (!writer.writeLongArray("arr", arr)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     case 1: 
>     if (!writer.writeInt("idx", idx)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     } 
>   
>     return true; 
>     } {code}
> Which is not happening in another serialization method in the same class: 
> {code:java}
> public static void writeTo(DataOutput out, @Nullable GridLongList list) 
> throws IOException { 
>     out.writeInt(list != null ? list.idx : -1); 
>   
>     if (list != null) { 
>     for (int i = 0; i < list.idx; i++) 
>     out.writeLong(list.arr[i]); 
>     } 
> } {code}
> So, we can simply reduce messages size by sending only a valuable part of the 
> array.
>  
>  
> I created this issue according to a discussion on the mailing list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8054) Let serialize only valuable part of GridLongList

[Alexander Menshikov (JIRA)]

Alexander Menshikov created IGNITE-8054:
---

 Summary: Let serialize only valuable part of GridLongList
 Key: IGNITE-8054
 URL: https://issues.apache.org/jira/browse/IGNITE-8054
 Project: Ignite
  Issue Type: Bug
  Components: messaging
Affects Versions: 2.4
Reporter: Alexander Menshikov
 Fix For: 2.5


Here in GridLongList we serialize all elements and don't take into account 
`idx` value:


{code:java}
@Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 

    writer.setBuffer(buf); 

  

    if (!writer.isHeaderWritten()) { 

    if (!writer.writeHeader(directType(), fieldsCount())) 

    return false; 

  

    writer.onHeaderWritten(); 

    } 

  

    switch (writer.state()) { 

    case 0: 
    if (!writer.writeLongArray("arr", arr)) 

    return false; 

  

    writer.incrementState(); 

  

    case 1: 

    if (!writer.writeInt("idx", idx)) 

    return false; 

  

    writer.incrementState(); 

  

    } 

  

    return true; 

    } {code}

Which is not happening in another serialization method in the same class: 


{code:java}
public static void writeTo(DataOutput out, @Nullable GridLongList list) throws 
IOException { 

    out.writeInt(list != null ? list.idx : -1); 

  

    if (list != null) { 

    for (int i = 0; i < list.idx; i++) 

    out.writeLong(list.arr[i]); 

    } 

} {code}

So, we can simply reduce messages size by sending only a valuable part of the 
array.

 

 

I created this issue according to a discussion on the mailing list:

http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring 2.0

[Roman Meerson (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415236#comment-16415236
 ] 

Roman Meerson commented on IGNITE-6879:
---

[~SomeFire] Sorry. I`m new in Github Fetching. Made upstream fecth and made 
merging

> Support Spring 2.0
> --
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)