[jira] [Created] (IGNITE-9244) Partition eviction may use all threads in sys pool, it leads to hangs send a message via sys pool

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-9244:
--

 Summary: Partition eviction may use all threads in sys pool, it 
leads to hangs send a message via sys pool 
 Key: IGNITE-9244
 URL: https://issues.apache.org/jira/browse/IGNITE-9244
 Project: Ignite
  Issue Type: Bug
 Environment: In the current implementation, GridDhtPartitionsEvictor 
reset partition to evict one by one.
GridDhtPartitionsEvictor is created for each cache group, if we try to evict 
too many groups as sys pool size, group evictors will take all available 
threads in sys pool. It leads to hangs send a message via sys pool. As a fix, I 
suggest to limit concurrent execution via sys pool or use another pool for this 
purpose.
Reporter: Dmitriy Govorukhin






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

[jira] [Created] (IGNITE-9245) Document how to monitor Ignite with Zabbix

[Artem Budnikov (JIRA)]

Artem Budnikov created IGNITE-9245:
--

 Summary: Document how to monitor Ignite with Zabbix 
 Key: IGNITE-9245
 URL: https://issues.apache.org/jira/browse/IGNITE-9245
 Project: Ignite
  Issue Type: Test
  Components: documentation
Reporter: Artem Budnikov
Assignee: Artem Budnikov


Create a how-to page with an instruction on how to use Zabbix templates to 
monitor Ignite metrics.



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

Re: Apache Ignite 2.7: scope, time and release manager

[Nikolay Izhikov]

Hello, Igniters.

We have 3 not assigned tickets for a 2.7 which is labeled "Important".
Who can pick up this tickets?

https://issues.apache.org/jira/browse/IGNITE-4191 - SQL: support transactions
https://issues.apache.org/jira/browse/IGNITE-5473 - Create ignite 
troubleshooting logger
https://issues.apache.org/jira/browse/IGNITE-6903 - Implement new JMX metrics 
for Indexing



