[GitHub] ignite pull request #4650: IGNITE-9408: Update Apache Mesos version.
GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/4650 IGNITE-9408: Update Apache Mesos version. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite IGNITE-9408 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4650.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 #4650 commit 51265ac0f058b5f6d292064ad2808697ed6d82cc Author: shroman Date: 2018-08-30T01:57:04Z IGNITE-9408: Update Apache Mesos version. ---
Re: Bots on dev list
Is anyone in the community using or was using Nabble for the dev list communication? Personally, I am subscribed to the dev list and use filters in my email client. D. On Wed, Aug 29, 2018 at 3:40 AM, Denis Mekhanikov wrote: > Guys, > > Yep, I use filters on my mail account. But the portal is impossible to use. > When you subscribe to the dev list for the first time, you don't have any > history on your email, > and the archive is polluted with messages, sent by bots. > > Some view on Nabble, that doesn't contain any automatically generated > messages, would help here. > > Denis > > ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov : > > > Modern mail services allow users to filter messages. You can easily > filter > > out bot messages. > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > > > > > Igniters, > > > > > > We have a lot of threads, created by bots on the dev list. > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, some > > > others too, but these are the most active. > > > > > > Take a look at this page: > > > http://apache-ignite-developers.2346864.n4.nabble. > > > com/Apache-Ignite-Developers-f1i35.html > > > It's hard to find actual discussions in this mess. I'd like to see > > > something like what we have on the users list: > > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > > > It doesn't seem necessary to me to mix discussions with this cryptic > flow > > > of information. > > > Can we create a separate mailing list for bots? > > > > > > Denis > > > > > >
Re: New committer: Dmitriy Govorukhin
Dmitriy, congrats! Looking forward to many contributions to come. On Wed, Aug 29, 2018 at 12:35 PM, Denis Magda wrote: > The Project Management Committee (PMC) for Apache Ignite > has invited Dmitriy Govorukhin to become a committer and we are pleased > to announce that he has accepted. > > Being a committer enables easier contribution to the > project since there is no need to go via the patch > submission process. This should enable better productivity. > > Congrats, Dmitriy! Look forward to your contributions. > > -- > Denis >
PHP thin client
Hi folks, PHP thin client is ready for review. Jira with the scope of work - [1]. Implementation, examples, tests: PR - [2], repository - [3]. API spec - [4]. Readme (how to for the client, instructions for the examples and tests, etc.) - [5]. Regards, -Alexey [1] https://issues.apache.org/jira/browse/IGNITE-7783 [2] https://github.com/apache/ignite/pull/4649 [3] https://github.com/nobitlost/ignite/tree/ignite-7783/modules/platforms/php [4] https://rawgit.com/nobitlost/ignite/ignite-7783-docs/modules/platforms/php/api_docs/html/index.html [5] https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md
New committer: Dmitriy Govorukhin
The Project Management Committee (PMC) for Apache Ignite has invited Dmitriy Govorukhin to become a committer and we are pleased to announce that he has accepted. Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Congrats, Dmitriy! Look forward to your contributions. -- Denis
New PMC member: Dmitriy Pavlov
The Project Management Committee (PMC) for Apache Ignite has invited Dmitriy Pavlov to become a PMC member and we are pleased to announce that he has accepted. Being a PMC member enables assistance with the management and to guide the direction of the project. Congratulations Dmitriy! Keep contributing to Ignite success the way you do ;) Denis
[GitHub] ignite pull request #4649: IGNITE-7783 PHP Thin Client
GitHub user ekaterina-nbl opened a pull request: https://github.com/apache/ignite/pull/4649 IGNITE-7783 PHP Thin Client You can merge this pull request into a Git repository by running: $ git pull https://github.com/nobitlost/ignite ignite-7783 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4649.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 #4649 commit 4b444dff62c04b97bc2cdb0676ad52880374 Author: ekaterina-nbl Date: 2018-03-20T21:12:21Z initial implementation commit d1e8014c80f698028d23e09cafd7ea190ac3e929 Author: ekaterina-nbl Date: 2018-03-20T21:32:52Z initial implementation commit f79229e233ffa7bff1e7c22f04749924af6d712a Author: ekaterina-nbl Date: 2018-03-22T09:39:32Z initial implementation commit 658d60b58840080b664e02815f4ba6aac76e5804 Author: ekaterina-nbl Date: 2018-03-22T16:52:18Z minor update commit 617cef12ad72791c7e7e67179e1b0c3f7f3ae6bb Author: ekaterina-nbl Date: 2018-03-25T13:33:27Z api spec commit d9729585f5a901977e2a2e40e86a2b715fab79fa Author: alexey-nbl Date: 2018-03-25T21:27:11Z link to api_spec added commit ea847eba62e556fa81cbf9838ffe17af60f464e4 Author: ekaterina-nbl Date: 2018-03-31T22:07:50Z error types modified commit c2ad53fe625cc3a05155eeef318421538830 Author: ekaterina-nbl Date: 2018-03-31T23:41:56Z client states commit 6d2233864b4d891361d38a7143846570bd6c0ef6 Author: ekaterina-nbl Date: 2018-04-01T13:11:27Z object types improvement commit 52fbc5f87143da068596141cb59b17b684fd2c1f Author: ekaterina-nbl Date: 2018-04-02T16:59:52Z complex objects commit cae5a28e7e0d610434debcc140738e2f48d061cf Author: ekaterina-nbl Date: 2018-04-02T20:13:00Z object types improvement commit 3165405d4eae09519dc9b5f40f162eb74a9b3c5d Author: ekaterina-nbl Date: 2018-04-02T21:21:26Z client states commit fdbb8f86b32fe4c038d38620a80921be3038f31f Author: alexey-nbl Date: 2018-04-03T08:26:04Z Ignite client states described commit 04b946885db0ea2f6fe56a75e28302641dad5f61 Author: alexey-nbl Date: 2018-04-03T09:35:49Z minor update commit f4aaf1c3f23c82ba7974b4c571a9984748e5e82e Author: alexey-nbl Date: 2018-04-03T12:47:54Z Update ObjectType.js commit e4c8279f4e83b3ed13383420ab3d1417b090a3fa Author: ekaterina-nbl Date: 2018-04-03T13:46:19Z minor updates + api spec commit ed2e4ee830ca40a28dc31958665f52fab6a0bcdd Author: alexey-nbl Date: 2018-04-04T14:34:52Z Update ObjectType.js commit 7e1666eb5df82b622a028c0ea949fa21c79e66c2 Author: alexey-nbl Date: 2018-04-04T15:14:00Z Update ObjectType.js commit 7b0270d65b597dc1b0d164e78f07c3a21c37ca67 Author: ekaterina-nbl Date: 2018-04-08T17:16:43Z sql queries, key value ops commit fe90f53fd08f77add17fbf06d014f9a9b0a11c65 Author: alexey-nbl Date: 2018-04-08T18:31:47Z Update IgniteClient.js commit 04137bf5ec3b7077e194edd0100a01bb43f7933a Author: alexey-nbl Date: 2018-04-08T18:37:04Z Update CacheConfiguration.js commit b63ad5980718da1b0c44fa4ca138c6e85e47aef3 Author: alexey-nbl Date: 2018-04-08T19:11:11Z Update ObjectType.js commit 756b908c9dc38ae497e4d7d740f836dabed93e48 Author: alexey-nbl Date: 2018-04-08T22:41:54Z Update CacheClient.js commit e96ffee17298dd25d26a7029738132478271cf92 Author: ekaterina-nbl Date: 2018-04-08T23:23:33Z object array, minor updates commit c050e671f74232c4efc41f51c2018d08b152cbbc Author: alexey-nbl Date: 2018-04-09T21:04:35Z Update CacheClient.js commit 25052a4e93d6fcc0b0c4789fdd5a1eb85413b5a2 Author: alexey-nbl Date: 2018-04-09T22:43:50Z Update ObjectType.js commit c516b4147c10398d4f34d78a8830dd0fcb5f28f4 Author: alexey-nbl Date: 2018-04-10T11:50:13Z Update CacheClient.js commit 0e9924a0df8a1d41718fb929698b8e4416f2efa2 Author: ekaterina-nbl Date: 2018-04-10T13:21:16Z cache key value operations tests commit e09ee0e7969bffd6f4cfd11579f6d0ff9b486c99 Author: ekaterina-nbl Date: 2018-04-10T13:21:50Z Merge branch 'master' of https://github.com/nobitlost/ignite commit 15d2abce41b4f1c9d4d5fecd44a99a5393177482 Author: alexey-nbl Date: 2018-04-10T14:38:57Z Update Query.js ---
[jira] [Created] (IGNITE-9426) IgniteAtomicSequence benchmarks
Dmitriy Govorukhin created IGNITE-9426: -- Summary: IgniteAtomicSequence benchmarks Key: IGNITE-9426 URL: https://issues.apache.org/jira/browse/IGNITE-9426 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin Need to create JMH and Yardstick benchmarks for the atomic sequence in order to be able to measure future performance improvements -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4648: IGNITE-9341
GitHub user sk0x50 opened a pull request: https://github.com/apache/ignite/pull/4648 IGNITE-9341 You can merge this pull request into a Git repository by running: $ git pull https://github.com/sk0x50/ignite ignite-9341 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4648.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 #4648 commit db188e822a485cbdc24929f88e304c140caa5bc6 Author: Slava Koptilin Date: 2018-08-29T17:00:16Z IGNITE-9341: test changes ---
Re: Apache Ignite 2.7 release
Hell, Yakov I'm ok with your proposal. * Scope freeze - September 17 - We should have a full list of tickets for 2.7 here. * Code freeze - October 01 - We should merge all 2.7 tickets to master here. * Vote on RC1 - October 11. * Vote on release - October 15. В Ср, 29/08/2018 в 12:39 +0300, Yakov Zhdanov пишет: > Nikolay, > > I think we should have 2 weeks after code freeze which by the way may > include RC1 voting stage. This way I would like us to agree that release > candidate should be sent to vote on Oct, 11th and we can release on Oct, > 15th. > > What do you think? > > --Yakov signature.asc Description: This is a digitally signed message part
Re: Retries in write-behind store
Val, There is no need to have two implementations of the store, the exception may be handled based on the cache configuration, the store only need to check whether write-behind is enabled. The configuration change will be transparently handled by the store. This change can be easily incorporated to our POJO store. I am ok with the callback idea, but we need to discuss the API changes first. --AG ср, 29 авг. 2018 г. в 16:07, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Alex, > > I see your point, but I still think it should be incorporated into the > product. > > First of all, your solution implies changing the CacheStore implementation > every time you switch between write-through and write-behind. This > contradicts with the overall design. > > Second of all, one of the most commonly used implementations is the POJO > store which is provided out of the box. Moreover, usually users take > advantage of automatic integration feature and generate the config using > Web Console, so they often don't even know what "CacheJdbcPojoStore" is. > > Said that, your suggestion works as a workaround, but it doesn't seem to be > very user-friendly. I actually like Gaurav's idea - instead of blindly > limiting number of retries we can have a callback to handle errors. > > -Val > > On Wed, Aug 29, 2018 at 1:31 AM Alexey Goncharuk < > alexey.goncha...@gmail.com> > wrote: > > > Since the write-behind store wraps the store provided by a user, I think > > the correct solution would be to catch the exception and not propagate it > > further in the store, because only the end-user knows which errors can be > > retried, and which errors cannot. > > > > In this case no changes in the write-behind logic is needed. > > > > ср, 29 авг. 2018 г. в 7:14, Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > > > Folks, > > > > > > Is there a way to limit or disable retries of failed updates in the > > > write-behind store? I can't find one, it looks like if an update fails, > > it > > > is moved to the end of the queue and then eventually retried. If it > fails > > > again, process is repeated. > > > > > > Such behavior *might* be OK if failures are caused by database being > > > temporarily unavailable. But what if update fails deterministically, > for > > > example due to a constraint violation? There is absolutely no reason to > > > retry it, and at the same time it can cause stability and performance > > > issues when buffer is full with such "broken" updates. > > > > > > Does it makes sense to add an option that would allow to limit number > of > > > retries (or even disable them)? > > > > > > -Val > > > > > >
[GitHub] ignite pull request #4647: IGNITE-9425 - Fix NPE on index rebuild
GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/4647 IGNITE-9425 - Fix NPE on index rebuild You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9425 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4647.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 #4647 commit d26fb535865765b48fe955b3d95c544bb1ae1885 Author: dkarachentsev Date: 2018-08-29T15:43:36Z IGNITE-9425 - Fix NPE on index rebuild ---
[jira] [Created] (IGNITE-9425) NPE on index rebuild
Dmitry Karachentsev created IGNITE-9425:
---
Summary: NPE on index rebuild
Key: IGNITE-9425
URL: https://issues.apache.org/jira/browse/IGNITE-9425
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev
Fix For: 2.7
Summary:
This issue is seen when we have two caches mapped to two different regions (one
with persistence and one without persistence)
The client-side config should have the cache definitions
The server-side config should have the data regions only
Affinity should be defined on the cache without persistence
We need to populate the data into both the caches and then restart the server
and clients
The issue will be seen when the client reconnects.
Workaround:
Add the cache configurations (for the caches without persistence) to the
server-side config.
Steps to reproduce:
Ignite server
- region1 (with persistence)
- region2 (without persistence)
client
- cache1a from region1 – with custom affinity
- cache2a fom region2 – with custom affinity
1. Populate data in both cache1a and cache2a.
2. Restart ignite server. It knows about cache1a from the persistent store. It
doesn’t know about cache2a.
3. Restart client. When it connects to ignite, the server sees a nullpointer
{noformat}
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1243)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$11.apply(GridCacheDatabaseSharedManager.java:1239)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.rebuildIndexesIfNeeded(GridCacheDatabaseSharedManager.java:1239)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1711)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:126)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:729)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2419)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2299)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4646: IGNITE-9421: fixed model output
GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/4646 IGNITE-9421: fixed model output You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9421 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4646.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 #4646 commit 82279ec8fdb3bf7192af48783937c89d1867dce9 Author: zaleslaw Date: 2018-08-29T14:38:47Z IGNITE-9421: fixed model output ---
[GitHub] ignite pull request #4645: IGNITE-9424 set partition to KeyCacheObject after...
GitHub user akalash opened a pull request: https://github.com/apache/ignite/pull/4645 IGNITE-9424 set partition to KeyCacheObject after reading from page You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9424 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4645.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 #4645 commit 02d9eb573966ca1a5cf6b258b2fd9bfefc0c7054 Author: Anton Kalashnikov Date: 2018-08-29T14:03:28Z IGNITE-9424 set partition to KeyCacheObject after reading from page ---
[jira] [Created] (IGNITE-9424) Partition equal to -1 during insert to atomic cache
Anton Kalashnikov created IGNITE-9424:
-
Summary: Partition equal to -1 during insert to atomic cache
Key: IGNITE-9424
URL: https://issues.apache.org/jira/browse/IGNITE-9424
Project: Ignite
Issue Type: Test
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
Reproduced by IgnitePdsThreadInterruptionTest.testInterruptsOnWALWrite
{noformat}
org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
(retry update if possible).: [31108]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1261)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1740)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1090)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:817)
at
org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsThreadInterruptionTest$3.run(IgnitePdsThreadInterruptionTest.java:208)
at java.lang.Thread.run(Thread.java:748)
Caused by: class
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
Failed to update keys (retry update if possible).: [31108]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:394)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1865)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1664)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1153)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:611)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2430)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2407)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1087)
... 3 more
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
update keys.
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKey(UpdateErrors.java:108)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:329)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2623)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1942)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1776)
... 13 more
Suppressed: class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
Runtime failure on search row:
org.apache.ignite.internal.processors.cache.tree.SearchRow@371d7ce1
at
org.apache
[GitHub] ignite pull request #4644: Ignite 8913
GitHub user SGrimstad opened a pull request: https://github.com/apache/ignite/pull/4644 Ignite 8913 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-8913 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4644.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 #4644 commit 26543e10f8143dbc2d313b870081d633baf4cd05 Author: SGrimstad Date: 2018-08-14T11:21:13Z IGNITE-9141 Implemented commit ee631080782fe17a007e10117a96fc1a72990854 Author: devozerov Date: 2018-08-14T12:54:32Z Merge branch 'master' into ignite-9141 commit 4587bfc24f25045fd7fc2197076797cc6ca54e32 Author: devozerov Date: 2018-08-14T13:23:19Z Review. commit 1511eb31b644113091be156d872f5adb2daecb84 Author: SGrimstad Date: 2018-08-14T11:21:13Z IGNITE-9141 Implemented commit 0425a32a3d490165b29bcf9236a49a48f7761666 Author: devozerov Date: 2018-08-14T13:23:19Z Review. commit a7209f870148f984cdbf3e6437337c7b665defb5 Author: SGrimstad Date: 2018-08-20T11:56:11Z IGNITE-9141 Modified according to review comments. Integration tests added commit 08e196ad4503d4487fda0da2b61406ef3bd84cbf Author: SGrimstad Date: 2018-08-20T12:28:46Z IGNITE-9141 javadoc added commit b006a8dba4ae4319aa78a0d3c6fd6eef47bb1da8 Author: SGrimstad Date: 2018-08-20T12:29:46Z IGNITE-9141 javadoc added commit 0ed04a7ca655866685841b2ec9c2ed64797bf233 Author: devozerov Date: 2018-08-28T08:05:04Z Merge branch 'master' into ignite-9141 commit 02db267355a8405c64c45d51c81e342df664d612 Author: devozerov Date: 2018-08-28T08:45:55Z Review comments. commit 0c4301cdc0d6108ed5b51173144e19d3ad450e63 Author: SGrimstad Date: 2018-08-28T11:08:47Z IGNITE-9141 Fixes according to review commit dd35f024d77d12badf711bce3644450008e38921 Author: SGrimstad Date: 2018-08-29T12:15:43Z IGNITE-8913 Query cancelled messages are enriched with details, tests updated ---
[GitHub] ignite pull request #4643: IGNITE-8886 Fix position calculation for mixed ra...
GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/4643 IGNITE-8886 Fix position calculation for mixed raw binary objects. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8886 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4643.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 #4643 commit e16262cca84be1e7c883cc1bc6af7dc1eeec1c32 Author: Ilya Kasnacheev Date: 2018-08-29T13:48:02Z IGNITE-8886 Fix position calculation for mixed raw binary objects. ---
Re: Wrong off-heap size is reported for a node
Pavel, I think that point 1 is the correct way to calculate the committed size for a log. It is already calculated regardless of the metricsEnabled flag. In addition, I suggest more readable log format for data regions in issue comments [1]. [1] https://issues.apache.org/jira/browse/IGNITE-9305 вт, 21 авг. 2018 г. в 12:15, Pavel Pereslegin : > > Hello, Igniters. > > I assigned ticket [1] created by Denis and want to clarify how to log > committed size. > The metric offHeapSize (in DataRegionMetricsImpl) is always > calculated, but getOffHeapSize returns zero if memory metrics are > disabled for this data region. > > So I see the following options: > 1. Modify method getOffHeapSize so that it always returns actual value > offHeapSize. > 2. Add another offHeapSize() method. > 3. Output to log max size instead of committed (change "comm" to "max" > in log output). > 4. Don't bother about disabling metrics and output to log value > returned by getOffHeapSize. > > Any thoughts? > > [1] https://issues.apache.org/jira/browse/IGNITE-9305 > сб, 18 авг. 2018 г. в 3:17, Denis Magda : > > > > Vova, the things are even simpler - we have this > > > > ignite.dataRegionMetrics().getPhysicalMemorySize() that returns the > > number equal/comparabel to pageNumber X pageSize. > > > > > > Igniters, if you believe that we need to do more work here then let's > > do it iteratively. Let's fix the off-heap occupied size the way above > > (just print out getPhysicalMemorySize() for every data region). Then > > do the rest. This needs to be fixed in 2.7. > > > > > > -- > > > > Denis > > > > > > On Fri, Aug 17, 2018 at 10:20 AM Vladimir Ozerov > > wrote: > > > > > Folks, > > > > > > We already have this: > > > >>> PageMemory [pages=6997377] > > > > > > Then we can multiply it by page size and get occupied memory. Am I wrong? > > > > > > On Fri, Aug 17, 2018 at 12:56 PM Dmitriy Pavlov > > > wrote: > > > > > > > Hi Maxim, > > > > > > > > thank you for stepping in and for finding these issues. Yes, these > > > tickets > > > > are correct. > > > > > > > > I can move https://issues.apache.org/jira/browse/IGNITE-5583 to > > > unassigned > > > > if someone would like to implement this change. I will not have enough > > > time > > > > to complete it in 1 month (before 2.7 release). > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пт, 17 авг. 2018 г. в 11:04, Maxim Muzafarov : > > > > > > > > > Igniters, > > > > > > > > > > Suppose, Dmitry is talking about IGNITE-5583 [1] - `Switch non-heap > > > > memory > > > > > metrics > > > > > to new page memory semantics` and related previous disscustions to it > > > > [4]. > > > > > > > > > > Also we have some additional improvements to CacheMetrics: > > > > > IGNITE-5490 [2] - `Implement replacement for obsolete > > > > > CacheMetrics#getOffHeapAllocatedSize` > > > > > IGNITE-5765 [3] - `CacheMetrics interface cleanup, documentation and > > > > fixes` > > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-5583 > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-5490 > > > > > [3] https://issues.apache.org/jira/browse/IGNITE-5765 > > > > > [4] > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Negative-non-heap-memory-maximum-td17990.html > > > > > > > > > > On Fri, 17 Aug 2018 at 10:14 Dmitriy Pavlov > > > > wrote: > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > It is not an easy fix, so I'm not sure it is possible to do in 2.7. > > > > > > > > > > > > Offheap size is not reported by VM (it returns -1). To implement it > > > we > > > > > need > > > > > > totally migrate off-heap memory metrics to durable memory data. > > > > > > > > > > > > I think this issue was reported and I'll find the duplicate. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > пт, 17 авг. 2018 г. в 6:10, Denis Magda : > > > > > > > > > > > > > Yes, it was at the end of my wordy email :) > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9305 > > > > > > > > > > > > > > -- > > > > > > > Denis > > > > > > > > > > > > > > On Thu, Aug 16, 2018 at 11:03 PM Dmitriy Setrakyan < > > > > > > dsetrak...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > Is there a blocker ticket for 2.7? > > > > > > > > > > > > > > > > On Thu, Aug 16, 2018, 19:59 Denis Magda > > > wrote: > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > Was troubleshooting an Ignite deployment today and couldn't > > > find > > > > > out > > > > > > > from > > > > > > > > > the logs what was the actual off-heap space used. > > > > > > > > > > > > > > > > > > Those were the given memory resoures (Ignite 2.6): > > > > > > > > > > > > > > > > > > [2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] > > > > > Topology > > > > > > > > > snapshot [ver=1, servers=1, clients=0, CPUs=64, > > > *offheap=30.0GB*, > > > > > > > > > heap=24.0GB] > > > > > > > > > > > > > > > > > > And that
[GitHub] ignite pull request #4642: IGNITE-9116 .NET: LINQ: Use CacheConfiguration.Sq...
GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/4642 IGNITE-9116 .NET: LINQ: Use CacheConfiguration.SqlSchema when generating SQL You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-9116 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4642.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 #4642 commit c0638d786dfa17d68ad5e48f041b2188c74132f7 Author: Pavel Tupitsyn Date: 2018-08-13T08:42:40Z Fix LINQ provider SQL schema inferrence commit 4038a9b2da1f63bc8b27e367b27ccf13727ffac8 Author: Pavel Tupitsyn Date: 2018-08-13T08:46:10Z Add tests commit 09e6839397aec6700670a533e1d7450f053d3034 Author: Pavel Tupitsyn Date: 2018-08-13T10:59:46Z Fix quoted identifiers handling commit dd294b871eee0b9257d213d9fe52ac113bda6a77 Author: Pavel Tupitsyn Date: 2018-08-13T11:02:42Z Fix quoted identifiers handling commit bdd87f22b2ee214159721ccd38933a2a9be284ab Author: Pavel Tupitsyn Date: 2018-08-13T16:55:59Z Fix quoted identifiers handling commit 43623d411f0c253f08a691055f4589c8ae39822e Author: Pavel Tupitsyn Date: 2018-08-13T17:04:31Z Fixing tests commit fa034fa8f1b298d6eb459065f8b4ab88ec57fced Author: Pavel Tupitsyn Date: 2018-08-13T17:06:26Z TODOs commit d60fe10fe89f4d681ade6ac418326e5c1f63ae09 Author: Pavel Tupitsyn Date: 2018-08-29T08:55:06Z NormalizeSchemaName commit d440cecff1fbdcbd9c6f2d36dfd82cb218119c87 Author: Pavel Tupitsyn Date: 2018-08-29T08:59:09Z NormalizeSchemaName commit d22c5a71c539d2515db292be9ed0be107e75154f Author: Pavel Tupitsyn Date: 2018-08-29T09:08:27Z Fixing tests commit fe7adfbc66b76d320a35e3e8bb43c23a79f6ba59 Author: Pavel Tupitsyn Date: 2018-08-29T12:27:44Z Fixing tests commit cff6ec094bd3b2446bc98d5f6c575024159c8ee3 Author: Pavel Tupitsyn Date: 2018-08-29T12:47:58Z Fixing tests commit be910ff16b1a75a9a30c831107a1489b3ed55bb5 Author: Pavel Tupitsyn Date: 2018-08-29T12:58:06Z Fixing tests commit 432c5d7eae18cb3030aa624cebcea0f81efda046 Author: Pavel Tupitsyn Date: 2018-08-29T13:08:03Z Merge remote-tracking branch 'origin/master' into ignite-9116 ---
Re: Retries in write-behind store
Alex, I see your point, but I still think it should be incorporated into the product. First of all, your solution implies changing the CacheStore implementation every time you switch between write-through and write-behind. This contradicts with the overall design. Second of all, one of the most commonly used implementations is the POJO store which is provided out of the box. Moreover, usually users take advantage of automatic integration feature and generate the config using Web Console, so they often don't even know what "CacheJdbcPojoStore" is. Said that, your suggestion works as a workaround, but it doesn't seem to be very user-friendly. I actually like Gaurav's idea - instead of blindly limiting number of retries we can have a callback to handle errors. -Val On Wed, Aug 29, 2018 at 1:31 AM Alexey Goncharuk wrote: > Since the write-behind store wraps the store provided by a user, I think > the correct solution would be to catch the exception and not propagate it > further in the store, because only the end-user knows which errors can be > retried, and which errors cannot. > > In this case no changes in the write-behind logic is needed. > > ср, 29 авг. 2018 г. в 7:14, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > Folks, > > > > Is there a way to limit or disable retries of failed updates in the > > write-behind store? I can't find one, it looks like if an update fails, > it > > is moved to the end of the queue and then eventually retried. If it fails > > again, process is repeated. > > > > Such behavior *might* be OK if failures are caused by database being > > temporarily unavailable. But what if update fails deterministically, for > > example due to a constraint violation? There is absolutely no reason to > > retry it, and at the same time it can cause stability and performance > > issues when buffer is full with such "broken" updates. > > > > Does it makes sense to add an option that would allow to limit number of > > retries (or even disable them)? > > > > -Val > > >
[jira] [Created] (IGNITE-9422) All client node fails with ZKDiscovery enabled.
Stanilovsky Evgeny created IGNITE-9422:
--
Summary: All client node fails with ZKDiscovery enabled.
Key: IGNITE-9422
URL: https://issues.apache.org/jira/browse/IGNITE-9422
Project: Ignite
Issue Type: Improvement
Components: zookeeper
Affects Versions: 2.6
Reporter: Stanilovsky Evgeny
Found problem with using ZKDiscovery:
{code:java}
2018-08-28 17:43:17,953 INFO
[org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl]
(zk-DPL_GRID%DplGridNodeName-EventThread) Newer version of existing
BinaryMetadata[type
Id=557511097,
typeName=com.sbt.bm.ucp.published.api.retail.PublishedIndividual_DPL_PROXY] is
received from node 33384a02-5cbb-4dd6-8318-6ee34c88a400; updating it locally
2018-08-28 17:43:17,954 ERROR
[org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl]
(zk-DPL_GRID%DplGridNodeName-EventThread) Fatal error in ZookeeperDiscovery.
Stopping the node in orde
r to prevent cluster wide instability.: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.onJoiningNodeDataReceived(CacheObjectBinaryProcessorImpl.java:1001)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:909)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processBulkJoin(ZookeeperDiscoveryImpl.java:2792)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processNewEvents(ZookeeperDiscoveryImpl.java:2638)
at
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.processNewEvents(ZookeeperDiscoveryImpl.java:2610)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9423) unreliable test: SVMMultiClassTrainerTest.testTrainWithTheLinearlySeparableCase[Data divided on 4 partitions, training with batch size {1}]
Oleg Ignatenko created IGNITE-9423:
--
Summary: unreliable test:
SVMMultiClassTrainerTest.testTrainWithTheLinearlySeparableCase[Data divided on
4 partitions, training with batch size {1}]
Key: IGNITE-9423
URL: https://issues.apache.org/jira/browse/IGNITE-9423
Project: Ignite
Issue Type: Task
Components: ml
Affects Versions: 2.6
Reporter: Oleg Ignatenko
[Teamcity here|https://ci.ignite.apache.org/viewLog.html?buildId=1755119&;]
complains that
{{SVMMultiClassTrainerTest.testTrainWithTheLinearlySeparableCase}} is
unreliable:
{quote}*This test looks flaky:*
Frequent test status changes: 39 changes out of 128 invocations
Test status change in build without changes: from successful to failed
[View test history
»|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&tab=testDetails&testNameId=5118678405024105955#analysis]{quote}
Output for most recent test failure: {noformat}
SVMMultiClassTrainerTest.testTrainWithTheLinearlySeparableCase[Data divided on
4 partitions,
training with batch size \{1}]
java.lang.AssertionError: expected:<0.0> but was:<1.0>
at org.apache.ignite.ml.svm.SVMMultiClassTrainerTest
.testTrainWithTheLinearlySeparableCase(SVMMultiClassTrainerTest.java:53){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Apache Ignite 2.7 release
Denis, Nikolay, Igniters, This is a list of planned ML features for Apache Ignite 2.7 release: - Tensor Flow integration ( https://issues.apache.org/jira/browse/IGNITE-8670) - Data preprocessing (https://issues.apache.org/jira/browse/IGNITE-8662) - Model validation (https://issues.apache.org/jira/browse/IGNITE-8665) - Random forest algorithm ( https://issues.apache.org/jira/browse/IGNITE-8840) - Gradient boosted trees ( https://issues.apache.org/jira/browse/IGNITE-7149) - ANN algorithm (https://issues.apache.org/jira/browse/IGNITE-9261) - ML tutorial (https://issues.apache.org/jira/browse/IGNITE-8741) - And other improvements of ML module like a bugfixes, code cleanup, optimizations, etc Regards, Yury ср, 29 авг. 2018 г. в 2:43, Denis Magda : > Nikolay, Igniters, let me help you with the list. > > That what I was tracking on my side (something we can announce). Don't have > a JIRA ticket for every ticket but CC-ed everyone who claimed to be in > charge. Nikolay, please work with the community members to add these > capabilities to the release wiki page. If something doesn't get delivered > then let's exclude it. > > 1. Partition map exchange optimizations. Are we releasing any of them? > *(Sergey > Chugunov, Andrey Mashenkov)* > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-25%3A+Partition+Map+Exchange+hangs+resolving > > 2. Java 9/10/11 Support. Are we on track to support it better? *(Peter, > Vladimir)*. > > 3. SQL *(Vladimir)*: > >- Transactional SQL beta? >- Basic monitoring facilities (inline index alerts, page reads/writes >per type)? >- SQL index update optimizations? ( > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-19%3A+SQL+index+update+optimizations >) >- ODBC/JDBC session management >- Result set offload to disk. Looks it doesn't get to the release? >https://issues.apache.org/jira/browse/IGNITE-7526 > > 4. JCache 1.1 support. Completed! > > 5. Transparent data encryption? What exactly goes in 2.7? *(Nikolay)*. > > 6. Ignite + Informatica integration > > 7. Ignite and Spring Session integration (heard it was done but the ticket > is still Open): > https://issues.apache.org/jira/browse/IGNITE-2741 > > 8. Service Grid 2.0. What exactly goes in 2.7? (*Vyacheslav)* > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid > > 9. Ignite Multi Map *(Amir, Anton)* > https://issues.apache.org/jira/browse/IGNITE-640 > > 10. Thin Clients: > >- Node.JS (https://issues.apache.org/jira/browse/IGNITE-) - *Pavel >Petroshenko* >- Python (https://issues.apache.org/jira/browse/IGNITE-7782) - *Pavel >Petroshenko, **Dmitry Melnichuk* >- PHP (https://issues.apache.org/jira/browse/IGNITE-7783) - *Pavel P., >Ekaterina* >- C++: *Igor S.* >- Affinity awareness for thin clients (*Igor S.*): > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > 11. Machine and Deep Learning (preprocessing APIs, TensorFlow integration, > extra algorithms) - *Yuri and our ML experts* > > > > On Tue, Aug 28, 2018 at 10:17 AM Dmitriy Setrakyan > wrote: > > > Hi Nikolai, > > > > Generally looks OK, however, It is hard to comment on your schedule > without > > seeing a full list of all must-have features we plan to add to this > > release. I am hoping that the community will see this list at some point. > > > > D. > > > > On Tue, Aug 28, 2018 at 8:23 AM, Nikolay Izhikov > > wrote: > > > > > Hello, Igniters. > > > > > > I think we should discuss the release schedule. > > > > > > Current dates are following: > > > > > > * Code Freeze: September 30, 2018 > > > * Voting Date: October 1, 2018 > > > * Release Date: October 15, 2018 > > > > > > We discussed it privately with Vladimir Ozerov. > > > > > > Is seems better to reschedule a bit: > > > > > > * Scope freeze - September 17 - We should have a full list of > > > tickets for 2.7 here. > > > * Code freeze - October 01 - We should merge all 2.7 tickets to > > > master here. > > > * Vote - October 08. > > > > > > What do you think? > > > > > > > > > В Сб, 25/08/2018 в 00:57 +0300, Dmitriy Pavlov пишет: > > > > I hope Vyacheslav can comment better than me. I suppose it is, more > or > > > > less, rectifications and clarifications of design aspects. Not > overall > > > > redesign. > > > > > > > > I also hope Igniters, especially Services experts, will join the > > > discussion > > > > in the separate topic. Now after a couple of days there is no > reaction. > > > > > > > > сб, 25 авг. 2018 г. в 0:53, Dmitriy Setrakyan >: > > > > > > > > > On Fri, Aug 24, 2018 at 2:50 PM, Dmitriy Pavlov < > > dpavlov@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > Hi Dmitriy, I suppose it highly depends on how fast community > will > > > come > > > > > > > > > > to > > > > > > a consensus about design. So it is up to us to make this happen >
[GitHub] ignite pull request #4641: IGNITE-9348 ML examples improvements
GitHub user oignatenko opened a pull request: https://github.com/apache/ignite/pull/4641 IGNITE-9348 ML examples improvements You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9348 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4641.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 #4641 commit 39c41f7e5b40e1825a40902b1add318fbe7c7cdc Author: Oleg Ignatenko Date: 2018-08-22T14:28:29Z IGNITE-9348 ML examples improvements - wip -- verified with diffs overview, executing the examples and studying execution logs commit 78b498252943cfc5ddab9dd7ebaeeea129643bd0 Author: Oleg Ignatenko Date: 2018-08-22T15:25:57Z IGNITE-9348 ML examples improvements - wip -- verified with diffs overview, executing the examples and studying execution logs commit 09d666d1b16293f8116e4021b9379b84203896cb Author: Oleg Ignatenko Date: 2018-08-22T15:34:52Z Merge branch 'master-ml' into ignite-9348 commit 11732c09637c1cecc3c0d7e035dfab711bf2751f Author: Oleg Ignatenko Date: 2018-08-23T15:09:21Z IGNITE-9348 ML examples improvements - wip (logging improved) -- verified with diffs overview, executing the examples and studying execution logs ---
[jira] [Created] (IGNITE-9421) ML Examples: LogisticRegressionSGDTrainerExample example result not correct
Stepan Pilschikov created IGNITE-9421:
-
Summary: ML Examples: LogisticRegressionSGDTrainerExample example
result not correct
Key: IGNITE-9421
URL: https://issues.apache.org/jira/browse/IGNITE-9421
Project: Ignite
Issue Type: Bug
Components: ml
Affects Versions: 2.6
Reporter: Stepan Pilschikov
Running
org.apache.ignite.examples.ml.regression.logistic.binary.LogisticRegressionSGDTrainerExample
example
Output:
{code}
>>> Absolute amount of errors 100
>>> Accuracy 0.0
>>> Confusion matrix is [[50, 50], [0, 0]]
>>> -
>>> Logistic regression model over partitioned dataset usage example completed.
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #3236: IGNITE-5136: GridLogThrottle memory leak
Github user SomeFire closed the pull request at: https://github.com/apache/ignite/pull/3236 ---
[jira] [Created] (IGNITE-9420) Move logical recovery phase outside of PME
Pavel Kovalenko created IGNITE-9420: --- Summary: Move logical recovery phase outside of PME Key: IGNITE-9420 URL: https://issues.apache.org/jira/browse/IGNITE-9420 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Fix For: 2.7 Currently, we perform logical recovery in PME here org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#restoreState We should move logical recovery before discovery manager will start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9419) Avoid saving cache configuration synchronously during PME
Pavel Kovalenko created IGNITE-9419: --- Summary: Avoid saving cache configuration synchronously during PME Key: IGNITE-9419 URL: https://issues.apache.org/jira/browse/IGNITE-9419 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Fix For: 2.7 Currently, we save cache configuration during PME at the activation phase here org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.CachesInfo#updateCachesInfo . We should avoid this, as it performs operations to a disk. We should save it asynchronously or lazy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9418) Avoid initialize file page store manager for caches during PME synchronously
Pavel Kovalenko created IGNITE-9418: --- Summary: Avoid initialize file page store manager for caches during PME synchronously Key: IGNITE-9418 URL: https://issues.apache.org/jira/browse/IGNITE-9418 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.7 Currently, we do creation for partition and index files during PME for starting caches at the beginning of org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#readCheckpointAndRestoreMemory method. We should avoid this because sometimes it took a long time as we perform writing to disk. If the cache was registered during PME we should initialize page store lazy or asynchronously. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[ML] Bugs in GA Grid
Turik, Could you please take a look on those two bugs: https://issues.apache.org/jira/browse/IGNITE-9354 https://issues.apache.org/jira/browse/IGNITE-9359 Thanks, Yury
[jira] [Created] (IGNITE-9417) IgniteSqlInsertIndexedValueBenchamrks failed with more than one driver
Ilya Suntsov created IGNITE-9417:
Summary: IgniteSqlInsertIndexedValueBenchamrks failed with more
than one driver
Key: IGNITE-9417
URL: https://issues.apache.org/jira/browse/IGNITE-9417
Project: Ignite
Issue Type: Bug
Reporter: Ilya Suntsov
I guess that we need to handle errors like bellow and continue to work OR each
driver must insert it's own key range:
{noformat}
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
javax.cache.CacheException: Duplicate key during INSERT [key=52]
<-->at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:676)
<-->at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
<-->at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:385)
<-->at
org.apache.ignite.yardstick.cache.dml.IgniteSqlInsertIndexedValue1Benchmark.test(IgniteSqlInsertIndexedValue1Benchmark.java:38)
<-->at
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
<-->at java.lang.Thread.run(Thread.java:748)
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Duplicate key
during INSERT [key=52]
<-->at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:803)
<-->at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.processDmlSelectResult(DmlStatementsProcessor.java:581)
<-->at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:539)
<-->at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:171)
<-->at
org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:345)
<-->at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1791)
<-->at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1755)
<-->at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2107)
<-->at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2102)
<-->at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
<-->at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2650)
<-->at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2116)
<-->at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
<-->... 5 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9416) [ML] Update distribution approach for TensorFlow module
Anton Dmitriev created IGNITE-9416: -- Summary: [ML] Update distribution approach for TensorFlow module Key: IGNITE-9416 URL: https://issues.apache.org/jira/browse/IGNITE-9416 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.7 Reporter: Anton Dmitriev So far we package "ignite-tf.sh" into zip file in "ignite-tensorflow" module. We need to define right approach to do it so that users are able to use it easily the same way as other Ignite command line tools. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9415) [ML] Using sparce vectors in LSQR and MLP
Yury Babak created IGNITE-9415: -- Summary: [ML] Using sparce vectors in LSQR and MLP Key: IGNITE-9415 URL: https://issues.apache.org/jira/browse/IGNITE-9415 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Fix For: 2.7 We need to investigate and apply sparce vectors support in BLAS for LSQR and MLP (or implement own version) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9414) [ML] Using sparce vectors in Tree-based algorithms.
Yury Babak created IGNITE-9414: -- Summary: [ML] Using sparce vectors in Tree-based algorithms. Key: IGNITE-9414 URL: https://issues.apache.org/jira/browse/IGNITE-9414 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Fix For: 2.7 We need to support sparce vectors in DecisionTrees, RF, GDB -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9413) [ML] Learning rate optimization for GDB.
Yury Babak created IGNITE-9413: -- Summary: [ML] Learning rate optimization for GDB. Key: IGNITE-9413 URL: https://issues.apache.org/jira/browse/IGNITE-9413 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Fix For: 2.7 We need to support learning rate optimization while training for MSE-loss and Log-loss -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9412) [ML] GDB convergence by error support.
Yury Babak created IGNITE-9412: -- Summary: [ML] GDB convergence by error support. Key: IGNITE-9412 URL: https://issues.apache.org/jira/browse/IGNITE-9412 Project: Ignite Issue Type: Improvement Components: ml Reporter: Yury Babak Fix For: 2.7 We need to support early training interruption when GDB has small error rate on learning sample -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Bots on dev list
Guys, Yep, I use filters on my mail account. But the portal is impossible to use. When you subscribe to the dev list for the first time, you don't have any history on your email, and the archive is polluted with messages, sent by bots. Some view on Nabble, that doesn't contain any automatically generated messages, would help here. Denis ср, 29 авг. 2018 г. в 12:26, Dmitrii Ryabov : > Modern mail services allow users to filter messages. You can easily filter > out bot messages. > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > > > Igniters, > > > > We have a lot of threads, created by bots on the dev list. > > Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, some > > others too, but these are the most active. > > > > Take a look at this page: > > http://apache-ignite-developers.2346864.n4.nabble. > > com/Apache-Ignite-Developers-f1i35.html > > It's hard to find actual discussions in this mess. I'd like to see > > something like what we have on the users list: > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > It doesn't seem necessary to me to mix discussions with this cryptic flow > > of information. > > Can we create a separate mailing list for bots? > > > > Denis > > >
Re: Bots on dev list
Denis, I am against filtering out MTCGA messages from the dev-list because test failures affect every developer in the community and may be caused by any developer in the community. Usually such emails require immediate action and it would be wrong to move them to a separate list. I understand, though, your concern about the dev-list appearance on nabble. I wonder if there is an option to create subfolders there so that certain emails are put into a separate subfolders, like Dmitrii Ryabov mentioned before. --AG ср, 29 авг. 2018 г. в 12:48, Maxim Muzafarov : > Denis, > > I would like to keep a single entry point into the whole Ignite development > process project, > but maybe other Igniters have another opinion on this. As for me, it's a > more convenient way > for searching any activity on dev.list by single keyword (e.g. PRs, JIRAs, > topics). > > As mentioned Dmitry, you can configure your mail agent for grouping or > moving bot messages into > the separate directory. These messages have predefined topic names and can > be easily filtered. > > On Wed, 29 Aug 2018 at 12:26 Dmitrii Ryabov wrote: > > > Modern mail services allow users to filter messages. You can easily > filter > > out bot messages. > > > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > > > > > Igniters, > > > > > > We have a lot of threads, created by bots on the dev list. > > > Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, some > > > others too, but these are the most active. > > > > > > Take a look at this page: > > > http://apache-ignite-developers.2346864.n4.nabble. > > > com/Apache-Ignite-Developers-f1i35.html > > > It's hard to find actual discussions in this mess. I'd like to see > > > something like what we have on the users list: > > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > > > It doesn't seem necessary to me to mix discussions with this cryptic > flow > > > of information. > > > Can we create a separate mailing list for bots? > > > > > > Denis > > > > > > -- > -- > Maxim Muzafarov >
Re: TeamCity's security certificate expired
Thank you. 2018-08-29 13:33 GMT+03:00 Alexey Goncharuk : > Certificates are updated, TC is up and running. > > ср, 29 авг. 2018 г. в 12:55, Dmitrii Ryabov : > > > Hi, Igniters! > > > > Who can refresh TeamCity's security certificate? > > >
[jira] [Created] (IGNITE-9411) Lock: make sure lock timeouts works fine
Vladimir Ozerov created IGNITE-9411: --- Summary: Lock: make sure lock timeouts works fine Key: IGNITE-9411 URL: https://issues.apache.org/jira/browse/IGNITE-9411 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov Fix For: 2.7 In SQL it is not uncommon that locks are taken in arbitrary order, what may lead to deadlocks. Fair deadlock detector is good solution in monolithic databases - just analyze dependency graph and kill one of conflicting transactions. We have a ticket to implement distributed deadlock detector in Ignite [1]. However, this solution is rather complex and may bring some overhead. For now it is better to rely on some timeout (global or per-transaction), and rollback TX when it fails to lock certain entry for a long time. Probably we already have this feature in some form. Need to add verify that it works and add more tests if needed. [1] https://issues.apache.org/jira/browse/IGNITE-9322 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9410) MVCC: add support to thin clients
Vladimir Ozerov created IGNITE-9410: --- Summary: MVCC: add support to thin clients Key: IGNITE-9410 URL: https://issues.apache.org/jira/browse/IGNITE-9410 Project: Ignite Issue Type: Task Components: mvcc, thin client Reporter: Vladimir Ozerov Fix For: 2.8 Currently only ODBC and JDBC drivers support transactions. We need to add transactional API to .NET, Java, CPP, NodeJS and Python clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: TeamCity's security certificate expired
Certificates are updated, TC is up and running. ср, 29 авг. 2018 г. в 12:55, Dmitrii Ryabov : > Hi, Igniters! > > Who can refresh TeamCity's security certificate? >
[GitHub] ignite pull request #4640: IGNITE-9402
GitHub user akalash opened a pull request: https://github.com/apache/ignite/pull/4640 IGNITE-9402 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9402 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4640.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 #4640 commit b145bb9521e94a1dd8da6775bd44d436cf41ae1b Author: Anton Kalashnikov Date: 2018-08-28T15:06:04Z IGNITE-9402 rewrited testRecoveringOnWALWritingFail2 commit f43c06a1148eb3bb3640561fb31094b10cb8a42d Author: Anton Kalashnikov Date: 2018-08-29T10:00:20Z IGNITE-9402 added message to assert commit d539ce0dc1023ee0a0b47ee7e1fbc8551f0738de Author: Anton Kalashnikov Date: 2018-08-29T10:01:34Z IGNITE-9402 remove tests from suit for test ---
TeamCity's security certificate expired
Hi, Igniters! Who can refresh TeamCity's security certificate?
Re: Bots on dev list
Denis, I would like to keep a single entry point into the whole Ignite development process project, but maybe other Igniters have another opinion on this. As for me, it's a more convenient way for searching any activity on dev.list by single keyword (e.g. PRs, JIRAs, topics). As mentioned Dmitry, you can configure your mail agent for grouping or moving bot messages into the separate directory. These messages have predefined topic names and can be easily filtered. On Wed, 29 Aug 2018 at 12:26 Dmitrii Ryabov wrote: > Modern mail services allow users to filter messages. You can easily filter > out bot messages. > > 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > > > Igniters, > > > > We have a lot of threads, created by bots on the dev list. > > Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, some > > others too, but these are the most active. > > > > Take a look at this page: > > http://apache-ignite-developers.2346864.n4.nabble. > > com/Apache-Ignite-Developers-f1i35.html > > It's hard to find actual discussions in this mess. I'd like to see > > something like what we have on the users list: > > http://apache-ignite-users.70518.x6.nabble.com/ > > > > It doesn't seem necessary to me to mix discussions with this cryptic flow > > of information. > > Can we create a separate mailing list for bots? > > > > Denis > > > -- -- Maxim Muzafarov
[jira] [Created] (IGNITE-9409) yarn IgniteProvider uses an obsolete URL for a version check
Roman Shtykh created IGNITE-9409: Summary: yarn IgniteProvider uses an obsolete URL for a version check Key: IGNITE-9409 URL: https://issues.apache.org/jira/browse/IGNITE-9409 Project: Ignite Issue Type: Bug Reporter: Roman Shtykh Assignee: Roman Shtykh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Apache Ignite 2.7 release
Nikolay, I think we should have 2 weeks after code freeze which by the way may include RC1 voting stage. This way I would like us to agree that release candidate should be sent to vote on Oct, 11th and we can release on Oct, 15th. What do you think? --Yakov
[jira] [Created] (IGNITE-9408) Update mesos version
Roman Shtykh created IGNITE-9408: Summary: Update mesos version Key: IGNITE-9408 URL: https://issues.apache.org/jira/browse/IGNITE-9408 Project: Ignite Issue Type: Task Reporter: Roman Shtykh Assignee: Roman Shtykh 0.22.0 is being used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Bots on dev list
Modern mail services allow users to filter messages. You can easily filter out bot messages. 2018-08-29 11:48 GMT+03:00 Denis Mekhanikov : > Igniters, > > We have a lot of threads, created by bots on the dev list. > Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, some > others too, but these are the most active. > > Take a look at this page: > http://apache-ignite-developers.2346864.n4.nabble. > com/Apache-Ignite-Developers-f1i35.html > It's hard to find actual discussions in this mess. I'd like to see > something like what we have on the users list: > http://apache-ignite-users.70518.x6.nabble.com/ > > It doesn't seem necessary to me to mix discussions with this cryptic flow > of information. > Can we create a separate mailing list for bots? > > Denis >
[GitHub] ignite pull request #4639: IGNITE-9388: mesos IgniteProvider tries to access...
GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/4639 IGNITE-9388: mesos IgniteProvider tries to access obsolete ignite.run⦠⦠or downloads from slow archive. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite IGNITE-9388 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4639.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 #4639 commit 06d0a8b7474f7cebcb6d25c1ddf7223b5ce13c2d Author: shroman Date: 2018-08-29T09:17:16Z IGNITE-9388: mesos IgniteProvider tries to access obsolete ignite.run or downloads from slow archive. ---
[jira] [Created] (IGNITE-9407) Node is hang when it was stopping from several client in one time
Anton Kalashnikov created IGNITE-9407:
-
Summary: Node is hang when it was stopping from several client in
one time
Key: IGNITE-9407
URL: https://issues.apache.org/jira/browse/IGNITE-9407
Project: Ignite
Issue Type: Test
Reporter: Anton Kalashnikov
Reproduced by IgniteChangeGlobalStateTest#testFailGetLock
{noformat}
[2018-08-27
19:00:29,463][ERROR][sys-#32068%node0-backUp-client%][GridClosureProcessor]
Closure execution failed with error.
[22:00:29]W: [org.apache.ignite:ignite-core]
java.lang.AssertionError: ignite-sys-cache
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.internalCacheEx(GridCacheProcessor.java:3847)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.utilityCache(GridCacheProcessor.java:3829)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.service.GridServiceProcessor.updateUtilityCache(GridServiceProcessor.java:298)
[22:00:29] : [Step 3/4] [2018-08-27 19:00:29,463][INFO
][sys-#32069%node2-backUp-client%][GridCacheProcessor] Stopped cache
[cacheName=ignite-sys-cache]
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart0(GridServiceProcessor.java:241)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onActivate(GridServiceProcessor.java:397)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor$6.run(GridClusterStateProcessor.java:1151)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6756)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[22:00:29]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[22:00:29]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[22:00:29]W: [org.apache.ignite:ignite-core]at
java.lang.Thread.run(Thread.java:748)
[22:00:29]W: [org.apache.ignite:ignite-core] [2018-08-27
19:00:29,469][ERROR][sys-#32068%node0-backUp-client%][GridClosureProcessor]
Runtime error caught during grid runnable execution: GridWorker
[name=closure-proc-worker, igniteInstanceName=node0-backUp-client,
finished=false, hashCode=669424318, interrupted=false,
runner=sys-#32068%node0-backUp-client%]
[22:00:29]W: [org.apache.ignite:ignite-core]
java.lang.AssertionError: ignite-sys-cache
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.internalCacheEx(GridCacheProcessor.java:3847)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.utilityCache(GridCacheProcessor.java:3829)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.service.GridServiceProcessor.updateUtilityCache(GridServiceProcessor.java:298)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart0(GridServiceProcessor.java:241)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onActivate(GridServiceProcessor.java:397)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor$6.run(GridClusterStateProcessor.java:1151)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6756)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
[22:00:29]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[22:00:29]W: [org.apache.ignite:ignite-core]at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[22:00:29]W: [org.apache.ignite:ignite-
[jira] [Created] (IGNITE-9406) Improve SQL "Performance and Debugging" page
Vladimir Ozerov created IGNITE-9406: --- Summary: Improve SQL "Performance and Debugging" page Key: IGNITE-9406 URL: https://issues.apache.org/jira/browse/IGNITE-9406 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Fix For: 2.7 Attachments: ignite_sql_perf.txt I prepared a document for one of Ignite clients with some advanced information about how various performance optimizations work in Ignite SQL. Let's compare this document with our "Performance and Debugging" page [1], and enhance the latter with missing info (if any). P.S.: Document is attached. Russian language. [1] https://apacheignite-sql.readme.io/docs/performance-and-debugging#query-execution-flow-optimizations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Bots on dev list
Igniters, We have a lot of threads, created by bots on the dev list. Currently messages are sent by JIRA, GitHub and MTCGA bots. Maybe, some others too, but these are the most active. Take a look at this page: http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-Developers-f1i35.html It's hard to find actual discussions in this mess. I'd like to see something like what we have on the users list: http://apache-ignite-users.70518.x6.nabble.com/ It doesn't seem necessary to me to mix discussions with this cryptic flow of information. Can we create a separate mailing list for bots? Denis
Re: Retries in write-behind store
Since the write-behind store wraps the store provided by a user, I think the correct solution would be to catch the exception and not propagate it further in the store, because only the end-user knows which errors can be retried, and which errors cannot. In this case no changes in the write-behind logic is needed. ср, 29 авг. 2018 г. в 7:14, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Folks, > > Is there a way to limit or disable retries of failed updates in the > write-behind store? I can't find one, it looks like if an update fails, it > is moved to the end of the queue and then eventually retried. If it fails > again, process is repeated. > > Such behavior *might* be OK if failures are caused by database being > temporarily unavailable. But what if update fails deterministically, for > example due to a constraint violation? There is absolutely no reason to > retry it, and at the same time it can cause stability and performance > issues when buffer is full with such "broken" updates. > > Does it makes sense to add an option that would allow to limit number of > retries (or even disable them)? > > -Val >
[jira] [Created] (IGNITE-9405) Update documentation for metrics for remains to evict keys/partitions
Alexey Goncharuk created IGNITE-9405: Summary: Update documentation for metrics for remains to evict keys/partitions Key: IGNITE-9405 URL: https://issues.apache.org/jira/browse/IGNITE-9405 Project: Ignite Issue Type: Task Components: documentation Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Retries in write-behind store
Also in addition to that how about generating event when updates are failed which can be listened to and custom logic can be added to handle the failures? On Wed, Aug 29, 2018 at 6:56 AM, Denis Magda wrote: > Val, > > Sounds like a handy configuration option. I would allow setting a number of > retries. If the number is set to 0 then a failed update is discarded right > away. > > -- > Denis > > On Tue, Aug 28, 2018 at 9:14 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Folks, > > > > Is there a way to limit or disable retries of failed updates in the > > write-behind store? I can't find one, it looks like if an update fails, > it > > is moved to the end of the queue and then eventually retried. If it fails > > again, process is repeated. > > > > Such behavior *might* be OK if failures are caused by database being > > temporarily unavailable. But what if update fails deterministically, for > > example due to a constraint violation? There is absolutely no reason to > > retry it, and at the same time it can cause stability and performance > > issues when buffer is full with such "broken" updates. > > > > Does it makes sense to add an option that would allow to limit number of > > retries (or even disable them)? > > > > -Val > > >
Re: Apache Ignite 2.7 release
Denis, Nikolai, Suppose, issue IGNITE-7165 [1] is already included in the release scope, but I think I can mention it here. It's about re-balance optimization - now client node join\left doesn't affect re-balance process. In general, it's not so much about client node as about if assignments not change re-balance will not be interrupted. I've provided all implementation details in JIRA comment [2]. Hope it will help someone with further optimizations. [1] https://issues.apache.org/jira/browse/IGNITE-7165 [2] https://issues.apache.org/jira/browse/IGNITE-7165?focusedCommentId=16561092&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16561092 On Wed, 29 Aug 2018 at 02:43 Denis Magda wrote: > Nikolay, Igniters, let me help you with the list. > > That what I was tracking on my side (something we can announce). Don't have > a JIRA ticket for every ticket but CC-ed everyone who claimed to be in > charge. Nikolay, please work with the community members to add these > capabilities to the release wiki page. If something doesn't get delivered > then let's exclude it. > > 1. Partition map exchange optimizations. Are we releasing any of them? > *(Sergey > Chugunov, Andrey Mashenkov)* > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-25%3A+Partition+Map+Exchange+hangs+resolving > > 2. Java 9/10/11 Support. Are we on track to support it better? *(Peter, > Vladimir)*. > > 3. SQL *(Vladimir)*: > >- Transactional SQL beta? >- Basic monitoring facilities (inline index alerts, page reads/writes >per type)? >- SQL index update optimizations? ( > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-19%3A+SQL+index+update+optimizations >) >- ODBC/JDBC session management >- Result set offload to disk. Looks it doesn't get to the release? >https://issues.apache.org/jira/browse/IGNITE-7526 > > 4. JCache 1.1 support. Completed! > > 5. Transparent data encryption? What exactly goes in 2.7? *(Nikolay)*. > > 6. Ignite + Informatica integration > > 7. Ignite and Spring Session integration (heard it was done but the ticket > is still Open): > https://issues.apache.org/jira/browse/IGNITE-2741 > > 8. Service Grid 2.0. What exactly goes in 2.7? (*Vyacheslav)* > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid > > 9. Ignite Multi Map *(Amir, Anton)* > https://issues.apache.org/jira/browse/IGNITE-640 > > 10. Thin Clients: > >- Node.JS (https://issues.apache.org/jira/browse/IGNITE-) - *Pavel >Petroshenko* >- Python (https://issues.apache.org/jira/browse/IGNITE-7782) - *Pavel >Petroshenko, **Dmitry Melnichuk* >- PHP (https://issues.apache.org/jira/browse/IGNITE-7783) - *Pavel P., >Ekaterina* >- C++: *Igor S.* >- Affinity awareness for thin clients (*Igor S.*): > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > 11. Machine and Deep Learning (preprocessing APIs, TensorFlow integration, > extra algorithms) - *Yuri and our ML experts* > > > > On Tue, Aug 28, 2018 at 10:17 AM Dmitriy Setrakyan > wrote: > > > Hi Nikolai, > > > > Generally looks OK, however, It is hard to comment on your schedule > without > > seeing a full list of all must-have features we plan to add to this > > release. I am hoping that the community will see this list at some point. > > > > D. > > > > On Tue, Aug 28, 2018 at 8:23 AM, Nikolay Izhikov > > wrote: > > > > > Hello, Igniters. > > > > > > I think we should discuss the release schedule. > > > > > > Current dates are following: > > > > > > * Code Freeze: September 30, 2018 > > > * Voting Date: October 1, 2018 > > > * Release Date: October 15, 2018 > > > > > > We discussed it privately with Vladimir Ozerov. > > > > > > Is seems better to reschedule a bit: > > > > > > * Scope freeze - September 17 - We should have a full list of > > > tickets for 2.7 here. > > > * Code freeze - October 01 - We should merge all 2.7 tickets to > > > master here. > > > * Vote - October 08. > > > > > > What do you think? > > > > > > > > > В Сб, 25/08/2018 в 00:57 +0300, Dmitriy Pavlov пишет: > > > > I hope Vyacheslav can comment better than me. I suppose it is, more > or > > > > less, rectifications and clarifications of design aspects. Not > overall > > > > redesign. > > > > > > > > I also hope Igniters, especially Services experts, will join the > > > discussion > > > > in the separate topic. Now after a couple of days there is no > reaction. > > > > > > > > сб, 25 авг. 2018 г. в 0:53, Dmitriy Setrakyan >: > > > > > > > > > On Fri, Aug 24, 2018 at 2:50 PM, Dmitriy Pavlov < > > dpavlov@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > Hi Dmitriy, I suppose it highly depends on how fast community > will > > > come > > > > > > > > > > to > > > > > > a consensus about design. So it is up to us to make this happen > > > > > > > > > > > > > > > > I am confused then. If we are s
[jira] [Created] (IGNITE-9404) Ignite start hangs infinitely when sync preloading is cancelled
Ivan Pavlukhin created IGNITE-9404:
--
Summary: Ignite start hangs infinitely when sync preloading is
cancelled
Key: IGNITE-9404
URL: https://issues.apache.org/jira/browse/IGNITE-9404
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.6
Reporter: Ivan Pavlukhin
This case fires very rarely in {{TcpDiscoveryRestartTest.testRestart}}. Caches
with {{SYNC}} rebalance mode are affected. When **starting** instance is trying
to preload partitions for such cache from another instance which **stops**
around the same time, first instance could hang infinitely. When {{SYNC}}
rebalance mode is enabled starting instance awaits on **preload future** in
start routine. In another thread it starts fetching partitions and receives an
error from **stopping** instance and cancels **rebalance future** but **preload
future** is not cancelled.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