В Вт, 31/07/2018 в 16:10 +0300, Petr Ivanov пишет:
> Fixed that.
> It seems that Heading 2 style was applied to some Jira macros.
> 
> 
> 
> > On 31 Jul 2018, at 16:06, Dmitriy Pavlov  wrote:
> > 
> > Hi Nikolay,
> > 
> > Thank you for this page. It seems font size for some filters is bigger than
> > for others. It is intentionally done this way?
> > 
> > Sincerely,
> > Dmitriy Pavlov
> > 
> > вт, 31 июл. 2018 г. в 15:57, Nikolay Izhikov :
> > 
> > > Hello, Igniters.
> > > 
> > > Release page created [1].
> > > 
> > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7
> > > 
> > > В Пт, 27/07/2018 в 00:52 -0700, Denis Magda пишет:
> > > > Sure, it can wait. Thanks! Take a rest )
> > > > 
> > > > On Thu, Jul 26, 2018 at 11:39 PM Nikolay Izhikov 
> > > > wrote:
> > > > 
> > > > > Hello, Denis.
> > > > > 
> > > > > Actually, I'm on vacation till July, 31.
> > > > > After it I will put all my efforts to manage Ignite release.
> > > > > 
> > > > > Can we wait until Tuesday?
> > > > > 
> > > > > В Чт, 26/07/2018 в 17:01 -0700, Denis Magda пишет:
> > > > > > Nikolay,
> > > > > > 
> > > > > > Could you please prepare Ignite 2.7 page similar to the following?
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> > > > > > 
> > > > > > We need to start tracking the progress and most essential
> > > 
> > > capabilities
> > > > > 
> > > > > that will get into the release.
> > > > > > 
> > > > > > --
> > > > > > Denis
> > > > > > On Tue, Jul 24, 2018 at 1:39 AM Vyacheslav Daradur <
> > > 
> > > daradu...@gmail.com>
> > > > > 
> > > > > wrote:
> > > > > > > Hi, Igniters!
> > > > > > > 
> > > > > > > The end of September for Ignite 2.7 release sounds good to me.
> > > > > > > 
> > > > > > > I'm working on Service Grid and going to deliver the following
> > > 
> > > tasks:
> > > > > > > - Use discovery messages for service deployment [[1]
> > > > > > > - Collect service deployment results asynchronously on coordinator
> > > 
> > > [2]
> > > > > > > - Propagate service deployment results from assigned nodes to
> > > > > 
> > > > > initiator [3]
> > > > > > > - Handle topology changes during service deployment [4]
> > > > > > > - Propagate deployed services to joining nodes [5]
> > > > > > > - Replace service instance parameter with a class name in
> > > > > > > ServiceConfiguration [6] (planned to be implemented by Amelchev
> > > > > > > Nikita)
> > > > > > > 
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8361
> > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-8362
> > > > > > > [3] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-8363
> > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-8364
> > > > > > > [6] https://issues.apache.org/jira/browse/IGNITE-8366
> > > > > > > On Mon, Jul 23, 2018 at 4:02 PM Dmitry Pavlov <
> > > 
> > > dpavlov@gmail.com>
> > > > > 
> > > > > wrote:
> > > > > > > > 
> > > > > > > > Hi Denis, Nikolay,
> > > > > > > > 
> > > > > > > > I've issued a number of tickets to update dependencies versions.
> > > 
> > > I
> > > > > 
> > > > > would
> > > > > > > > like all these updates are available within 2.7.
> > > > > > > > 
> > > > > > > > Sincerely,
> > > > > > > > Dmitriy Pavlov
> > > > > > > > 
> > > > > > > > сб, 21 июл. 2018 г. в 3:28, Pavel Petroshenko <
> > > 
> > > pa...@petroshenko.com
> > > > > > 
> > > > > > :
> > > > > > > > 
> > > > > > > > > Hi Denis, Nikolay,
> > > > > > > > > 
> > > > > > > > > The proposed 2.7 release timing sounds reasonable to me.
> > > > > > > > > Python [1], PHP [2], and Node.js [3] thin clients should take
> > > 
> > > the
> > > > > 
> > > > > train.
> > > > > > > > > 
> > > > > > > > > p.
> > > > > > > > > 
> > > > > > > > > [1] https://jira.apache.org/jira/browse/IGNITE-7782
> > > > > > > > > [2] https://jira.apache.org/jira/browse/IGNITE-7783
> > > > > > > > > [3] https://jira.apache.org/jira/browse/IGNITE-
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Fri, Jul 20, 2018 at 2:35 PM, Denis Magda <
> > > 
> > > dma...@gridgain.com>
> > > > > 
> > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > Igniters,
> > > > > > > > > > 
> > > > > > > > > > Let's agree on the time and the scope of 2.7. As for the
> > > 
> > > release
> > > > > 
> > > > > manager,
> > > > > > > > > > we had a conversation with Nikolay Izhikov and he decided to
> > > 
> > > try
> > > > > 
> > > > > the role
> > > > > > > > > > out. Thanks, Nikolay!
> > > > > > > > > > 
> > > > > > > > > > Nikolay, we need to prepare a page like that [1] once 

Re: TDE: Upgrade Team City JDK

[Nikolay Izhikov]

Hello, Petr.

TDE tests succeed on "publicagent03_9091".

https://ci.ignite.apache.org/viewLog.html?buildId=1626049&buildTypeId=IgniteTests24Java8_BasicTestsWithPersistence&tab=testsInfo

> If everything is OK — I’ll distribute this Java among all other agents.

Can you do it?

В Чт, 09/08/2018 в 18:29 +0300, Petr Ivanov пишет:
> Done
> 
> 
> > On 9 Aug 2018, at 17:44, Nikolay Izhikov  wrote:
> > 
> > Petr.
> > 
> > Seems, now I has to put my tests in "Basic Tests With Persistence".
> > Can you configure Team city so I can run "Basic Tests With Persistence" on 
> > publicagent03_9091?
> > 
> > В Чт, 09/08/2018 в 16:35 +0300, Petr Ivanov пишет:
> > > Yeap.
> > > 
> > > As it is disabled, it will not take tasks from queue automatically, but 
> > > can be assigned tasks manually.
> > > 
> > > 
> > > > On 9 Aug 2018, at 16:27, Nikolay Izhikov  wrote:
> > > > 
> > > > Hello, Petr.
> > > > 
> > > > I'm able to select thi agent for build.
> > > > But it has "disabled" comment.
> > > > 
> > > > Is that OK?
> > > > 
> > > > https://ci.ignite.apache.org/viewQueued.html?itemId=1620053:0:153&tab=queuedBuildOverviewTab
> > > > 
> > > > В Ср, 08/08/2018 в 17:44 +0300, Petr Ivanov пишет:
> > > > > Nikolay,
> > > > > 
> > > > > 
> > > > > I’ve updated publicagent03_9091 and tested all current builds for 
> > > > > Ignite Tests 2.4+ project for master branch.
> > > > > Please test your PR on this agent (select it when starting build) for 
> > > > > correct java configuration.
> > > > > 
> > > > > If everything is OK — I’ll distribute this Java among all other 
> > > > > agents.
> > > > > 
> > > > > 
> > > > > 
> > > > > > On 31 Jul 2018, at 22:18, Petr Ivanov  wrote:
> > > > > > 
> > > > > > > 8u111.
> > > > > > 
> > > > > > I’ve started the process of update, will try to accomplish by the 
> > > > > > end of the week.
> > > > > > 
> > > > > > 
> > > > > > > On 31 Jul 2018, at 21:26, Denis Magda  wrote:
> > > > > > > 
> > > > > > > Nikolay,
> > > > > > > 
> > > > > > > Do you need 8u111 and later? Or any JDK 8 works for you?
> > > > > > > 
> > > > > > > --
> > > > > > > Denis
> > > > > > > 
> > > > > > > On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov 
> > > > > > >  wrote:
> > > > > > > 
> > > > > > > > Hello, Petr.
> > > > > > > > 
> > > > > > > > > What JDK is required for running this build?
> > > > > > > > 
> > > > > > > > 8u111 and later.
> > > > > > > > 
> > > > > > > > > I can filter agents with correct JDK for now.
> > > > > > > > 
> > > > > > > > Encryption tests are executed by following build plans:
> > > > > > > > 
> > > > > > > > * Basic 1
> > > > > > > > * Binary Objects (Simple Mapper Basic)
> > > > > > > > * Queries 1
> > > > > > > > * Spring
> > > > > > > > 
> > > > > > > > В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
> > > > > > > > > No we cannot do it right now.
> > > > > > > > > 
> > > > > > > > > What JDK is required for running this build?
> > > > > > > > > I can filter agents with correct JDK for now.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > On 31 Jul 2018, at 16:35, Nikolay Izhikov 
> > > > > > > > > >  wrote:
> > > > > > > > > > 
> > > > > > > > > > Hello, Igniters.
> > > > > > > > > > 
> > > > > > > > > > I have to up this thread.
> > > > > > > > > > 
> > > > > > > > > > TDE. Phase 1 development is over.
> > > > > > > > > > But, I still can't run TDE tests on Team city [1].
> > > > > > > > > > 
> > > > > > > > > > I think that source of error is [2]
> > > > > > > > > > 
> > > > > > > > > > Can we upgrade Team City JDK?
> > > > > > > > > > 
> > > > > > > > > > [1]
> > > > > > > > 
> > > > > > > > https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1566703&_focus=446976
> > > > > > > > > > [2] https://bugs.openjdk.java.net/browse/JDK-8149411
> > > > > > > > > > 
> > > > > > > > > > В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
> > > > > > > > > > > Hi.
> > > > > > > > > > > 
> > > > > > > > > > > > can we add option enables AES 128
> > > > > > > > > > > 
> > > > > > > > > > > Currently, 128 bit key used [1]
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > I guess we should update environment to meet test 
> > > > > > > > > > > > requirements
> > > > > > > > 
> > > > > > > > prior putting changes to master.
> > > > > > > > > > > 
> > > > > > > > > > > Yes.
> > > > > > > > > > > 
> > > > > > > > > > > [1]
> > > > > > > > 
> > > > > > > > https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> > > > > > > > > > > > Hi Nikolay,
> > > > > > > > > > > > 
> > > > > > > > > > > > can we add option enables AES 128 for test mode? This 
> > > > > > > > > > > > should work
> > > > > > > > 
> > > > > > > > well
> > > > > > > > > > > > without update env.
> > > > > > > > > > > > 
> > > > > > > > > > > > Sincerely,
> > > > > 

Re: TDE: Upgrade Team City JDK

[Petr Ivanov]

Nikolay, thanks for helping with tests.


I will proceed with Java updates. Will notify when finished.




> On 10 Aug 2018, at 11:37, Nikolay Izhikov  wrote:
> 
> Hello, Petr.
> 
> TDE tests succeed on "publicagent03_9091".
> 
> https://ci.ignite.apache.org/viewLog.html?buildId=1626049&buildTypeId=IgniteTests24Java8_BasicTestsWithPersistence&tab=testsInfo
> 
>> If everything is OK — I’ll distribute this Java among all other agents.
> 
> Can you do it?
> 
> В Чт, 09/08/2018 в 18:29 +0300, Petr Ivanov пишет:
>> Done
>> 
>> 
>>> On 9 Aug 2018, at 17:44, Nikolay Izhikov  wrote:
>>> 
>>> Petr.
>>> 
>>> Seems, now I has to put my tests in "Basic Tests With Persistence".
>>> Can you configure Team city so I can run "Basic Tests With Persistence" on 
>>> publicagent03_9091?
>>> 
>>> В Чт, 09/08/2018 в 16:35 +0300, Petr Ivanov пишет:
 Yeap.
 
 As it is disabled, it will not take tasks from queue automatically, but 
 can be assigned tasks manually.
 
 
> On 9 Aug 2018, at 16:27, Nikolay Izhikov  wrote:
> 
> Hello, Petr.
> 
> I'm able to select thi agent for build.
> But it has "disabled" comment.
> 
> Is that OK?
> 
> https://ci.ignite.apache.org/viewQueued.html?itemId=1620053:0:153&tab=queuedBuildOverviewTab
> 
> В Ср, 08/08/2018 в 17:44 +0300, Petr Ivanov пишет:
>> Nikolay,
>> 
>> 
>> I’ve updated publicagent03_9091 and tested all current builds for Ignite 
>> Tests 2.4+ project for master branch.
>> Please test your PR on this agent (select it when starting build) for 
>> correct java configuration.
>> 
>> If everything is OK — I’ll distribute this Java among all other agents.
>> 
>> 
>> 
>>> On 31 Jul 2018, at 22:18, Petr Ivanov  wrote:
>>> 
 8u111.
>>> 
>>> I’ve started the process of update, will try to accomplish by the end 
>>> of the week.
>>> 
>>> 
 On 31 Jul 2018, at 21:26, Denis Magda  wrote:
 
 Nikolay,
 
 Do you need 8u111 and later? Or any JDK 8 works for you?
 
 --
 Denis
 
 On Tue, Jul 31, 2018 at 6:55 AM Nikolay Izhikov  
 wrote:
 
> Hello, Petr.
> 
>> What JDK is required for running this build?
> 
> 8u111 and later.
> 
>> I can filter agents with correct JDK for now.
> 
> Encryption tests are executed by following build plans:
> 
>* Basic 1
>* Binary Objects (Simple Mapper Basic)
>* Queries 1
>* Spring
> 
> В Вт, 31/07/2018 в 16:45 +0300, Petr Ivanov пишет:
>> No we cannot do it right now.
>> 
>> What JDK is required for running this build?
>> I can filter agents with correct JDK for now.
>> 
>> 
>> 
>>> On 31 Jul 2018, at 16:35, Nikolay Izhikov  
>>> wrote:
>>> 
>>> Hello, Igniters.
>>> 
>>> I have to up this thread.
>>> 
>>> TDE. Phase 1 development is over.
>>> But, I still can't run TDE tests on Team city [1].
>>> 
>>> I think that source of error is [2]
>>> 
>>> Can we upgrade Team City JDK?
>>> 
>>> [1]
> 
> https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=1566703&_focus=446976
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8149411
>>> 
>>> В Ср, 27/06/2018 в 18:50 +0300, Nikolay Izhikov пишет:
 Hi.
 
> can we add option enables AES 128
 
 Currently, 128 bit key used [1]
 
 
> I guess we should update environment to meet test requirements
> 
> prior putting changes to master.
 
 Yes.
 
 [1]
> 
> https://github.com/apache/ignite/pull/4167/files#diff-1088ffe504f1aa300830e1ae9c030de1R80
 
 
 В Ср, 27/06/2018 в 18:44 +0300, Dmitry Pavlov пишет:
> Hi Nikolay,
> 
> can we add option enables AES 128 for test mode? This should work
> 
> well
> without update env.
> 
> Sincerely,
> 
> ср, 27 июн. 2018 г. в 18:43, Petr Ivanov :
> 
>> 
>> 
>>> On 27 Jun 2018, at 18:06, Nikolay Izhikov 
> 
> wrote:
>>> 
>>> Hello, Eduard.
>>> 
 We should make suites which are restricted by agents to make
> 
> as small
>> 
>> as> possible.
>>> 
>>> Agree. That means we should enable java cryptography on all
> 
> agents.
>> 
>> Isn't i

[GitHub] ignite pull request #4512: fail create cache on client node

[dgarus]

GitHub user dgarus opened a pull request:

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

fail create cache on client node



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

$ git pull https://github.com/dgarus/ignite create_cache_fail_on_client

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

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


commit 173e647b9714e93e90dbc3a59da5169ec5063c0b
Author: Garus Denis 
Date:   2018-08-10T09:18:38Z

fail create cache on client node




---

[jira] [Created] (IGNITE-9246) Optimistic transactions can wait for topology future on remap for a long time even if timeout is set.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-9246:
-

 Summary: Optimistic transactions can wait for topology future on 
remap for a long time even if timeout is set.
 Key: IGNITE-9246
 URL: https://issues.apache.org/jira/browse/IGNITE-9246
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov


This is possible if long PME is occured during tx remap phase.

Fix: wait for new topology on remap with timeout if set.



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

An error of creation of dynamic cache on a client node

[Denis Garus]

Hi, Igniters!

Currently, errors of creation dynamic caches on server nodes and client
nodes are different. 
If an error occurs on a server node, all cache nodes should revert the
changes [1]. 
If an error occurred on a client node, the client reverts the changes,
servers nodes start cache. 
In that case, the client node just throws the CacheException [2]. 

Is this way correct? 
Maybe we should stop the client node if an error of cache creation occurred
on it? 

[1] https://issues.apache.org/jira/browse/IGNITE-1094 
[2] the reproducer: https://github.com/apache/ignite/pull/4512/files 



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Metrics for MVCC caches

[Павлухин Иван]

Hi,

Dmitriy thanks for note, I will keep metrics IEP in mind.

Roman it sounds quite a straightforward approach. Moreover current cache
transactions follow it: there could be a number of invisible actions in
private workspace (e.g. creating and then deleting the same entry) but only
final changes are metered.

Also, I observed strange behavior for TRANSACTIONAL cache operations. For
following case metrics surprised me (numbers in comments):

public void testPutRemove() throws Exception {
cache.remove(1);
System.out.println(cache.metrics().getCacheRemovals()); // 1

cache.put(1, "a");

cache.remove(1);
System.out.println(cache.metrics().getCacheRemovals()); // 2
}

While for ATOMIC cache I see 0 and 1 which looks much better. And similar
effect is observed for "replace" operations.

Is it a bug? Do we have some document describing how metrics should be
counted?

2018-08-08 21:11 GMT+03:00 Dmitriy Setrakyan :

> I think we should be updating the IEP with metrics specifications in
> parallel.
>
> D.
>
> On Wed, Aug 8, 2018, 05:32 Roman Kondakov 
> wrote:
>
> > Hi Ivan!
> >
> > In my opinion we need to preserve the essence of the metrics: if we
> > didn't consider dirty writes as updates before MVCC implementation, we
> > also shouldn't count these writes in MVCC metrics implementation too.
> > So, I think we need to count only committed entries. But we can count
> > this dirty writes as additional metrics.
> >
> > Also additional metrics concerning MVCC could be:
> >
> > - Average count of the active transactions per snapshot
> >
> > - Average quantity of versions per key
> >
> >
> > --
> >
> > Roman Kondakov
> >
> >
> > On 07.08.2018 17:17, Павлухин Иван wrote:
> > > Hi Igniters,
> > >
> > > I am working on cache metrics support for caches with enabled MVCC. As
> > you
> > > may know, during MVCC transaction execution entry versions are written
> to
> > > storage right away (without deferring until commit). So, it is not
> > obvious
> > > for me if we should update writes count right away or defer it until
> > > commit. On one hand, MVCC entry version write is not "true" write until
> > > commit. On the other hand, it definitely changes the storage. How do we
> > > interpret write metrics in Ignite philosophy?
> > >
> > > Also, it seems that bunch of MVCC specific metrics could be
> introduced. I
> > > would like to collect some thoughts about it. Which such metrics come
> to
> > > your mind?
> > >
> >
> >
>



-- 
Best regards,
Ivan Pavlukhin

[GitHub] ignite pull request #4513: IGNITE-9244 Rework partition eviction.

[DmitriyGovorukhin]

GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-9244 Rework partition eviction.

- add evict shared manager
- concurrent evict partition from one group
- balanced executors by partition size
- limitation concurrent evict operation via permits counter

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

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

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

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


commit ab10ca99d7d7052414ef0927d52f17c81e5d7bde
Author: Dmitriy Govorukhin 
Date:   2018-08-10T10:10:12Z

IGNITE-9244 Rework partition eviction.
- add evict shared manager
- concurrent evict partition from one group
- balanced executors by partition size
- limitation concurrent evict operation via permits counter

Signed-off-by: Dmitriy Govorukhin 




---

[jira] [Created] (IGNITE-9247) CPP Thin: implement GetAll

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-9247:
--

 Summary: CPP Thin: implement GetAll
 Key: IGNITE-9247
 URL: https://issues.apache.org/jira/browse/IGNITE-9247
 Project: Ignite
  Issue Type: New Feature
  Components: thin client
Reporter: Stanislav Lukyanov


Need to implement GetAll in C++ Thin client.

Currently, there is no way to extract values from cache via C++ Thin client 
without knowing the keys beforehand. GetAll would be the easiest way to do that.



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

Re: Backup queue for local continuous query

[Andrey Mashenkov]

Hi Denis,

As my understanding right, to prevent potential OOM Local CQ either
shouldn't collect anything in backup queue or other nodes should send akcs.

Second way look strange as Local CQ runs on local node only and doesn't
care whats going on other nodes.
It is not clear what events and when other nodes should ack as they doesn't
participate in query?
When a primary node for a partition goes away and node with local CQ
running become a new primary
then seems, it make no sense to notify CQ with stale events from backup
queue and only new events make sense (as from new primary).

Instead of using backup queue we can notify CQ on backup events instantly
and let user filter out backup events if needed in listener.

So, I'd expect local query shouldn't involve remote nodes at all.
Also, I'm not sure we should filter out backup events. Can we let users to
do this in their listener code as it shouldn't costs for local CQ?





On Thu, Aug 2, 2018 at 3:35 PM Denis Mekhanikov 
wrote:

> Igniters,
>
> I noticed, that local continuous queries store queues with backup entries.
> And since the queries are local, other nodes never send acknowledges.
>
> It has two negative effects:
> 1) Backup queue may grow indefinitely and cause OOME.
> 2) When topology changes, the backup queue is flushed, and old
> notifications are delivered to the listener, even if they happened long
> time ago.
>
> I prepared a fix for it. You can find it in the ticket: IGNITE-9009
> 
> It makes local continuous queries ignore backup entries and not put them
> into the backup queues.
>
> Nikolay, Semyon,
> You are the people, who implemented this piece of functionality.
> Could you review these changes and share your opinion?
>
> I can think of another way to fix it: we could register
> *CacheContinuousQueryHandlers* on all nodes even for a local CQ, and make
> them send backup notifications to the subscriber node.
> It will help in cases, when you create local listeners on all nodes and
> want all nodes to process changes, that happen on their primary partitions.
> In this case backup entries may help not to lose updates. But actually it
> will leave a time window between sending a backup acknowledge and notifying
> the local listener. And such use-case will generate quadratic number of
> handlers and pollute the network communication.
>
> So, I prefer the first option.
>
> What do you think?
>
> Denis
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Removing "fabric" from Ignite binary package name

[Anton Vinogradov]

Peter,
I checked PR
Tests [1] seems to be ok
Comparision [2] with 2.6 seems to be ok
Sample result [3] - ok

Please check the rest.

[1]
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=ignite-7251
[2]
https://ci.ignite.apache.org/repository/download/ApacheIgniteReleaseJava8_NofabricPrepareVote2CompareWithPreviousRelease/1627255:id/results/result.log
[3]
https://ci.ignite.apache.org/viewLog.html?buildId=1615082&buildTypeId=ApacheIgniteReleaseJava8_NofabricPrepareVote1JavaNetCCompleteAssembly&tab=artifacts#!-1ezndiu3o89to,-lja97u2cm2u1

пн, 6 авг. 2018 г. в 12:41, Anton Vinogradov :

> Assigned issue to myself.
> Going to start implementation this week.
>
> сб, 4 авг. 2018 г. в 22:20, Petr Ivanov :
>
>> Thats all for Anton only, my role not worth mentioning.
>>
>>
>>
>> > On 4 Aug 2018, at 08:12, Denis Magda  wrote:
>> >
>> > Anton, Peter, thanks a lot! We all owe you a jar of beer and chocolate
>> (?)
>> > ;) Send me an invoice and I'll pay for it :)
>> >
>> > --
>> > Denis
>> >
>> > On Fri, Aug 3, 2018 at 7:32 AM Petr Ivanov  wrote:
>> >
>> >> Yeap. When PR will be ready, I’ll start updating build configurations.
>> >>
>> >>
>> >>> On 3 Aug 2018, at 17:28, Anton Vinogradov  wrote:
>> >>>
>> >>> I can perform proper refactoring by myself.
>> >>>
>> >>> Peter, could you assist me with TC in that case?
>> >>>
>> >>> пт, 3 авг. 2018 г. в 17:17, Dmitriy Setrakyan > >:
>> >>>
>>  Agree with Denis. Let's do the simple refactoring first, and then
>> more
>>  complicated one in phase 2.
>> 
>>  On Fri, Aug 3, 2018 at 6:47 AM, Denis Magda 
>> wrote:
>> 
>> >>
>> >> Thus, my suggestion is:
>> >> — find and update all hardcoded “fabric” usage on TC, so that they
>>  work
>> >> both with or without fabric in name of binaries
>> >> — use current implementation — review and merge to master
>> >> — plan full suffix refactoring (as Anton suggests) on the next
>> > iterations
>> >> with no rush
>> >
>> >
>> > I like this plan which allows us to do the things. I see the current
>> > implementation as one of the steps of the overall refactoring
>> proposed
>> >> by
>> > Anton. It sounds normal if we split refactoring into pieces.
>> >
>> > Anton, do you have time to help with the rest of refactoring tasks
>> >> before
>> > AI 2.7? It's great if we close the whole tasks by that time.
>> Otherwise,
>> > let's split it and release the current implementation first.
>> >
>> > --
>> > Denis
>> >
>> > On Fri, Aug 3, 2018 at 1:18 AM Petr Ivanov 
>> >> wrote:
>> >
>> >> Dmitriy,
>> >>
>> >> I cannot forecast estimates for this task as it dependents on many
>> > factors:
>> >> — I will be able to start researching the Anton’s implementation
>> >> suggestion not earlier than the beginning of September
>> >> — I am not acquainted with assembly configuration well, it may take
>>  some
>> >> considerable time to understand how correctly get rid of “fabric”
>> not
>> >> touching everything else
>> >> — the process of review and merge can also drag on indefinitely
>> (based
>> > on
>> >> the previous attempt to introduce this changes)
>> >>
>> >>
>> >> Vladimir,
>> >>
>> >> If community will approve this hack, I’ll implement it.
>> >> Yet it won’t resolve the problem of building from sources not on
>> TC —
>>  the
>> >> fabric will stay in names of binaries and folders inside.
>> >> And it will add problems when the correct implementation will be
>> >> introduced.
>> >>
>> >>
>> >>
>> >> Thus, my suggestion is:
>> >> — find and update all hardcoded “fabric” usage on TC, so that they
>>  work
>> >> both with or without fabric in name of binaries
>> >> — use current implementation — review and merge to master
>> >> — plan full suffix refactoring (as Anton suggests) on the next
>> > iterations
>> >> with no rush
>> >>
>> >>
>> >>
>> >>> On 3 Aug 2018, at 09:50, Vladimir Ozerov 
>>  wrote:
>> >>>
>> >>> Folks,
>> >>>
>> >>> Can you please explain the problem with TC and artifacts? Can we
>> just
>> >>> rename final artifact at the end of a build phase just before
>>  signing,
>> >> and
>> >>> leave the rest TC infrastructure as is?
>> >>>
>> >>> On Fri, Aug 3, 2018 at 12:28 AM Dmitriy Setrakyan <
>> > dsetrak...@apache.org
>> >>>
>> >>> wrote:
>> >>>
>>  Anton, Petr,
>> 
>>  Thanks for your readiness to assist. Can this be done for 2.7
>>  release?
>> 
>>  D.
>> 
>>  On Thu, Aug 2, 2018 at 1:32 AM, Anton Vinogradov 
>> > wrote:
>> 
>> > What I see is that we spent almost a year discussing how to do
>>  this.
>> > I'm pretty sure we had enough time to do everything properly.
>> 

[GitHub] ignite pull request #4446: IGNITE-5103 - Server drops client node from clust...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9248) CPP: Support Clang compiler

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-9248:
---

 Summary: CPP: Support Clang compiler
 Key: IGNITE-9248
 URL: https://issues.apache.org/jira/browse/IGNITE-9248
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Igor Sapego
Assignee: Igor Sapego


Currently Ignite C++ can not be compiled with the clang compiler.



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

[GitHub] ignite pull request #4514: IGNITE-9171 Use lazy mode with results pre-fetch

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-9171 Use lazy mode with results pre-fetch



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

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

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

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


commit de324a59df6dcba2ec906fb974baf95dabd19504
Author: tledkov-gridgain 
Date:   2018-08-03T11:37:26Z

IGNITE-9171: save the progress

commit 63181f02cc950c49f93101e79682939949396675
Author: tledkov-gridgain 
Date:   2018-08-03T13:51:22Z

IGNITE-9171: save the progress

commit 8fec73450804fd1f9080dce7d000c8eefb0c6749
Author: tledkov-gridgain 
Date:   2018-08-03T14:35:23Z

Merge branch '_master' into ignite-9171

commit 260f3bf244fac0031fa4bb8d27aac365acfd43db
Author: tledkov-gridgain 
Date:   2018-08-06T09:22:39Z

IGNITE-9171: save the progress

commit f9bfdf76a791c0fa588d1a3a2a91bb349d7affd6
Author: tledkov-gridgain 
Date:   2018-08-06T09:35:42Z

Merge branch '_master' into ignite-9171

commit 59bf5ee665c460179aa961f9a3939b892f916dbc
Author: tledkov-gridgain 
Date:   2018-08-06T11:14:47Z

IGNITE-9171: save the progress

commit 83cca801e7547b032e7f3436ef22c979e72e04f0
Author: tledkov-gridgain 
Date:   2018-08-06T12:43:00Z

Merge branch '_master' into ignite-9171

commit bfb342cd0e35aad8c1c79044e0ebcde936c71806
Author: tledkov-gridgain 
Date:   2018-08-06T13:41:32Z

IGNITE-9171: save the progress

commit fe64dc2b22cf2f8e6b5d56068286dda1e6cc77fd
Author: tledkov-gridgain 
Date:   2018-08-07T12:30:24Z

IGNITE-9171: remove lazy worker

commit 98e4c57b795bc89c5b4a1c27f7f06f2cdbfc4dd4
Author: tledkov-gridgain 
Date:   2018-08-07T12:36:27Z

Merge branch '_master' into ignite-9171

commit 3ace9838ce13e3a08e5fdbe88101d2b61c40c718
Author: tledkov-gridgain 
Date:   2018-08-08T11:10:51Z

IGNITE-9171: benchmark

commit a3ee0f5f70d452f43de84a61832866ecd02e92da
Author: tledkov-gridgain 
Date:   2018-08-08T11:16:08Z

Merge branch '_master' into ignite-9171

commit b9a2ecfc6ac9f6c324ff0ab832899bb99ae46473
Author: tledkov-gridgain 
Date:   2018-08-08T13:13:07Z

IGNITE-9171: fix lazy mode

commit de71737b20e1683ff9d2078f1ba33a5843ccc541
Author: tledkov-gridgain 
Date:   2018-08-09T09:15:54Z

IGNITE-9171: save the progress

commit 51c15c81496c9b5dd8beebdf66087ea61a3324d9
Author: tledkov-gridgain 
Date:   2018-08-09T12:42:19Z

IGNITE-9171: save the progress

commit 75dbcc9872388b29758b56593fdc04d497d8d0ed
Author: tledkov-gridgain 
Date:   2018-08-10T08:04:25Z

IGNITE-9171: modify table lock

commit 18e198044d1806e2951b249977230d0dfaed7053
Author: tledkov-gridgain 
Date:   2018-08-10T08:14:28Z

IGNITE-9171: modify table lock - minors

commit f2188d118e9028a783bb2347d7ed15f7664828c0
Author: tledkov-gridgain 
Date:   2018-08-10T08:53:17Z

Merge branch '_master' into ignite-9171

commit 57e77782ce24d4f36843e89d9e81ab5d39eef4c1
Author: tledkov-gridgain 
Date:   2018-08-10T10:38:11Z

IGNITE-9171: minors

commit 79b2292733b3fb510ce38053b44512e25f143fa6
Author: tledkov-gridgain 
Date:   2018-08-10T12:35:32Z

Merge branch '_master' into ignite-9171




---

[GitHub] ignite pull request #4429: IGNITE-9050 WALIterator should throw an exception...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4499: IGNITE-9236 : Removed setting failureDetectionTim...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9249) Tests hang when different threads try to start and stop nodes at the same time.

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-9249:


 Summary: Tests hang when different threads try to start and stop 
nodes at the same time.
 Key: IGNITE-9249
 URL: https://issues.apache.org/jira/browse/IGNITE-9249
 Project: Ignite
  Issue Type: Bug
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh


An example of such test is 
GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest.testRestartWithPutFourNodesOneBackupsOffheapEvict().

Hanged threads:
{code}
"restart-worker-1@63424" prio=5 tid=0x7f5e nid=NA waiting
  java.lang.Thread.State: WAITING
  at java.lang.Object.wait(Object.java:-1)
  at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:949)
  at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:389)
  at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
  at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
  at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
  at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1754)
  at 
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1050)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
  - locked <0xfc36> (a 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
  at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:920)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:858)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:812)
  at 
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$1000(GridCacheAbstractNodeRestartSelfTest.java:64)
  at 
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:665)
  at java.lang.Thread.run(Thread.java:748)

"restart-worker-0@63423" prio=5 tid=0x7f5d nid=NA waiting
  java.lang.Thread.State: WAITING
  at sun.misc.Unsafe.park(Unsafe.java:-1)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
  at 
org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7584)
  at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1666)
  at 
org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1284)
  at 
org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1262)
  at org.apache.ignite.Ignition.allGrids(Ignition.java:502)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2258)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1158)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1133)
  at 
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1433)
  at 
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.access$800(GridCacheAbstractNodeRestartSelfTest.java:64)
  at 
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest$2.run(GridCacheAbstractNodeRestartSelfTest.java:661)
  at java.lang.Thread.run(Thread.java:748)
{code}

Full thread dump:
{code}
"test-runner-#26488%dht.GridCachePartitionedNearDisabledOptimisticTxNodeRestartTest%@63124"
 prio=5 tid=0x7e6a nid=NA waiting
  java.lang.Thread.State: WAITING
  at sun.misc.Unsafe.park(Unsafe.java:-1)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInte

[GitHub] ignite pull request #4515: IGNITE-9249 : Configured node join timeout for al...

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-9249 : Configured node join timeout for all tests.



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

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

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

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


commit 3be4dcc6da6649fb04f99f61c31cebb29d03c0fe
Author: Ilya Lantukh 
Date:   2018-08-10T13:23:28Z

IGNITE-9249 : Configured node join timeout for all tests.




---

[GitHub] ignite pull request #4145: IGNITE-8724 U.warn mislead implementation fix

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4516: gg-14053

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

gg-14053

For test purposes.
Fix mvcc tx handling.

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

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

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

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


commit a60d4aca9c23ebc56e8df9358c2db88c7383d59d
Author: devozerov 
Date:   2017-12-25T15:43:41Z

Fixed data page assert.

commit 6fc207501e89a399bdd88845211d948ffe800a8b
Author: Igor Seliverstov 
Date:   2017-12-26T12:48:34Z

IGNITE-7261 SQL TX: SELECT and DML operations must share the same MVCC 
version

commit 76e09f9d49d6688293f85624787fdc708fdc9fd3
Author: devozerov 
Date:   2017-12-26T14:06:34Z

Commented out failing TTL tests in "clients" suite.

commit f8368d90d1a41bda96ccde72ecae7d7752ea808b
Author: devozerov 
Date:   2017-12-26T15:29:28Z

Do not return removed values from cache key iterator.

commit 56b2d0b4fe6694a80650c666a8488a2fd99721db
Author: devozerov 
Date:   2017-12-26T13:36:18Z

Various checkpoint read lock/unlock fixes.

commit b489669049512867ed978c5a5963dce02ae63bc1
Author: Igor Seliverstov 
Date:   2017-12-26T15:38:31Z

Fix possible race

commit 6061f8e980d10acf8943d8a192475d875ebb
Author: Igor Seliverstov 
Date:   2017-12-26T16:31:56Z

Fix mvcc version gathering

commit 4cb890b67722727b54df3fbfbc9e218f5545652f
Author: devozerov 
Date:   2017-12-26T16:47:05Z

Fixed assertion during data streamer remove operation.

commit 1c9b01dcec374ce3fe19d25d2122142d3fe4b225
Author: Igor Seliverstov 
Date:   2017-12-26T23:15:12Z

Do not use key-value API for transactional DML requests

commit 37a2a7900b17909d81c89d54cb1dc2f00e5ab3fe
Author: Igor Seliverstov 
Date:   2017-12-26T23:17:54Z

Fix transaction close on first exception

commit 9d90d31b3db1da7b5c553468519c6cd12ac4de9e
Author: devozerov 
Date:   2017-12-27T09:45:12Z

Fixed partition-restricted scan queries.

commit b3e12fad2646e1f4bd9cef3a5009c0f72e966ca3
Author: Igor Seliverstov 
Date:   2017-12-27T09:50:07Z

Fix dml exception type

commit 66b7a115e27fe41b80eb5eea9fa8df1f15e597b3
Author: Igor Seliverstov 
Date:   2017-12-27T10:25:42Z

Build key in DML Insert iterator before checking partition.

commit 74f36c3a0c98bb550a425e9d3d4e220bdaf6b1f7
Author: Igor Seliverstov 
Date:   2017-12-27T11:11:34Z

Build key in DML Insert iterator before checking partition.

commit 6150d94c51b748fff361df32391131f1e68095e5
Author: Igor Seliverstov 
Date:   2017-12-27T11:32:58Z

Fix no query in update plan.

commit 2c212c18159848e413927dd05cf330e2be1cd97d
Author: Alexander Paschenko 
Date:   2017-12-27T11:49:11Z

IGNITE-7280: JDBC tests.

commit e50c81e9ec3597414d8dbe775626654e0dc86eb0
Author: Alexander Paschenko 
Date:   2017-12-27T13:06:00Z

IGNITE-7302: Fixed INFORMATIONAL_SCHEMA processing. This closes #3294.

commit 04f94948bbd89136d4555a2e3fccd9367169
Author: Igor Seliverstov 
Date:   2017-12-27T14:04:58Z

IGNITE-7321 DML operation hangs in case exception is thrown from DHT enlist 
future

commit 3818bc9d74b2bba594ef89cc2d1ac975da816b54
Author: Igor Seliverstov 
Date:   2017-12-27T14:33:18Z

fix tests.

commit eb7a615c9d32e648eceeafb09893b226fe276467
Author: Igor Seliverstov 
Date:   2017-12-27T14:47:39Z

fix exception types.

commit f4ce065ce863a741e0d14901e087ff69856b7d9f
Author: Alexander Paschenko 
Date:   2017-12-27T16:23:23Z

Merge branch 'master' into ignite-5571

commit 73bedeb4979d5474be654c6f8f80c168c9a0606f
Author: Alexander Paschenko 
Date:   2017-12-27T19:00:36Z

IGNITE-5571 More tests

commit ccf16fcc4d819e33b71a3322ae99d48755ee6b76
Author: Alexander Paschenko 
Date:   2017-12-28T07:49:25Z

IGNITE-7259: Fixed GridIndexRebuildSelfTest. This closes #3304.

commit 53466fc059d027edb24b3d7f5da05b6be2e997fc
Author: Igor Seliverstov 
Date:   2017-12-28T11:24:16Z

fix partition checking.

commit b9aa9ebca0dca79fec278415beb5753ef49a4c60
Author: Igor Seliverstov 
Date:   2017-12-29T12:18:30Z

fix mvcc version checking on lock acquire

commit a86af95ea1ee08c2f66751a8e2fc440e4671d686
Author: Igor Seliverstov 
Date:   2018-01-11T12:45:02Z

TODOs, right tickets numbers, minors

commit 59ba16afcab00326a60f53b3a7592d2978f19313
Author: Igor Seliverstov 
Date:   2018-01-11T14:45:53Z

Merge branch 'master' into ignite-4191-master

commit 79d876bce306802bf097a69030e1fcca61cec859
Author: Igor Seliverstov 
Date:   2018-01-11T14:49:22Z

Merge branch 'master' into ignite-4191-master

commit 9bd874c8d132f23842ae4bf8caa2c633b42b0789
Author: Igor Seliverstov 
Date:   2018-01-11T14:52:15Z

Merge branch 'master' into ignite-4191-master

# Conflicts:
#   
modules/indexing/sr

Re: Backup queue for local continuous query

[Denis Mekhanikov]

Andrey,

I also think, that remote nodes shouldn't be involved.

> Instead of using backup queue we can notify CQ on backup events instantly
This would be an incompatible change. It would break users' code, that
doesn't expect notifications on backup entries.
On the other hand, it would make our API more consistent, since CQ events
are triggered for all entries, if a cache is replicated.
We could add *CacheEntryEvent#isPrimary* property, that would let users
distinguish primary and backup events.

But since it would change behaviour, I'm inclined to just ignore events on
backup partitions.

What do you think?

Denis

пт, 10 авг. 2018 г. в 13:41, Andrey Mashenkov :

> Hi Denis,
>
> As my understanding right, to prevent potential OOM Local CQ either
> shouldn't collect anything in backup queue or other nodes should send akcs.
>
> Second way look strange as Local CQ runs on local node only and doesn't
> care whats going on other nodes.
> It is not clear what events and when other nodes should ack as they doesn't
> participate in query?
> When a primary node for a partition goes away and node with local CQ
> running become a new primary
> then seems, it make no sense to notify CQ with stale events from backup
> queue and only new events make sense (as from new primary).
>
> Instead of using backup queue we can notify CQ on backup events instantly
> and let user filter out backup events if needed in listener.
>
> So, I'd expect local query shouldn't involve remote nodes at all.
> Also, I'm not sure we should filter out backup events. Can we let users to
> do this in their listener code as it shouldn't costs for local CQ?
>
>
>
>
>
> On Thu, Aug 2, 2018 at 3:35 PM Denis Mekhanikov 
> wrote:
>
> > Igniters,
> >
> > I noticed, that local continuous queries store queues with backup
> entries.
> > And since the queries are local, other nodes never send acknowledges.
> >
> > It has two negative effects:
> > 1) Backup queue may grow indefinitely and cause OOME.
> > 2) When topology changes, the backup queue is flushed, and old
> > notifications are delivered to the listener, even if they happened long
> > time ago.
> >
> > I prepared a fix for it. You can find it in the ticket: IGNITE-9009
> > 
> > It makes local continuous queries ignore backup entries and not put them
> > into the backup queues.
> >
> > Nikolay, Semyon,
> > You are the people, who implemented this piece of functionality.
> > Could you review these changes and share your opinion?
> >
> > I can think of another way to fix it: we could register
> > *CacheContinuousQueryHandlers* on all nodes even for a local CQ, and make
> > them send backup notifications to the subscriber node.
> > It will help in cases, when you create local listeners on all nodes and
> > want all nodes to process changes, that happen on their primary
> partitions.
> > In this case backup entries may help not to lose updates. But actually it
> > will leave a time window between sending a backup acknowledge and
> notifying
> > the local listener. And such use-case will generate quadratic number of
> > handlers and pollute the network communication.
> >
> > So, I prefer the first option.
> >
> > What do you think?
> >
> > Denis
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: Pessimistic Mode and Transactions and 2PC

[Ilya Lantukh]

Hi John,

1. There is no "begin prepare" record, nodes acquire locks on TX keys and
then transfer local TX to PREPARED state.
2. TxRecord is logged when local TX state changes to PREPARED, COMMITED or
ROLLED_BACK before sending a response to what you call "coordinator" (in
Ignite we use the term "near node", because the term "coordinator" is
already used in another case).
3. Yes.

Hope this helps.

On Wed, Aug 8, 2018 at 6:29 PM, John Wilson  wrote:

> No they are not. I just want to understand.
>
> On Wednesday, August 8, 2018, Dmitriy Pavlov 
> wrote:
>
> > Hi John,
> >
> > Are these questions related to some contribution?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 8 авг. 2018 г. в 3:18, John Wilson :
> >
> > > Hi,
> > >
> > > Assume the following:
> > >
> > >
> > >- I have a transaction coordinator and two primary nodes with 0
> backup
> > >nodes.
> > >- Persistence store is enabled.
> > >- I'm running a transaction in pessimistic mode with serializable
> > >isolation.
> > >
> > > I have these questions:
> > >
> > >1. What exactly happens during the prepare phase? Only acquiring
> locks
> > >on the two primary nodes? Or do the primary nodes themselves, in
> > > addition
> > >to acquiring locks, write to their respective WAL a TxRecord with a
> > > "begin
> > >prepare" info?
> > >2. Assume locks have been acquired successfully, would the nodes
> then
> > >write a "prepared" TxRecord to WAL before returning a "Yes" vote to
> > >coordinator?
> > >3. When the coordinator sends a commit message, would each node
> write
> > >the key-values to the DataRecord and a commit to the TxRecord before
> > >returning to coordinator?
> > >
> > >
> > > Overall, I'm trying to understand what happens exactly during prepare
> and
> > > commit phases and when the key-values involved in the transaction are
> > > actually written; as well as the exact updates that are written to the
> > WAL
> > > files in each phase.
> > >
> > > appreciate your response.
> > >
> > > Thanks,
> > >
> >
>



-- 
Best regards,
Ilya

[jira] [Created] (IGNITE-9250) Replace CacheAffinitySharedManager.CachesInfo by ClusterCachesInfo

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-9250:
-

 Summary: Replace CacheAffinitySharedManager.CachesInfo by 
ClusterCachesInfo
 Key: IGNITE-9250
 URL: https://issues.apache.org/jira/browse/IGNITE-9250
 Project: Ignite
  Issue Type: Improvement
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Now we have duplicate of registerCaches(and groups). They holds in 
ClusterCachesInfo - main storage, and also they holds in 
CacheAffinitySharedManager.CachesInfo. It looks like redundantly and can lead 
to unconsistancy of caches info.



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

[GitHub] ignite pull request #4517: IGNITE-8559 Replace CacheAffinitySharedManager.Ca...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-8559 Replace CacheAffinitySharedManager.CachesInfo by ClusterC…

…achesInfo

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

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

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

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


commit ea4c1be40d5f621043994a04a0c1bd1f6e47914e
Author: Anton Kalashnikov 
Date:   2018-08-10T14:16:08Z

IGNITE-8559 Replace CacheAffinitySharedManager.CachesInfo by 
ClusterCachesInfo




---

Re: Apache Ignite 2.7: scope, time and release manager

[Andrey Gura]

Hi,

I believe we can just move this tickets to the next version.
On Fri, Aug 10, 2018 at 11:35 AM Nikolay Izhikov  wrote:
>
> Hello, Igniters.
>
> We have 3 not assigned tickets for a 2.7 which is labeled "Important".
> Who can pick up this tickets?
>
> https://issues.apache.org/jira/browse/IGNITE-4191 - SQL: support transactions
> https://issues.apache.org/jira/browse/IGNITE-5473 - Create ignite 
> troubleshooting logger
> https://issues.apache.org/jira/browse/IGNITE-6903 - Implement new JMX metrics 
> for Indexing
>
>
>
> В Вт, 31/07/2018 в 16:10 +0300, Petr Ivanov пишет:
> > Fixed that.
> > It seems that Heading 2 style was applied to some Jira macros.
> >
> >
> >
> > > On 31 Jul 2018, at 16:06, Dmitriy Pavlov  wrote:
> > >
> > > Hi Nikolay,
> > >
> > > Thank you for this page. It seems font size for some filters is bigger 
> > > than
> > > for others. It is intentionally done this way?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вт, 31 июл. 2018 г. в 15:57, Nikolay Izhikov :
> > >
> > > > Hello, Igniters.
> > > >
> > > > Release page created [1].
> > > >
> > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7
> > > >
> > > > В Пт, 27/07/2018 в 00:52 -0700, Denis Magda пишет:
> > > > > Sure, it can wait. Thanks! Take a rest )
> > > > >
> > > > > On Thu, Jul 26, 2018 at 11:39 PM Nikolay Izhikov 
> > > > > wrote:
> > > > >
> > > > > > Hello, Denis.
> > > > > >
> > > > > > Actually, I'm on vacation till July, 31.
> > > > > > After it I will put all my efforts to manage Ignite release.
> > > > > >
> > > > > > Can we wait until Tuesday?
> > > > > >
> > > > > > В Чт, 26/07/2018 в 17:01 -0700, Denis Magda пишет:
> > > > > > > Nikolay,
> > > > > > >
> > > > > > > Could you please prepare Ignite 2.7 page similar to the following?
> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.6
> > > > > > >
> > > > > > > We need to start tracking the progress and most essential
> > > >
> > > > capabilities
> > > > > >
> > > > > > that will get into the release.
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > > On Tue, Jul 24, 2018 at 1:39 AM Vyacheslav Daradur <
> > > >
> > > > daradu...@gmail.com>
> > > > > >
> > > > > > wrote:
> > > > > > > > Hi, Igniters!
> > > > > > > >
> > > > > > > > The end of September for Ignite 2.7 release sounds good to me.
> > > > > > > >
> > > > > > > > I'm working on Service Grid and going to deliver the following
> > > >
> > > > tasks:
> > > > > > > > - Use discovery messages for service deployment [[1]
> > > > > > > > - Collect service deployment results asynchronously on 
> > > > > > > > coordinator
> > > >
> > > > [2]
> > > > > > > > - Propagate service deployment results from assigned nodes to
> > > > > >
> > > > > > initiator [3]
> > > > > > > > - Handle topology changes during service deployment [4]
> > > > > > > > - Propagate deployed services to joining nodes [5]
> > > > > > > > - Replace service instance parameter with a class name in
> > > > > > > > ServiceConfiguration [6] (planned to be implemented by Amelchev
> > > > > > > > Nikita)
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8361
> > > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-8362
> > > > > > > > [3] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > > > > [4] https://issues.apache.org/jira/browse/IGNITE-8363
> > > > > > > > [5] https://issues.apache.org/jira/browse/IGNITE-8364
> > > > > > > > [6] https://issues.apache.org/jira/browse/IGNITE-8366
> > > > > > > > On Mon, Jul 23, 2018 at 4:02 PM Dmitry Pavlov <
> > > >
> > > > dpavlov@gmail.com>
> > > > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Denis, Nikolay,
> > > > > > > > >
> > > > > > > > > I've issued a number of tickets to update dependencies 
> > > > > > > > > versions.
> > > >
> > > > I
> > > > > >
> > > > > > would
> > > > > > > > > like all these updates are available within 2.7.
> > > > > > > > >
> > > > > > > > > Sincerely,
> > > > > > > > > Dmitriy Pavlov
> > > > > > > > >
> > > > > > > > > сб, 21 июл. 2018 г. в 3:28, Pavel Petroshenko <
> > > >
> > > > pa...@petroshenko.com
> > > > > > >
> > > > > > > :
> > > > > > > > >
> > > > > > > > > > Hi Denis, Nikolay,
> > > > > > > > > >
> > > > > > > > > > The proposed 2.7 release timing sounds reasonable to me.
> > > > > > > > > > Python [1], PHP [2], and Node.js [3] thin clients should 
> > > > > > > > > > take
> > > >
> > > > the
> > > > > >
> > > > > > train.
> > > > > > > > > >
> > > > > > > > > > p.
> > > > > > > > > >
> > > > > > > > > > [1] https://jira.apache.org/jira/browse/IGNITE-7782
> > > > > > > > > > [2] https://jira.apache.org/jira/browse/IGNITE-7783
> > > > > > > > > > [3] https://jira.apache.org/jira/browse/IGNITE-
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Jul 20, 2018 at 2:35 PM, Denis Magda <
> > > >
> > > > dma...@gridgain.com>
> > > > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Ignite

Re: Metrics for MVCC caches

[Alex Plehanov]

Hi, Ivan

Looks like a bug. Metrics counting described at JSR107 (JCache)
specification. It says, that "cache removals" metric should be incremented
if remove() method returns true. Since there are no matching keys in the
first remove() call should be found, remove() should return false and
"cache removals" metric should not be affected.

2018-08-10 12:56 GMT+03:00 Павлухин Иван :

> Hi,
>
> Dmitriy thanks for note, I will keep metrics IEP in mind.
>
> Roman it sounds quite a straightforward approach. Moreover current cache
> transactions follow it: there could be a number of invisible actions in
> private workspace (e.g. creating and then deleting the same entry) but only
> final changes are metered.
>
> Also, I observed strange behavior for TRANSACTIONAL cache operations. For
> following case metrics surprised me (numbers in comments):
>
> public void testPutRemove() throws Exception {
> cache.remove(1);
> System.out.println(cache.metrics().getCacheRemovals()); // 1
>
> cache.put(1, "a");
>
> cache.remove(1);
> System.out.println(cache.metrics().getCacheRemovals()); // 2
> }
>
> While for ATOMIC cache I see 0 and 1 which looks much better. And similar
> effect is observed for "replace" operations.
>
> Is it a bug? Do we have some document describing how metrics should be
> counted?
>
> 2018-08-08 21:11 GMT+03:00 Dmitriy Setrakyan :
>
> > I think we should be updating the IEP with metrics specifications in
> > parallel.
> >
> > D.
> >
> > On Wed, Aug 8, 2018, 05:32 Roman Kondakov 
> > wrote:
> >
> > > Hi Ivan!
> > >
> > > In my opinion we need to preserve the essence of the metrics: if we
> > > didn't consider dirty writes as updates before MVCC implementation, we
> > > also shouldn't count these writes in MVCC metrics implementation too.
> > > So, I think we need to count only committed entries. But we can count
> > > this dirty writes as additional metrics.
> > >
> > > Also additional metrics concerning MVCC could be:
> > >
> > > - Average count of the active transactions per snapshot
> > >
> > > - Average quantity of versions per key
> > >
> > >
> > > --
> > >
> > > Roman Kondakov
> > >
> > >
> > > On 07.08.2018 17:17, Павлухин Иван wrote:
> > > > Hi Igniters,
> > > >
> > > > I am working on cache metrics support for caches with enabled MVCC.
> As
> > > you
> > > > may know, during MVCC transaction execution entry versions are
> written
> > to
> > > > storage right away (without deferring until commit). So, it is not
> > > obvious
> > > > for me if we should update writes count right away or defer it until
> > > > commit. On one hand, MVCC entry version write is not "true" write
> until
> > > > commit. On the other hand, it definitely changes the storage. How do
> we
> > > > interpret write metrics in Ignite philosophy?
> > > >
> > > > Also, it seems that bunch of MVCC specific metrics could be
> > introduced. I
> > > > would like to collect some thoughts about it. Which such metrics come
> > to
> > > > your mind?
> > > >
> > >
> > >
> >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: ConcurrentLinkedHashMap works incorrectly after clear()

[Andrey Gura]

Stas,

SkipList implementation offers O(log n) for get/put/contains
operations while CLHM - O(1). So it is suitable for small data sets
but will have serious performance impact for the big ones.

However, it seems it's time for right choice: correctness or
performance. The answer seems obvious )
On Tue, Jul 24, 2018 at 4:45 PM Stanislav Lukyanov
 wrote:
>
> It seems that we currently use the CLHM primarily as a FIFO cache.
> I see two ways around that.
>
> First, we could implement such LRU/FIFO cache based on another, properly 
> supported data structure from j.u.c.
> ConcurrentSkipListMap seems OK. I have a draft implementation of 
> LruEvictionPolicy based on it that passes functional tests,
> but I haven’t benchmarked it yet.
>
> Second, Guava has a Cache API with a lot of configuration options that we 
> could use (license is Apache, should be OK).
>
> Stan
>
> From: Nikolay Izhikov
> Sent: 24 июля 2018 г. 16:27
> To: dev@ignite.apache.org
> Subject: Re: ConcurrentLinkedHashMap works incorrectly after clear()
>
> Hello, Ilya.
>
> May be we need to proceed with ticket [1] "Get rid of 
> org.jsr166.ConcurrentLinkedHashMap"?
>
> Especially, if this class is broken and buggy.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-7516
>
> В Вт, 24/07/2018 в 16:20 +0300, Ilya Lantukh пишет:
> > Thanks for revealing this issue!
> >
> > I don't understand why should we disallow calling clear().
> >
> > One way how it can be re-implemented is:
> > 1. acquire write locks on all segments;
> > 2. clear them;
> > 3. reset size to 0;
> > 4. release locks.
> >
> > Another approach is to calculate inside
> > ConcurrentLinkedHashMap.Segment.clear() how many entries you actually
> > deleted and then call size.addAndGet(...).
> >
> > In both cases you'll have to replace LongAdder with AtomicLong.
> >
> > On Tue, Jul 24, 2018 at 4:03 PM, Ilya Kasnacheev 
> > wrote:
> >
> > > Hello igniters!
> > >
> > > So I was working on a fix for
> > > https://issues.apache.org/jira/browse/IGNITE-9056
> > > The reason for test flakiness turned out our ConcurrentLinkedHashMap (and
> > > its tautological cousin GridBoundedConcurrentLinkedHashMap) is broken :(
> > >
> > > When you do clear(). its size counter is not updated. So sizex() will
> > > return the old size after clear, and if there's maxCnt set, after several
> > > clear()s it will immediately evict entries after they are inserted,
> > > maintaining map size at 0.
> > >
> > > This is scary since indexing internals make intense use of
> > > ConcurrentLinkedHashMaps.
> > >
> > > My suggestion for this fix is to avoid ever calling clear(), making it
> > > throw UnsupportedOperationException and recreating/replacing map instead 
> > > of
> > > clear()ing it. Unless somebody is going to stand up and fix
> > > ConcurrentLinkedHashMap.clear() properly. Frankly speaking I'm afraid of
> > > touching this code in any non-trivial way.
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> >
> >
> >
>

[GitHub] ignite pull request #4495: IGNITE-9178 Partition lost event are not triggere...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4506: IGNITE-9231 improvement throttle implementation

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4518: IGNITE-9227 Fast reply on single message if excha...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-9227 Fast reply on single message if exchange future has already 
completed



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

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

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

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


commit 15d4cf514b0124572ac6a80798772f3b57a41e4c
Author: Pavel Kovalenko 
Date:   2018-08-10T15:55:49Z

IGNITE-9227 Fast reply on single message if exchange future has already 
completed and full message is available to send

commit 65782a52eeb425082b85dde316dd1082fe43edb4
Author: Pavel Kovalenko 
Date:   2018-08-10T15:57:12Z

Merge branch 'master' into ignite-9227

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite6.java

commit f609ef4fa855a1636211ee5dde0ffeff59fb4d40
Author: Pavel Kovalenko 
Date:   2018-08-10T15:58:46Z

IGNITE-9227 Unfail test.




---

Re: Benchmarking

[Ilya Suntsov]

Anton,

I have experience with the yardstick and can help you sometimes.
My possibilities in this matter are limited and it is possible that your
request will be delayed.

Please, try to use the last version of the yardstick and then we can
discuss specific yardstick
issues that you couldn't solve.

Also, you can use dedicated AWS instances for benchmarking.
Pay attention to the fact that sometimes our benchmarks can show unstable
results in case of
non-dedicated instances.




2018-08-09 21:09 GMT+03:00 Vyacheslav Daradur :

> Huge +1, for a public benchmarking tool and the Docker based approach.
> On Thu, Aug 9, 2018 at 7:16 PM Pavel Kovalenko  wrote:
> >
> > Igniters,
> >
> > I would like to add that it would be very nice to have prepared scenarios
> > in packed docker images with docker-compose, to easily deploy and run it
> on
> > AWS environment. This will give the possibility to benchmark any changes
> > independently and fastly.
> >
> > 2018-08-09 18:51 GMT+03:00 Anton Vinogradov :
> >
> > > Igniters,
> > >
> > > All critical code changes should be covered by benchmarks.
> > > Currently, community have no dedicated benchmarking service.
> > >
> > > Everyone can run yandstick locally, but this seems to be useless.
> > > You have to run cluster on 4 clients and 4 servers, at least.
> > >
> > > Currently it is not possible for me to perform benchmarking using 8+
> real
> > > servers.
> > > Also, some automation requred to have reliable check of two branchs
> with
> > > one feature difference, since yardstick will provide you branch check,
> not
> > > a branches comparision.
> > >
> > > So, my question is:
> > > Is there anybody at community able to perform benchmarks on real
> hardware
> > > and already have automation to compare 2 branches?
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>



-- 
Best Regards,
Ilya Suntsov
email: isunt...@gridgain.com
*GridGain Systems*
www.gridgain.com

Running Yardstick benchmark with persistent store enabled

[Mammo, Mulugeta]

Hi,

I was testing out the Yardstick benchmark in my local machine and it looks to 
me that there is no direct way to run the benchmarks with persistent store 
enabled. I modified the ignite-localhost-config.xml with persistentEnabled and 
then had to modify 
https://github.com/apache/ignite/blob/master/modules/yardstick/src/main/java/org/apache/ignite/yardstick/IgniteAbstractBenchmark.java#L63
 to add a node.ignite().active(true) to activate cluster.. the benchmark will 
run successfully but the results looks weird in that I see no disk IO.

Any ideas?

Thanks,
Mulugeta

Re: Running Yardstick benchmark with persistent store enabled

[Vyacheslav Daradur]

Hi,

Try to add "-pds" flag in input arguments for Ignite benchmarks to
enable persistence.
On Sat, Aug 11, 2018 at 12:19 AM Mammo, Mulugeta
 wrote:
>
> Hi,
>
> I was testing out the Yardstick benchmark in my local machine and it looks to 
> me that there is no direct way to run the benchmarks with persistent store 
> enabled. I modified the ignite-localhost-config.xml with persistentEnabled 
> and then had to modify 
> https://github.com/apache/ignite/blob/master/modules/yardstick/src/main/java/org/apache/ignite/yardstick/IgniteAbstractBenchmark.java#L63
>  to add a node.ignite().active(true) to activate cluster.. the benchmark will 
> run successfully but the results looks weird in that I see no disk IO.
>
> Any ideas?
>
> Thanks,
> Mulugeta
>


-- 
Best Regards, Vyacheslav D.

[GitHub] ignite pull request #4519: IGNITE-9209: GridDistributedTxMapping.toString() ...

[SomeFire]

GitHub user SomeFire opened a pull request:

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

IGNITE-9209: GridDistributedTxMapping.toString() returns broken string



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

$ git pull https://github.com/SomeFire/ignite ignite-9209

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

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


commit 9d0f4853e9b179553631866b57cba8d393328be8
Author: Dmitrii Ryabov 
Date:   2018-08-10T21:41:53Z

IGNITE-9209: GridDistributedTxMapping.toString() returns broken string




---