Re: Service grid redesign

[Vyacheslav Daradur]

Hi, Igniters!

I had a discussion about the scope of work of IEP-17 with Denis and Pavel.

To estimate the time I took 2 weeks for R during which I would do the task:
https://issues.apache.org/jira/browse/IGNITE-8361

Then I will inform the community about the planned work time.


On Tue, May 8, 2018 at 9:50 PM, Vyacheslav Daradur  wrote:
> Thanks, Denis! I assigned the task to myself.
>
> I going to start work next week.
>
> On Tue, May 8, 2018 at 7:50 PM, Denis Mekhanikov  
> wrote:
>> Hi Vyacheslav!
>>
>> Thanks for the enthusiasm!
>> The first ticket to be implemented here is IGNITE-8361
>> .
>> I think, until this one is resolved, other tasks can't be started.
>>
>> Please assign it to yourself, if you feel confident enough.
>> Feel free to ask for any help, if you need.
>>
>> For now it will be enough to perform service deployment and initialization
>> in the discovery thread.
>> Making it asynchronous will be our next step: IGNITE-8362
>> 
>>
>> Denis
>>
>> вт, 24 апр. 2018 г. в 15:43, Vyacheslav Daradur :
>>
>>> Hi, Denis M.,
>>>
>>> I'd like to pick up a ticket from IEP-17 next week.
>>>
>>> Could you please advise a ticket to start?
>>>
>>> On Tue, Apr 24, 2018 at 11:47 AM, Dmitriy Setrakyan
>>>  wrote:
>>> > On Tue, Apr 24, 2018, 3:59 PM Denis Mekhanikov 
>>> > wrote:
>>> >
>>> >> Dmitriy,
>>> >>
>>> >> After the proposed changes are made the utility cache won't be needed at
>>> >> all.
>>> >>
>>> >
>>> > I was rather talking about prioritization. In my view, first and foremost
>>> > we must fix deployment before anything else.
>>> >
>>> > D.
>>>
>>>
>>>
>>> --
>>> Best Regards, Vyacheslav D.
>>>
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

[GitHub] ignite pull request #4009: IGNITE-8384

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-8384



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

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

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

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






---

[GitHub] ignite pull request #4001: IGNITE-8499 validate_indexes command doesn't dete...

[glukos]

Github user glukos closed the pull request at:

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


---

[jira] [Created] (IGNITE-8517) Implement CacheGroupMetricsMXBean.getTotalAllocatedPages() calculation for PageMemoryNoStore

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-8517:
-

 Summary: Implement 
CacheGroupMetricsMXBean.getTotalAllocatedPages() calculation for 
PageMemoryNoStore
 Key: IGNITE-8517
 URL: https://issues.apache.org/jira/browse/IGNITE-8517
 Project: Ignite
  Issue Type: Improvement
Reporter: Aleksey Plekhanov


Allocated pages count are calculated for cache groups only when PDS is enabled 
(allocated page trackers for each cache group are used in FilePageStore class). 
But when PageMemoryNoStore is used this metric for cache groups is not 
calculated (data region page tracker is used when page is allocated)



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

Re: Avoid JIRA comments deletion

[Dmitry Pavlov]

I do not suggest to restrict removal using JIRA rights, it is not
reasonable.

I ask contributors to avoid such practice. In a number of cases it doesn't
make any sense and confuses community members.

ср, 16 мая 2018 г. в 15:58, Vladimir Ozerov :

> People make mistakes. Sometimes I can edit comment. Sometimes I can delete
> it if I understand it makes no sense. If I do this then I think that
> comment adds no value.  If you restrict removal, then users would use
> "Edit" and print something like "comment was removed". Same thing.
>
> Again - what is the problem being solved?
>
> On Wed, May 16, 2018 at 3:53 PM, Dmitry Pavlov 
> wrote:
>
> > Hi Vladimir,
> >
> > I receive a number of such emails, then contributor deletes data. This is
> > valueable information about ticket history.
> >
> > I'm not sure what are we trying to solve using this, as you said,
> perfectly
> > normal operation - deleting comments. Could you provide cases?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 16 мая 2018 г. в 15:18, Vladimir Ozerov :
> >
> > > Agree, comments deletion is perfectly normal operation.
> > > What are we trying to solve?
> > >
> > > On Wed, May 16, 2018 at 3:12 PM, Vyacheslav Daradur <
> daradu...@gmail.com
> > >
> > > wrote:
> > >
> > > > +1 to Andrey's point.
> > > >
> > > > Do we really have any problems with comment's deletion?
> > > >
> > > > I think: if a contributor will make a decision to remove a comment
> and
> > > > will not be able to do this he just will edit the comment with the
> > > > message *deleted*.
> > > >
> > > >
> > > >
> > > > On Wed, May 16, 2018 at 2:46 PM, Andrey Kuznetsov  >
> > > > wrote:
> > > > > Folks,
> > > > >
> > > > > Let me disagree with you.
> > > > >
> > > > > As you've mentioned, there is a history of changes for an issue, so
> > > > nothing
> > > > > can be lost. Comment deletions can be useful to maintain clear path
> > of
> > > > > issue evolution. For me, it's ok to delete misleading comments, but
> > > this
> > > > > should be done with care, of course.
> > > > >
> > > > > 2018-05-16 12:51 GMT+03:00 Dmitriy Govorukhin <
> > > > dmitriy.govoruk...@gmail.com>
> > > > > :
> > > > >
> > > > >> +1 Dmitriy,
> > > > >>
> > > > >> I do not see any reason for deletion comments.
> > > > >> Maybe only edit operation must be allowed.
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >   Andrey Kuznetsov.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-8516) Not null constraint doesn't checked

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-8516:
---

 Summary: Not null constraint doesn't checked
 Key: IGNITE-8516
 URL: https://issues.apache.org/jira/browse/IGNITE-8516
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4
Reporter: Nikolay Izhikov
 Fix For: 2.6


User are able to insert null into the not null column through cache-api.

Reproducer:
{code:java}
package org.apache.ignite.internal.processors.sql;

public class IgniteNotNullBug extends GridCommonAbstractTest {
@Override protected void beforeTestsStarted() throws Exception {
startGrid(0);

Set nn = new HashSet<>();
nn.add("address");

jcache(grid(0), cacheConfiguration(new 
QueryEntity(Organization.class.getName(), Address.class.getName())
.addQueryField("address", "java.lang.String", "address")
.setNotNullFields(nn)), "ORG_ADDRESS");
}

public void testPutNullField() throws Exception {
Map entries = new HashMap<>();

entries.put(new Organization("1"), new Address(null));
//entries.put(new Organization("2"), new Address("Some address"));

IgniteCache cache = jcache(0, "ORG_ADDRESS");

cache.putAll(entries);

System.out.println("cache.getConfiguration(CacheConfiguration) = " + 
cache.getConfiguration(CacheConfiguration.class).getQueryEntities());

List objects = execSql("SELECT address FROM ORG_ADDRESS.ADDRESS");

assert ((List)objects.get(0)).get(0) == null;
}

protected CacheConfiguration cacheConfiguration(QueryEntity qryEntity) {
CacheConfiguration cache = defaultCacheConfiguration();

cache.setCacheMode(CacheMode.PARTITIONED);
cache.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cache.setBackups(1);
cache.setWriteSynchronizationMode(FULL_SYNC);

cache.setQueryEntities(Collections.singletonList(qryEntity));

return cache;
}

private List execSql(String sql, Object... args) {
SqlFieldsQuery qry = new SqlFieldsQuery(sql)
.setArgs(args);

return grid(0).context().query().querySqlFields(qry, true).getAll();
}

private static class Organization implements Serializable {
private final String name;
private Organization(String name) { this.name = name; }
}

private static class Address implements Serializable {
private final String address;
private Address(String address) { this.address = address; }
}
}
{code}



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

[GitHub] ignite pull request #4006: IGNITE-5883 Only for testing. Add random dir to d...

[andrewmed]

Github user andrewmed closed the pull request at:

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


---

[jira] [Created] (IGNITE-8515) Value of CacheGroupMetricsMXBean.getTotalAllocatedPages() is always 0

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-8515:
-

 Summary: Value of CacheGroupMetricsMXBean.getTotalAllocatedPages() 
is always 0
 Key: IGNITE-8515
 URL: https://issues.apache.org/jira/browse/IGNITE-8515
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
 Fix For: 2.6


{{DataRegionMetricsImpl#getOrAllocateGroupPageAllocationTracker}} don't save 
created trackers and always returns new tracker.



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

[jira] [Created] (IGNITE-8514) Missed descriptions for a few package

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-8514:
-

 Summary: Missed descriptions for a few package
 Key: IGNITE-8514
 URL: https://issues.apache.org/jira/browse/IGNITE-8514
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Sergey Kozlov
 Fix For: 2.5


The packages below have no descriptions in javadoc:
/doc/javadoc/overview-summary.html
{noformat}
org.apache.ignite.spi.communication.tcp.internal
org.apache.ignite.spi.discovery.zk
org.apache.ignite.spi.discovery.zk.internal
org.apache.ignite.ml.structures.partition
{noformat}



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

Re: method arguments code style

[Vyacheslav Daradur]

Hi, I filed the ticket https://issues.apache.org/jira/browse/IGNITE-8512

I'll do this when I have enough time if it won't be done earlier.

On Mon, May 14, 2018 at 8:46 PM, Dmitry Pavlov  wrote:
> Hi Vyacheslav,
>
> plugin was published in AI wiki, feel free to create ticket to add method
> code style check.
>
> Actually I'm not sure it is easy to validate code style in plugin, but I
> guess you know it better.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 8 мая 2018 г. в 21:47, Vyacheslav Daradur :
>
>> Hi, Igniters!
>>
>> After the completion of publishing abbr-plugin [1][2] we will be able
>> to automate checking of method arguments code style.
>>
>> It will be easy to check rules approved by the community during writing
>> code.
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-5698
>> [2]
>> http://apache-ignite-developers.2346864.n4.nabble.com/abbrevation-rules-plugin-td19356.html
>>
>> On Tue, May 8, 2018 at 8:34 PM, Dmitry Pavlov 
>> wrote:
>> > Folks, I've messed with another topic, where Vladimir was going to update
>> > review check-list.
>> >
>> > Here I've updated Coding Guidelines:
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-MethodArguments
>> >
>> > Please review changes, so we can consider it is final.
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > вт, 8 мая 2018 г. в 20:05, Dmitry Pavlov :
>> >
>> >> I thought that Vladimir will update.
>> >>
>> >> By the way, Denis M, I propose to grant access to the wiki to Dmitry G.
>> >> WDYT?
>> >>
>> >> вт, 8 мая 2018 г. в 19:28, Dmitriy Govorukhin <
>> >> dmitriy.govoruk...@gmail.com>:
>> >>
>> >>> Dmitriy,
>> >>>
>> >>> Сould you please update code style wiki page in accordance with the
>> >>> results of the discussion?
>> >>> On May 7 2018, at 11:00 am, Vladimir Ozerov 
>> wrote:
>> >>> >
>> >>> > Dmitry,
>> >>> > Agree, mixed style when some arguments share the same line and others
>> >>> don't
>> >>> > looks very bad. My proposal was to allow two styles - first when all
>> >>> > arguments are on the same line splitted by 120 char limit, second
>> when
>> >>> all
>> >>> > every arguments is on a separate line.
>> >>> > Mixed style should be disallowed.
>> >>> >
>> >>> > On Mon, May 7, 2018 at 12:35 AM, Dmitriy Govorukhin <
>> >>> > dmitriy.govoruk...@gmail.com> wrote:
>> >>> >
>> >>> > > Vladimir,
>> >>> > > My eyes cry when I see this
>> >>> > > public double getCost(Session ses, int[] masks, TableFilter[]
>> filters,
>> >>> > > int filter, SortOrder sortOrder,
>> >>> > > HashSet cols) {
>> >>> > > return SpatialTreeIndex.getCostRangeIndex(masks,table.
>> >>> > > getRowCountApproximation(),
>> >>> > > columns) / 10;
>> >>> > > }
>> >>> > >
>> >>> > > Why did arguments split into 3 line?
>> >>> > > It is much better readable for me
>> >>> > > public double getCost(
>> >>> > > Session ses,
>> >>> > > int[] masks,
>> >>> > > TableFilter[] filters,
>> >>> > > int filter,
>> >>> > > SortOrder sortOrder,
>> >>> > > HashSet cols
>> >>> > > ) {
>> >>> > > return SpatialTreeIndex.getCostRangeIndex(masks,
>> >>> > > able.getRowCountApproximation(),
>> >>> > > columns) / 10;
>> >>> > > }
>> >>> > >
>> >>> > > Do we have a serious reason to continue writing code as before?
>> >>> > >
>> >>> > >
>> >>> > > On Thu, May 3, 2018 at 2:24 PM, Vladimir Ozerov <
>> voze...@gridgain.com
>> >>> >
>> >>> > > wrote:
>> >>> > >
>> >>> > > > My opinion is that we should allow both styles and not enforce
>> any
>> >>> of
>> >>> > > them.
>> >>> > > > I hardly can say that this
>> >>> > > >
>> >>> > > > public double getCost(
>> >>> > > > Session ses,
>> >>> > > > int[] masks,
>> >>> > > > TableFilter[] filters,
>> >>> > > > int filter,
>> >>> > > > SortOrder sortOrder,
>> >>> > > > HashSet cols
>> >>> > > > ) {
>> >>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
>> >>> > > > table.getRowCountApproximation(), columns) / 10;
>> >>> > > > }
>> >>> > > >
>> >>> > > > is better than this
>> >>> > > > public double getCost(Session ses, int[] masks, TableFilter[]
>> >>> filters,
>> >>> > > > int filter, SortOrder sortOrder,
>> >>> > > > HashSet cols) {
>> >>> > > > return SpatialTreeIndex.getCostRangeIndex(masks,
>> >>> > > > table.getRowCountApproximation(), columns) / 10;
>> >>> > > > }
>> >>> > > >
>> >>> > > >
>> >>> > > > But this
>> >>> > > > public CacheLockCandidates doneRemote(
>> >>> > > > GridCacheVersion ver,
>> >>> > > > Collection pending,
>> >>> > > > Collection committed,
>> >>> > > > Collection rolledback
>> >>> > > > )
>> >>> > > >
>> >>> > > >
>> >>> > > > looks better than this
>> >>> > > > public CacheLockCandidates doneRemote(GridCacheVersion ver,
>> >>> > > > Collection pending,
>> >>> > > > Collection committed,
>> >>> > > > Collection rolledback)
>> >>> > > >
>> >>> > > >
>> >>> > > > The very problem is that our eyes feel comfortable when we either
>> >>> move
>> >>> > > them
>> 

Re: Avoid JIRA comments deletion

[Vladimir Ozerov]

People make mistakes. Sometimes I can edit comment. Sometimes I can delete
it if I understand it makes no sense. If I do this then I think that
comment adds no value.  If you restrict removal, then users would use
"Edit" and print something like "comment was removed". Same thing.

Again - what is the problem being solved?

On Wed, May 16, 2018 at 3:53 PM, Dmitry Pavlov 
wrote:

> Hi Vladimir,
>
> I receive a number of such emails, then contributor deletes data. This is
> valueable information about ticket history.
>
> I'm not sure what are we trying to solve using this, as you said, perfectly
> normal operation - deleting comments. Could you provide cases?
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 16 мая 2018 г. в 15:18, Vladimir Ozerov :
>
> > Agree, comments deletion is perfectly normal operation.
> > What are we trying to solve?
> >
> > On Wed, May 16, 2018 at 3:12 PM, Vyacheslav Daradur  >
> > wrote:
> >
> > > +1 to Andrey's point.
> > >
> > > Do we really have any problems with comment's deletion?
> > >
> > > I think: if a contributor will make a decision to remove a comment and
> > > will not be able to do this he just will edit the comment with the
> > > message *deleted*.
> > >
> > >
> > >
> > > On Wed, May 16, 2018 at 2:46 PM, Andrey Kuznetsov 
> > > wrote:
> > > > Folks,
> > > >
> > > > Let me disagree with you.
> > > >
> > > > As you've mentioned, there is a history of changes for an issue, so
> > > nothing
> > > > can be lost. Comment deletions can be useful to maintain clear path
> of
> > > > issue evolution. For me, it's ok to delete misleading comments, but
> > this
> > > > should be done with care, of course.
> > > >
> > > > 2018-05-16 12:51 GMT+03:00 Dmitriy Govorukhin <
> > > dmitriy.govoruk...@gmail.com>
> > > > :
> > > >
> > > >> +1 Dmitriy,
> > > >>
> > > >> I do not see any reason for deletion comments.
> > > >> Maybe only edit operation must be allowed.
> > > >>
> > > >>
> > > >
> > > > --
> > > > Best regards,
> > > >   Andrey Kuznetsov.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>

Re: Avoid JIRA comments deletion

[Dmitry Pavlov]

Hi Vladimir,

I receive a number of such emails, then contributor deletes data. This is
valueable information about ticket history.

I'm not sure what are we trying to solve using this, as you said, perfectly
normal operation - deleting comments. Could you provide cases?

Sincerely,
Dmitriy Pavlov

ср, 16 мая 2018 г. в 15:18, Vladimir Ozerov :

> Agree, comments deletion is perfectly normal operation.
> What are we trying to solve?
>
> On Wed, May 16, 2018 at 3:12 PM, Vyacheslav Daradur 
> wrote:
>
> > +1 to Andrey's point.
> >
> > Do we really have any problems with comment's deletion?
> >
> > I think: if a contributor will make a decision to remove a comment and
> > will not be able to do this he just will edit the comment with the
> > message *deleted*.
> >
> >
> >
> > On Wed, May 16, 2018 at 2:46 PM, Andrey Kuznetsov 
> > wrote:
> > > Folks,
> > >
> > > Let me disagree with you.
> > >
> > > As you've mentioned, there is a history of changes for an issue, so
> > nothing
> > > can be lost. Comment deletions can be useful to maintain clear path of
> > > issue evolution. For me, it's ok to delete misleading comments, but
> this
> > > should be done with care, of course.
> > >
> > > 2018-05-16 12:51 GMT+03:00 Dmitriy Govorukhin <
> > dmitriy.govoruk...@gmail.com>
> > > :
> > >
> > >> +1 Dmitriy,
> > >>
> > >> I do not see any reason for deletion comments.
> > >> Maybe only edit operation must be allowed.
> > >>
> > >>
> > >
> > > --
> > > Best regards,
> > >   Andrey Kuznetsov.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

[jira] [Created] (IGNITE-8512) Abbr-plugin: Add check of method arguments code style

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-8512:
--

 Summary: Abbr-plugin: Add check of method arguments code style
 Key: IGNITE-8512
 URL: https://issues.apache.org/jira/browse/IGNITE-8512
 Project: Ignite
  Issue Type: Task
Reporter: Vyacheslav Daradur


It is necessary to add check of method arguments code style to Abbreviation 
Plugin:
https://github.com/dspavlov/ignite-abbrev-plugin

Methods arguments have to be checked according to coding guidelines:
https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-MethodArguments

Dev-list discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/method-arguments-code-style-td30088.html




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

[GitHub] ignite pull request #4006: IGNITE-5883 Only for testing. Add random dir to d...

[andrewmed]

GitHub user andrewmed opened a pull request:

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

IGNITE-5883 Only for testing. Add random dir to debug flacky tests in TC

Do NOT merge
Only for tests

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

$ git pull https://github.com/andrewmed/ignite ignite-5883

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

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


commit 6147652dc382860a4798998820e4445ab2aea3f5
Author: AMedvedev 
Date:   2018-05-16T12:40:05Z

IGNITE-5883 Only for testing. Add random dir to debug flacky tests in TC




---

[GitHub] ignite pull request #3958: IGNITE-8450: Cleanup old algebra

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: work with files and directories

[Dmitriy Govorukhin]

One more thing, If we implement this component and will aggregate
information about all files, we can
create failure handler which provided detail information about node
persistence structure. It will be helpful for debugging node crash.

On Wed, May 16, 2018 at 12:46 PM, Dmitry Pavlov 
wrote:

> Andrey Gura expressed in words what I also thought.
>
> I agree if we extract common code to some kind of file utils.
>
> In the same time creating common file operation framework is not possible
> because of different nature of WAL, Page Store and other components using
> files.
>
> ср, 16 мая 2018 г. в 11:27, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com
> >:
>
> > Andrey,
> >
> > My point is, it will be very cool if there is some component who will
> know
> > about persistence folder and files,
> > and we can move all generic code, for work with files,  to this
> component.
> >
> > On Wed, May 16, 2018 at 12:59 AM, Pavel Kovalenko 
> > wrote:
> >
> > > Andrey,
> > >
> > > I think the main idea of that not about how to unify writing content to
> > > file. It's about creating peristence files and folders. For other
> > > persistence components (WAL, Checkpoint, etc.) it should be like
> > > FileFactory object with methods like "public File
> > > getOrCreatePartitionFile(...), public void commitFIle(..) and etc". So,
> > all
> > > logic about how files should look will be moved to centralized point
> and
> > it
> > > will be more easier to understand our persistence structure.
> > >
> > > 2018-05-16 0:42 GMT+03:00 Andrey Gura :
> > >
> > > > Hi,
> > > >
> > > > I understand you idea but it just increases dependencies of different
> > > > component from one that is in general bad practice.
> > > >
> > > > We have different components where each one can use different
> approach
> > > for
> > > > file management. For example page store and WAL have different file
> IO
> > > > implementations due to performance reasons and we have to provide
> > > different
> > > > mechanics for work with files.
> > > >
> > > > Of course we can refactor mentioned components in more structured
> > manner
> > > > but we should not strongly link it with one implementation.
> > > >
> > > > вт, 15 мая 2018 г., 20:10 Dmitry Pavlov :
> > > >
> > > > > Hi Maxim,
> > > > >
> > > > > FileWriteAheadLogManager  &  FsyncModeFileWriteAheadLogManager
> were
> > > > > intentionally copy-pasted in hope we will soon delete FsyncManager.
> > > > >
> > > > > But it is still shows this tool works good. Probably we could
> > integrate
> > > > > this tool to our processes.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > >
> > > > > вт, 15 мая 2018 г. в 20:06, Maxim Muzafarov :
> > > > >
> > > > > > +1 also for something like "resource manager".
> > > > > >
> > > > > > Recently, I've found for myself sonarcloud.io tool for code
> > > analisys.
> > > > > It's
> > > > > > free for open source project and I've made Ignite project initial
> > run
> > > > > [1].
> > > > > >
> > > > > > I've prepeared analisys for mysefl and found a lot of duplicated
> > code
> > > > > > blocks [1]. Of course it's not the ideal tool but gave us
> direction
> > > of
> > > > > > thoughts. E.g. these classes [3]:
> > > > > > 1) FileWriteAheadLogManager.java
> > > > > > 2) FsyncModeFileWriteAheadLogManager.java
> > > > > >
> > > > > >
> > > > > > [1] https://sonarcloud.io/dashboard?id=org.apache.
> > > > ignite%3Aapache-ignite
> > > > > > [2]
> > > > > >
> > > > > >
> > > > > https://sonarcloud.io/component_measures?id=org.
> > > > apache.ignite%3Aapache-ignite=duplicated_blocks
> > > > > > [3]
> > > > > >
> > > > > >
> > > > > https://sonarcloud.io/component_measures?id=org.
> > > > apache.ignite%3Aapache-ignite=duplicated_blocks&
> > > > selected=org.apache.ignite%3Aignite-core%3Asrc%2Fmain%
> > > > 2Fjava%2Forg%2Fapache%2Fignite%2Finternal%2Fprocessors%2Fcache%
> > > > 2Fpersistence%2Fwal%2FFsyncModeFileWriteAheadLogManager.java
> > > > > >
> > > > > > вт, 15 мая 2018 г. в 19:26, Pavel Kovalenko  >:
> > > > > >
> > > > > > > +1 to this approach,
> > > > > > >
> > > > > > > It can be also very helpful in failover scenarios when
> something
> > > > wrong
> > > > > > > happened with disk. In this case we're reducing the number of
> > > points
> > > > of
> > > > > > > failure.
> > > > > > >
> > > > > > > 2018-05-15 18:37 GMT+03:00 Dmitriy Govorukhin <
> > > > > > > dmitriy.govoruk...@gmail.com>
> > > > > > > :
> > > > > > >
> > > > > > > > Hi Ignite,
> > > > > > > >
> > > > > > > > Do we have a general approach to work with a file and
> > > directories?
> > > > > > > > I see many duplication logic for write through .tmp file.
> > > > > > > >
> > > > > > > > For example,
> > > > > > > >
> > > > > > > > GridCacheDatabaseSharedManager.writeCheckpointEntry();
> > > > > > > > GridCacheDatabaseSharedManage.nodeStart();
> > > > > > > > 

Re: Avoid JIRA comments deletion

[Vladimir Ozerov]

Agree, comments deletion is perfectly normal operation.
What are we trying to solve?

On Wed, May 16, 2018 at 3:12 PM, Vyacheslav Daradur 
wrote:

> +1 to Andrey's point.
>
> Do we really have any problems with comment's deletion?
>
> I think: if a contributor will make a decision to remove a comment and
> will not be able to do this he just will edit the comment with the
> message *deleted*.
>
>
>
> On Wed, May 16, 2018 at 2:46 PM, Andrey Kuznetsov 
> wrote:
> > Folks,
> >
> > Let me disagree with you.
> >
> > As you've mentioned, there is a history of changes for an issue, so
> nothing
> > can be lost. Comment deletions can be useful to maintain clear path of
> > issue evolution. For me, it's ok to delete misleading comments, but this
> > should be done with care, of course.
> >
> > 2018-05-16 12:51 GMT+03:00 Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com>
> > :
> >
> >> +1 Dmitriy,
> >>
> >> I do not see any reason for deletion comments.
> >> Maybe only edit operation must be allowed.
> >>
> >>
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Avoid JIRA comments deletion

[Vyacheslav Daradur]

+1 to Andrey's point.

Do we really have any problems with comment's deletion?

I think: if a contributor will make a decision to remove a comment and
will not be able to do this he just will edit the comment with the
message *deleted*.



On Wed, May 16, 2018 at 2:46 PM, Andrey Kuznetsov  wrote:
> Folks,
>
> Let me disagree with you.
>
> As you've mentioned, there is a history of changes for an issue, so nothing
> can be lost. Comment deletions can be useful to maintain clear path of
> issue evolution. For me, it's ok to delete misleading comments, but this
> should be done with care, of course.
>
> 2018-05-16 12:51 GMT+03:00 Dmitriy Govorukhin 
> :
>
>> +1 Dmitriy,
>>
>> I do not see any reason for deletion comments.
>> Maybe only edit operation must be allowed.
>>
>>
>
> --
> Best regards,
>   Andrey Kuznetsov.



-- 
Best Regards, Vyacheslav D.

[jira] [Created] (IGNITE-8511) [ML] Add support for Multi-Class Logistic Regression

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8511:


 Summary: [ML] Add support for Multi-Class Logistic Regression
 Key: IGNITE-8511
 URL: https://issues.apache.org/jira/browse/IGNITE-8511
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

Re: Avoid JIRA comments deletion

[Andrey Kuznetsov]

Folks,

Let me disagree with you.

As you've mentioned, there is a history of changes for an issue, so nothing
can be lost. Comment deletions can be useful to maintain clear path of
issue evolution. For me, it's ok to delete misleading comments, but this
should be done with care, of course.

2018-05-16 12:51 GMT+03:00 Dmitriy Govorukhin 
:

> +1 Dmitriy,
>
> I do not see any reason for deletion comments.
> Maybe only edit operation must be allowed.
>
>

-- 
Best regards,
  Andrey Kuznetsov.

[GitHub] ignite pull request #4005: IGNITE-8510 RPM package 2.4.0 is incorrectly upgr...

[vveider]

GitHub user vveider opened a pull request:

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

IGNITE-8510 RPM package 2.4.0 is incorrectly upgraded by 2.5.0



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

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

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

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


commit 27da6c11623b318cb954386810ca47661d94e91e
Author: Ivanov Petr 
Date:   2018-05-16T11:31:15Z

IGNITE-8510 RPM package 2.4.0 is incorrectly upgraded by 2.5.0




---

Re: Thin clients features wiki page

[Alexey Kosenchuk]

Not applicable for NodeJS client as there are no threads in NodeJS (only 
processes) [1]


Just in case - of course, it's possible to run multiple 
queries/operations concurrently from one thread/process.
Eg. see Promise.all in CachePutGetExample.js and AuthTlsExample.js 
examples [2]


Is Java thin client really not thread-safe?

Is thread-safety a mandatory req for all clients (where it is applicable)?

-Alexey

[1] https://nodejs.org/en/about/
[2] 
https://github.com/nobitlost/ignite/tree/master/modules/platforms/nodejs/examples


16.05.2018 12:53, Igor Sapego пишет:

Fixed for .NET.

What about NodeJS? Alexey?

Best Regards,
Igor

On Wed, May 16, 2018 at 12:48 PM, Pavel Tupitsyn 
wrote:


Ignite.NET client is thread-safe as stated in XMLDoc [1]

[1]
https://github.com/apache/ignite/blob/master/modules/
platforms/dotnet/Apache.Ignite.Core/Client/IIgniteClient.cs

On Wed, May 16, 2018 at 12:34 PM, Guru Stron 
wrote:


  Hi Igor,

Nice one!

On 16 May 2018 at 11:26, Igor Sapego  wrote:


Pavel,

This is about concurrent usage of the same connection (client)
by several threads.

By the ways guys, I wanted to ask you, if your clients support this
feature, as I was not sure. I mean, protocol seems to be designed
to support such use-case, but I was not sure about clients.

Best Regards,
Igor

On Tue, May 15, 2018 at 10:46 PM, Pavel Tupitsyn 

wrote:



Igor,

That's a valid point. Will see how it goes. As for the new

documentation

engine, there are no more arguments. We will try to migrate within

2.6.

Just need to find more contributors who would help with this.

--
Denis

On Tue, May 15, 2018 at 2:11 AM, Igor Sapego 

wrote:



Thanks for proposals, guys, I will do this.

Denis,
Readme.io is not very convenient for some big tables. They look

OK,

while they have 3-4 columns, but if we are going to add more

clients

(or should I say "when") it is going to be a mess. This may be a

one

more argument when we consider to change documentation engine.


Best Regards,
Igor

On Tue, May 15, 2018 at 2:37 AM, Denis Magda <

dma...@gridgain.com>

wrote:



Igor, thanks for putting together the page.

As for the immediate improvements, I'm backing up Alexey's

suggestions.


This page deserves to be moved to the readme.io. We'll do that

once

it's

sorted out how to group the thin clients' documentation.

--
Denis

On Mon, May 14, 2018 at 12:39 PM, Alexey Kosenchuk <
alexey.kosenc...@nobitlost.com> wrote:


Hi Igor,

"Get Binary Cache" (if it is about getting a complex object in

a

"binary" form, w/o deserialization) - is supported by NodeJS:
BinaryObject is returned for a complex object if an app has not
specified another JavaScript Object for deserialization.

Maybe worth to add type registration functionality:
- complex object type registration (supported by NodeJS)
- enum type registration (not supported by NodeJS)
- type name registration (not supported by NodeJS)

Also, maybe add a list of all type codes, supported for read

and

write.

But not sure, as all of them are supported by all three

clients.


Thanks,
-Alexey

14.05.2018 22:06, Igor Sapego пишет:

Hello Igniters,


I've created a new page in wiki, that summarizes a features
availability of thin clients. It should help us to plan

development

of thin clients while also helping out users to understand a

state

of clients.

Check it out and tell me what you think. And if there are some
mistakes, don't hesitate telling me.

[1] -
https://cwiki.apache.org/confluence/display/IGNITE/Thin+clie
nts+features

Best Regards,
Igor

[jira] [Created] (IGNITE-8509) A lot of "Execution timeout" result for Cache 6 suite

[Maxim Muzafarov (JIRA)]

Maxim Muzafarov created IGNITE-8509:
---

 Summary: A lot of "Execution timeout" result for Cache 6 suite
 Key: IGNITE-8509
 URL: https://issues.apache.org/jira/browse/IGNITE-8509
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov


*Summary*

Suite Cache 6 fails with execution timeout fails with
{code:java}
[org.apache.ignite:ignite-core] [2018-05-15 02:35:14,143][WARN 
][grid-timeout-worker-#71656%transactions.TxRollbackOnTimeoutNearCacheTest0%][diagnostic]
 Found long running transaction [startTime=02:32:57.989, curTime=02:35:14.136, 
tx=GridDhtTxRemote
{code}
*Please, fefer for more details* 

[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6=1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E]

*Statistics Cache 6 Suite*

 Recent fails : 42,0% [21 fails / 50 runs]; 
 Critical recent fails: 10,0% [5 fails / 50 runs];

Last mounth (15.04 – 15.05)
Execution timeout: 21,0% [84 fails / 400 runs];



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

[jira] [Created] (IGNITE-8508) Zookeeper discovery SPI may notify custom message ACK with out-of-order topology version

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8508:


 Summary: Zookeeper discovery SPI may notify custom message ACK 
with out-of-order topology version
 Key: IGNITE-8508
 URL: https://issues.apache.org/jira/browse/IGNITE-8508
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Goncharuk






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

Re: Thin clients features wiki page

[Igor Sapego]

Fixed for .NET.

What about NodeJS? Alexey?

Best Regards,
Igor

On Wed, May 16, 2018 at 12:48 PM, Pavel Tupitsyn 
wrote:

> Ignite.NET client is thread-safe as stated in XMLDoc [1]
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/
> platforms/dotnet/Apache.Ignite.Core/Client/IIgniteClient.cs
>
> On Wed, May 16, 2018 at 12:34 PM, Guru Stron 
> wrote:
>
> >  Hi Igor,
> >
> > Nice one!
> >
> > On 16 May 2018 at 11:26, Igor Sapego  wrote:
> >
> > > Pavel,
> > >
> > > This is about concurrent usage of the same connection (client)
> > > by several threads.
> > >
> > > By the ways guys, I wanted to ask you, if your clients support this
> > > feature, as I was not sure. I mean, protocol seems to be designed
> > > to support such use-case, but I was not sure about clients.
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Tue, May 15, 2018 at 10:46 PM, Pavel Tupitsyn  >
> > > wrote:
> > >
> > > > Hi Igor,
> > > >
> > > > Thanks for creating this!
> > > > One question: what is `Multithreading` feature?
> > > >
> > > > Pavel
> > > >
> > > > On Tue, May 15, 2018 at 9:45 PM, Denis Magda 
> > > wrote:
> > > >
> > > > > Igor,
> > > > >
> > > > > That's a valid point. Will see how it goes. As for the new
> > > documentation
> > > > > engine, there are no more arguments. We will try to migrate within
> > 2.6.
> > > > > Just need to find more contributors who would help with this.
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Tue, May 15, 2018 at 2:11 AM, Igor Sapego 
> > > wrote:
> > > > >
> > > > > > Thanks for proposals, guys, I will do this.
> > > > > >
> > > > > > Denis,
> > > > > > Readme.io is not very convenient for some big tables. They look
> OK,
> > > > > > while they have 3-4 columns, but if we are going to add more
> > clients
> > > > > > (or should I say "when") it is going to be a mess. This may be a
> > one
> > > > > > more argument when we consider to change documentation engine.
> > > > > >
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > > On Tue, May 15, 2018 at 2:37 AM, Denis Magda <
> dma...@gridgain.com>
> > > > > wrote:
> > > > > >
> > > > > >> Igor, thanks for putting together the page.
> > > > > >>
> > > > > >> As for the immediate improvements, I'm backing up Alexey's
> > > > suggestions.
> > > > > >>
> > > > > >> This page deserves to be moved to the readme.io. We'll do that
> > once
> > > > > it's
> > > > > >> sorted out how to group the thin clients' documentation.
> > > > > >>
> > > > > >> --
> > > > > >> Denis
> > > > > >>
> > > > > >> On Mon, May 14, 2018 at 12:39 PM, Alexey Kosenchuk <
> > > > > >> alexey.kosenc...@nobitlost.com> wrote:
> > > > > >>
> > > > > >>> Hi Igor,
> > > > > >>>
> > > > > >>> "Get Binary Cache" (if it is about getting a complex object in
> a
> > > > > >>> "binary" form, w/o deserialization) - is supported by NodeJS:
> > > > > >>> BinaryObject is returned for a complex object if an app has not
> > > > > >>> specified another JavaScript Object for deserialization.
> > > > > >>>
> > > > > >>> Maybe worth to add type registration functionality:
> > > > > >>> - complex object type registration (supported by NodeJS)
> > > > > >>> - enum type registration (not supported by NodeJS)
> > > > > >>> - type name registration (not supported by NodeJS)
> > > > > >>>
> > > > > >>> Also, maybe add a list of all type codes, supported for read
> and
> > > > write.
> > > > > >>> But not sure, as all of them are supported by all three
> clients.
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> -Alexey
> > > > > >>>
> > > > > >>> 14.05.2018 22:06, Igor Sapego пишет:
> > > > > >>>
> > > > > >>> Hello Igniters,
> > > > > 
> > > > >  I've created a new page in wiki, that summarizes a features
> > > > >  availability of thin clients. It should help us to plan
> > > development
> > > > >  of thin clients while also helping out users to understand a
> > state
> > > > >  of clients.
> > > > > 
> > > > >  Check it out and tell me what you think. And if there are some
> > > > >  mistakes, don't hesitate telling me.
> > > > > 
> > > > >  [1] -
> > > > >  https://cwiki.apache.org/confluence/display/IGNITE/Thin+clie
> > > > >  nts+features
> > > > > 
> > > > >  Best Regards,
> > > > >  Igor
> > > > > 
> > > > > 
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Avoid JIRA comments deletion

[Dmitriy Govorukhin]

+1 Dmitriy,

I do not see any reason for deletion comments.
Maybe only edit operation must be allowed.

On Wed, May 16, 2018 at 12:32 PM, Igor Sapego  wrote:

> I totally agree. There is no sense in most cases in deletion
> of commentaries.
>
> There is even less sense, when you can look into ticket
> history and see all the removed comments anyway.
>
> Best Regards,
> Igor
>
> On Wed, May 16, 2018 at 12:27 PM, Dmitry Pavlov 
> wrote:
>
> > Hi Igniters,
> >
> > What do you think about deletion of comment in JIRA tickets? I constantly
> > see that participants add comments, and then delete them.
> >
> > IMO , we have partially lost the history of problem research, and we can
> > lose interesting ideas about the problem causes; or already tested
> > hypotheses.
> >
> > I understand that the commentary may be outdated, but it can be
> underlined
> > by the second comment, which speaks about it explicitly.
> >
> > Please share your vision.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
>

Re: work with files and directories

[Dmitry Pavlov]

Andrey Gura expressed in words what I also thought.

I agree if we extract common code to some kind of file utils.

In the same time creating common file operation framework is not possible
because of different nature of WAL, Page Store and other components using
files.

ср, 16 мая 2018 г. в 11:27, Dmitriy Govorukhin :

> Andrey,
>
> My point is, it will be very cool if there is some component who will know
> about persistence folder and files,
> and we can move all generic code, for work with files,  to this component.
>
> On Wed, May 16, 2018 at 12:59 AM, Pavel Kovalenko 
> wrote:
>
> > Andrey,
> >
> > I think the main idea of that not about how to unify writing content to
> > file. It's about creating peristence files and folders. For other
> > persistence components (WAL, Checkpoint, etc.) it should be like
> > FileFactory object with methods like "public File
> > getOrCreatePartitionFile(...), public void commitFIle(..) and etc". So,
> all
> > logic about how files should look will be moved to centralized point and
> it
> > will be more easier to understand our persistence structure.
> >
> > 2018-05-16 0:42 GMT+03:00 Andrey Gura :
> >
> > > Hi,
> > >
> > > I understand you idea but it just increases dependencies of different
> > > component from one that is in general bad practice.
> > >
> > > We have different components where each one can use different approach
> > for
> > > file management. For example page store and WAL have different file IO
> > > implementations due to performance reasons and we have to provide
> > different
> > > mechanics for work with files.
> > >
> > > Of course we can refactor mentioned components in more structured
> manner
> > > but we should not strongly link it with one implementation.
> > >
> > > вт, 15 мая 2018 г., 20:10 Dmitry Pavlov :
> > >
> > > > Hi Maxim,
> > > >
> > > > FileWriteAheadLogManager  &  FsyncModeFileWriteAheadLogManager  were
> > > > intentionally copy-pasted in hope we will soon delete FsyncManager.
> > > >
> > > > But it is still shows this tool works good. Probably we could
> integrate
> > > > this tool to our processes.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > >
> > > > вт, 15 мая 2018 г. в 20:06, Maxim Muzafarov :
> > > >
> > > > > +1 also for something like "resource manager".
> > > > >
> > > > > Recently, I've found for myself sonarcloud.io tool for code
> > analisys.
> > > > It's
> > > > > free for open source project and I've made Ignite project initial
> run
> > > > [1].
> > > > >
> > > > > I've prepeared analisys for mysefl and found a lot of duplicated
> code
> > > > > blocks [1]. Of course it's not the ideal tool but gave us direction
> > of
> > > > > thoughts. E.g. these classes [3]:
> > > > > 1) FileWriteAheadLogManager.java
> > > > > 2) FsyncModeFileWriteAheadLogManager.java
> > > > >
> > > > >
> > > > > [1] https://sonarcloud.io/dashboard?id=org.apache.
> > > ignite%3Aapache-ignite
> > > > > [2]
> > > > >
> > > > >
> > > > https://sonarcloud.io/component_measures?id=org.
> > > apache.ignite%3Aapache-ignite=duplicated_blocks
> > > > > [3]
> > > > >
> > > > >
> > > > https://sonarcloud.io/component_measures?id=org.
> > > apache.ignite%3Aapache-ignite=duplicated_blocks&
> > > selected=org.apache.ignite%3Aignite-core%3Asrc%2Fmain%
> > > 2Fjava%2Forg%2Fapache%2Fignite%2Finternal%2Fprocessors%2Fcache%
> > > 2Fpersistence%2Fwal%2FFsyncModeFileWriteAheadLogManager.java
> > > > >
> > > > > вт, 15 мая 2018 г. в 19:26, Pavel Kovalenko :
> > > > >
> > > > > > +1 to this approach,
> > > > > >
> > > > > > It can be also very helpful in failover scenarios when something
> > > wrong
> > > > > > happened with disk. In this case we're reducing the number of
> > points
> > > of
> > > > > > failure.
> > > > > >
> > > > > > 2018-05-15 18:37 GMT+03:00 Dmitriy Govorukhin <
> > > > > > dmitriy.govoruk...@gmail.com>
> > > > > > :
> > > > > >
> > > > > > > Hi Ignite,
> > > > > > >
> > > > > > > Do we have a general approach to work with a file and
> > directories?
> > > > > > > I see many duplication logic for write through .tmp file.
> > > > > > >
> > > > > > > For example,
> > > > > > >
> > > > > > > GridCacheDatabaseSharedManager.writeCheckpointEntry();
> > > > > > > GridCacheDatabaseSharedManage.nodeStart();
> > > > > > > FileWriteAheadLogManager.FileArchiver.archiveSegment();
> > > > > > >
> > > > > > > All of these methods implement the same logic, write to tmp
> file
> > > and
> > > > > > rename
> > > > > > > to normal name.
> > > > > > >
> > > > > > > I guess, will be better if we stopping write duplication logic
> > code
> > > > and
> > > > > > > start to consolidate all in one place.
> > > > > > >
> > > > > > > Also, I think that current approach to creating files is not
> > quite
> > > > > right
> > > > > > > faithful. Each internal component
> > > > > > > create/delete files inside himself, and 

Re: Thin clients features wiki page

[Guru Stron]

 Hi Igor,

Nice one!

On 16 May 2018 at 11:26, Igor Sapego  wrote:

> Pavel,
>
> This is about concurrent usage of the same connection (client)
> by several threads.
>
> By the ways guys, I wanted to ask you, if your clients support this
> feature, as I was not sure. I mean, protocol seems to be designed
> to support such use-case, but I was not sure about clients.
>
> Best Regards,
> Igor
>
> On Tue, May 15, 2018 at 10:46 PM, Pavel Tupitsyn 
> wrote:
>
> > Hi Igor,
> >
> > Thanks for creating this!
> > One question: what is `Multithreading` feature?
> >
> > Pavel
> >
> > On Tue, May 15, 2018 at 9:45 PM, Denis Magda 
> wrote:
> >
> > > Igor,
> > >
> > > That's a valid point. Will see how it goes. As for the new
> documentation
> > > engine, there are no more arguments. We will try to migrate within 2.6.
> > > Just need to find more contributors who would help with this.
> > >
> > > --
> > > Denis
> > >
> > > On Tue, May 15, 2018 at 2:11 AM, Igor Sapego 
> wrote:
> > >
> > > > Thanks for proposals, guys, I will do this.
> > > >
> > > > Denis,
> > > > Readme.io is not very convenient for some big tables. They look OK,
> > > > while they have 3-4 columns, but if we are going to add more clients
> > > > (or should I say "when") it is going to be a mess. This may be a one
> > > > more argument when we consider to change documentation engine.
> > > >
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Tue, May 15, 2018 at 2:37 AM, Denis Magda 
> > > wrote:
> > > >
> > > >> Igor, thanks for putting together the page.
> > > >>
> > > >> As for the immediate improvements, I'm backing up Alexey's
> > suggestions.
> > > >>
> > > >> This page deserves to be moved to the readme.io. We'll do that once
> > > it's
> > > >> sorted out how to group the thin clients' documentation.
> > > >>
> > > >> --
> > > >> Denis
> > > >>
> > > >> On Mon, May 14, 2018 at 12:39 PM, Alexey Kosenchuk <
> > > >> alexey.kosenc...@nobitlost.com> wrote:
> > > >>
> > > >>> Hi Igor,
> > > >>>
> > > >>> "Get Binary Cache" (if it is about getting a complex object in a
> > > >>> "binary" form, w/o deserialization) - is supported by NodeJS:
> > > >>> BinaryObject is returned for a complex object if an app has not
> > > >>> specified another JavaScript Object for deserialization.
> > > >>>
> > > >>> Maybe worth to add type registration functionality:
> > > >>> - complex object type registration (supported by NodeJS)
> > > >>> - enum type registration (not supported by NodeJS)
> > > >>> - type name registration (not supported by NodeJS)
> > > >>>
> > > >>> Also, maybe add a list of all type codes, supported for read and
> > write.
> > > >>> But not sure, as all of them are supported by all three clients.
> > > >>>
> > > >>> Thanks,
> > > >>> -Alexey
> > > >>>
> > > >>> 14.05.2018 22:06, Igor Sapego пишет:
> > > >>>
> > > >>> Hello Igniters,
> > > 
> > >  I've created a new page in wiki, that summarizes a features
> > >  availability of thin clients. It should help us to plan
> development
> > >  of thin clients while also helping out users to understand a state
> > >  of clients.
> > > 
> > >  Check it out and tell me what you think. And if there are some
> > >  mistakes, don't hesitate telling me.
> > > 
> > >  [1] -
> > >  https://cwiki.apache.org/confluence/display/IGNITE/Thin+clie
> > >  nts+features
> > > 
> > >  Best Regards,
> > >  Igor
> > > 
> > > 
> > > >>
> > > >
> > >
> >
>

Re: Avoid JIRA comments deletion

[Igor Sapego]

I totally agree. There is no sense in most cases in deletion
of commentaries.

There is even less sense, when you can look into ticket
history and see all the removed comments anyway.

Best Regards,
Igor

On Wed, May 16, 2018 at 12:27 PM, Dmitry Pavlov 
wrote:

> Hi Igniters,
>
> What do you think about deletion of comment in JIRA tickets? I constantly
> see that participants add comments, and then delete them.
>
> IMO , we have partially lost the history of problem research, and we can
> lose interesting ideas about the problem causes; or already tested
> hypotheses.
>
> I understand that the commentary may be outdated, but it can be underlined
> by the second comment, which speaks about it explicitly.
>
> Please share your vision.
>
> Sincerely,
> Dmitriy Pavlov
>

Avoid JIRA comments deletion

[Dmitry Pavlov]

Hi Igniters,

What do you think about deletion of comment in JIRA tickets? I constantly
see that participants add comments, and then delete them.

IMO , we have partially lost the history of problem research, and we can
lose interesting ideas about the problem causes; or already tested
hypotheses.

I understand that the commentary may be outdated, but it can be underlined
by the second comment, which speaks about it explicitly.

Please share your vision.

Sincerely,
Dmitriy Pavlov

Re: async operation is not fair async

[Alexey Goncharuk]

Dmitriy,

I will add technical details to the ticket, however, looks like there is
still no consensus on how this change should be presented to a user. It
would be ok if we changed this behavior in Ignite 3.0, but for one of the
next point releases we have to agree how this should be enabled/disabled
(or whether we should delay this change to 3.0 at all).

2018-05-15 22:13 GMT+03:00 Dmitriy Govorukhin 
:

>  Alexey,
>
> Any updates?
>
> On Mon, May 14, 2018 at 6:19 PM, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com> wrote:
>
> > Alexey,
> >
> > Could you please add more description information for this task? [1]
> > Perhaps, base steps for implementation.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-8475
> >
> > On Mon, May 14, 2018 at 4:58 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> >> Another +1 for the true asynchronous approach. I remember a while ago
> one
> >> of the Ignite users raised a similar question regarding the *async
> method
> >> being blocked on establishing a TCP connection.
> >>
> >> As far as deadlocks go, I have a counter-example. Currently, we check
> the
> >> thread-local chain only for a single cache, so if I run the following
> >> code:
> >> cache1.getAsync(k1);
> >> cache2.getAsync(k2);
> >> then the deadlock is still possible, and I did not see a single user
> >> complaining about unexpected deadlocks. Rather than implementing this
> >> cross-cache chain (which would probably add another overhead), I would
> >> make
> >> it consistent and allow operations to be run in parallel.
> >>
> >> There are many use-cases when having true async operations dramatically
> >> improve performance. Consider, for example, a streaming example when
> keys
> >> are being pushed by a client to a cluster. Currently, to run effective
> >> processing, the user will have to use a data streamer with custom keys
> >> receiver which may be a huge usability downside. Async operations can
> >> utilize the cluster resources very efficiently.
> >>
> >> Finally, if we want to be on the safe side, we can keep the operation
> >> chain
> >> inside a transaction. I see absolutely no point in maintaining this
> chain
> >> outside of transactions.
> >>
> >> --AG
> >>
> >> 2018-05-14 16:01 GMT+03:00 Dmitriy Govorukhin <
> >> dmitriy.govoruk...@gmail.com>
> >> :
> >>
> >> > Andrey,
> >> >
> >> > Do you prefer change behavior at runtime?
> >> > I guess will be better have different methods for getting cache
> instance
> >> > with fair and not fair sync.
> >> >
> >> > On Mon, May 14, 2018 at 3:39 PM, Andrey Gura 
> wrote:
> >> >
> >> > > +1 for fair async operations.
> >> > >
> >> > > But I don't like idea use withFairSync() method. We added xxxAsync()
> >> > > methods recently and withAsync() is deprecated.
> >> > >
> >> > > I think we should just make methods are async in nature and provide
> >> > > ability of switching to the old behaviour using flag or property.
> >> > >
> >> > > On Fri, May 11, 2018 at 11:00 PM, Dmitriy Setrakyan
> >> > >  wrote:
> >> > > > Vladimir,
> >> > > >
> >> > > > In general I agree, but I do get greatly *close-minded* (pun
> >> intended)
> >> > > > whenever users' code that worked for the past several years all
> of a
> >> > > sudden
> >> > > > gets deadlocked after an upgrade. Making this feature optional is
> >> even
> >> > > > worse and more confusing. In this case the best action is no
> action
> >> at
> >> > > all.
> >> > > >
> >> > > > BTW, would be interesting to find out how Oracle async driver
> >> behaves
> >> > in
> >> > > > this case.
> >> > > >
> >> > > > D.
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, May 11, 2018 at 8:29 PM, Vladimir Ozerov <
> >> voze...@gridgain.com
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > >> Guys,
> >> > > >>
> >> > > >> To build a great product we should be open minded and look to the
> >> > > future,
> >> > > >> not to the past.
> >> > > >>
> >> > > >> Dima raised very valid point - why async is not async? Current
> >> > > programming
> >> > > >> culture and demanding performance requirements pushes users
> towards
> >> > > >> reactive-style programming. I do not want my thread to ever be
> >> > blocked.
> >> > > >> Instead, I want to send a number of concurrent commands and
> >> optionally
> >> > > >> subscribe to final result. So trully async API makes total sense
> to
> >> > me.
> >> > > >>
> >> > > >> But personally, my primary interest in this area is SQL. Oracle
> is
> >> > > >> preparing new async driver. ADBA - async database access. It was
> >> > > presented
> >> > > >> on recent JavaOne [1]. It is under active development right now -
> >> juse
> >> > > >> weave through the mailing list [2]. Some prototypes are already
> >> there
> >> > > [3].
> >> > > >> PostgreSQL community even started adopted it [4]!
> >> > > >>
> >> > > >> I am not pushing for immediate actions, but at least we should
> >> > > 

Re: Ignite hang on a complex SQL join occurring on 2 server nodes

[Ilya Kasnacheev]

Hello!

* The message that you provided most likely means there's a prolonged
deadlock or some other severe problem that made your cluster inoperational.
* You are using putAll which is known to cause deadlocks if used in
parallel and maps in question are not sorted.
* Is the map that you're passing to putAll sorted? (e.g. TreeMap)

Regards,

-- 
Ilya Kasnacheev

2018-05-15 19:33 GMT+03:00 mmyoussef :

> The scenario is
> 1- Data is loaded from cassandra to a lookup cache -> replicated cache
> 2- Data is fetched from kafka input topic to a map
> 3- the map is inserted - using putall method - to another cache ->
> partitioned cache
> 4- a complex join is done between both caches
> 5- The result set is processed and inserted into layer 2 cache
> 6- Then processed again to a layer 3 cache then to kafka output topic
>
> the jar is compiled and run on 2 different nodes.
>
> some records are fetched, processing runs on both nodes -results of the
> first batch are not accurate- and then hangs and keeps logging this message
> ?!
>
> 10/05/2018 16:39:48  INFO [tcp-disco-stats-printer-#4%cluster-VEON%]
> TcpDiscoverySpi: Discovery SPI statistics [statistics=TcpDiscoveryStatistics
>
> [joinStartedTs=1525962688220, joinFinishedTs=1525962706508,
> crdSinceTs=1525962706498, joinedNodesCnt=1, failedNodesCnt=0,
> leftNodesCnt=0,
> ackTimeoutsCnt=0, sockTimeoutsCnt=0, rcvdMsgs=
> {TcpDiscoveryMetricsUpdateMessage=474, TcpDiscoveryNodeAddedMessage=1,
> TcpDiscoveryNodeAddFinishedMessage=1, TcpDiscoveryJoinRequestMessage=2,
> TcpDiscoveryDiscardMessage=35, TcpDiscoveryConnectionCheckMessage=706,
> TcpDiscoveryCustomEventMessage=39}, procMsgs=
> {TcpDiscoveryMetricsUpdateMessage=715, TcpDiscoveryNodeAddedMessage=1,
> TcpDiscoveryNodeAddFinishedMessage=1, TcpDiscoveryJoinRequestMessage=2,
> TcpDiscoveryCustomEventMessage=53, TcpDiscoveryDiscardMessage=76},
> avgMsgsSndTimes={TcpDiscoveryMetricsUpdateMessage=0,
> TcpDiscoveryNodeAddedMessage=10, TcpDiscoveryNodeAddFinishedMessage=0,
> TcpDiscoveryJoinRequestMessage=10, TcpDiscoveryConnectionCheckMessage=0,
> TcpDiscoveryDiscardMessage=0, TcpDiscoveryCustomEventMessage=0},
> maxMsgsSndTimes={TcpDiscoveryMetricsUpdateMessage=10,
> TcpDiscoveryNodeAddedMessage=10, TcpDiscoveryNodeAddFinishedMessage=0,
> TcpDiscoveryJoinRequestMessage=10, TcpDiscoveryConnectionCheckMessage=42,
> TcpDiscoveryDiscardMessage=0, TcpDiscoveryCustomEventMessage=0},
> sentMsgs=
> {TcpDiscoveryMetricsUpdateMessage=474, TcpDiscoveryNodeAddedMessage=1,
> TcpDiscoveryNodeAddFinishedMessage=1, TcpDiscoveryJoinRequestMessage=1,
> TcpDiscoveryConnectionCheckMessage=706, TcpDiscoveryDiscardMessage=35,
> TcpDiscoveryCustomEventMessage=33}, avgMsgsAckTimes=
> {TcpDiscoveryMetricsUpdateMessage=0, TcpDiscoveryNodeAddedMessage=10,
> TcpDiscoveryNodeAddFinishedMessage=0, TcpDiscoveryJoinRequestMessage=10,
> TcpDiscoveryConnectionCheckMessage=0, TcpDiscoveryDiscardMessage=0,
> TcpDiscoveryCustomEventMessage=0}, maxMsgsAckTimes=
> {TcpDiscoveryMetricsUpdateMessage=10, TcpDiscoveryNodeAddedMessage=10,
> TcpDiscoveryNodeAddFinishedMessage=0, TcpDiscoveryJoinRequestMessage=10,
> TcpDiscoveryConnectionCheckMessage=42, TcpDiscoveryDiscardMessage=0,
> TcpDiscoveryCustomEventMessage=0}, avgMsgQueueTime=0, maxMsgQueueTime=11,
> ringMsgsSent=35, avgRingMsgTime=0, maxRingMsgTime=121,
> maxRingTimeMsgCls=TcpDiscoveryNodeAddedMessage, avgMsgProcTime=0,
> maxMsgProcTime=91, maxProcTimeMsgCls=TcpDiscoveryJoinRequestMessage,
> sockReadersCreated=3, sockReadersRmv=2, avgSrvSockInitTime=3,
> maxSrvSockInitTime=10, clientSockCreatedCnt=2, avgClientSockInitTime=15,
> maxClientSockInitTime=21, pendingMsgsRegistered=35,
> pendingMsgsDiscarded=0],
> spiState=CONNECTED, coord=TcpDiscoveryNode [id=8a03f4a3-a631-42e7-bdf2-
> b062e1e977b6, addrs=[0:0:0:0:0:0:0:1, 10.19.1.14, 127.0.0.1,
> 172.16.44.139,
> 172.23.48.1], sockAddrs=[WEGMM250132-O5F.TD.TERADATA.COM/10.19.1.14:47501,
>
> /172.16.44.139:47501, /172.23.48.1:47501, /0:0:0:0:0:0:0:1:47501,
> /127.0.0.1:47501], discPort=47501, order=1, intOrder=1,
> lastExchangeTime=1525962688210, loc=true, ver=2.0.0#20170430-sha1:d4eef3c6,
>
> isClient=false], next=TcpDiscoveryNode [id=ee98d2ff-40fe-4981-8a59-
> 1b12b478bc11, addrs=[0:0:0:0:0:0:0:1, 10.19.1.14, 127.0.0.1,
> 172.16.44.139,
> 172.23.48.1], sockAddrs=[WEGMM250132-O5F.TD.TERADATA.COM/10.19.1.14:47500,
>
> /172.23.48.1:47500, /0:0:0:0:0:0:0:1:47500, /127.0.0.1:47500,
> /172.16.44.139:47500], discPort=47500, order=2, intOrder=2,
> lastExchangeTime=1525962714266, loc=false, ver=2.0.0#20170430-sha1:d4eef3c6,
>
> isClient=false], intOrder=1, topSize=2, leavingNodesSize=0,
> failedNodesSize=0,
> joiningNodesSize=0, pendingCustomMsgs=0, msgWorker.queue.size=0,
> clients=0,
> clientWorkers=0, lastUpdate=05/10/2018 16:39:47, heapFree=5727M,
> heapTotal=5888M]
>
>
>
> some times I get this message too :
> [GridCachePartitionExchangeManager] Failed to wait for initial partition
> map
> exchange. Possible reasons are:
>   ^-- 

Re: supporting different configuration format json,yaml...

[Igor Sapego]

Dmitriy,

I guess, you can find some reasons in this discussion :)

Best Regards,
Igor

On Wed, May 16, 2018 at 11:18 AM, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com> wrote:

> Folks,
>
> Why do you interpret the question as a necessity for action?
> In my first message, "Are there any reasons why ignite does not support
> yaml or json format for configuration? or some other popular format?"
>
> On Wed, May 16, 2018 at 10:35 AM, Dmitriy Setrakyan  >
> wrote:
>
> > I generally agree with Andrey Gura. I do not think that the effort
> required
> > to implement another format for configuration justifies the means. Let's
> > stick to the Spring configuration.
> >
> > D.
> >
> > On Wed, May 16, 2018 at 10:10 AM, Pavel Tupitsyn 
> > wrote:
> >
> > > Andrey G, +1
> > >
> > >
> > > Andrey K,
> > >
> > > > json-schema
> > > It's a draft. XML schema is a mature standard.
> > >
> > > > eye fatigue
> > > Here is Ignite.NET config:   > > name='myCache'   />
> > > Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
> > > "Replicated", "name": "myCache" }
> > > Enough said I guess :)
> > >
> > >
> > >
> > > On Wed, May 16, 2018 at 12:48 AM, Andrey Gura 
> wrote:
> > >
> > > > Guys,
> > > >
> > > > Spring is IoC and you can't offer any format that can  replace
> Spring.
> > It
> > > > will just limited DSL.
> > > >
> > > > Once again. We have enough problems with main functionality. Why do
> you
> > > > want to focus on minor features?
> > > >
> > > >
> > > > вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov :
> > > >
> > > > > Pavel,
> > > > >
> > > > > One can use json-schema if necessary. Of course, XML is more
> powerful
> > > in
> > > > > many aspects, but produces more eye fatigue for humans. Of course,
> we
> > > are
> > > > > to stay with XML if switching to another configuration format
> > requires
> > > > > significant effort.
> > > > >
> > > > > BTW, first time I heard about JSON from [1] : " JSON is like XML,
> > > except
> > > > it
> > > > > doesn't suck ".
> > > > >
> > > > > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> > > > master/Readme.txt
> > > > >
> > > > >
> > > > > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn :
> > > > >
> > > > > > JSON sucks for config files anyway, there are no comments, no
> > > schemas,
> > > > > > quotes are required around keys, etc
> > > > > >
> > > > > > Just answer one question: what issue are we trying to solve?
> > > > > > XML is not a problem IMO, complexity of our config is.
> > > > > >
> > > > > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego  >
> > > > wrote:
> > > > > >
> > > > > > > How are you going to translate this YAML config to Spring
> config?
> > > > > > >
> > > > > > > How would you deal with something like [1]?
> > > > > > >
> > > > > > > [1] -
> > > > > > > https://github.com/apache/ignite/blob/master/modules/
> > > > > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Igor
> > > > > > >
> > > > > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <
> > > jokse...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Igor,
> > > > > > > >
> > > > > > > > Just get one of the config samples and translate it directly
> to
> > > > YAML:
> > > > > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > > > > YAML - https://pastebin.com/akGu3e81
> > > > > > > >
> > > > > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego :
> > > > > > > >
> > > > > > > > > Guys, if you think the YAML or JSON would be better, how
> > about
> > > > > > > > > you provide us a brief example of how such configs are
> going
> > to
> > > > > > > > > look, so we can compare and see, if this ever have any
> sense.
> > > > > > > > >
> > > > > > > > > Best Regards,
> > > > > > > > > Igor
> > > > > > > > >
> > > > > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > > > > ilya.kasnach...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hello!
> > > > > > > > > >
> > > > > > > > > > Maybe we should take .Net configuration as a standard,
> > extend
> > > > it
> > > > > to
> > > > > > > > JSON
> > > > > > > > > > and YAML?
> > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > > > > >
> > > > > > > > > > It should be fairly robust, and there's much less
> > > boilerplate.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Ilya Kasnacheev
> > > > > > > > > >
> > > > > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <
> > > jokse...@gmail.com
> > > > >:
> > > > > > > > > >
> > > > > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > > > > >
> > > > > > > > > > > Since we're moving Ignite towards outside of Java
> world,
> > we
> > > > > > 

[jira] [Created] (IGNITE-8507) SQL: Print a warning if SQL index inline size is not sufficient

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8507:
---

 Summary: SQL: Print a warning if SQL index inline size is not 
sufficient
 Key: IGNITE-8507
 URL: https://issues.apache.org/jira/browse/IGNITE-8507
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.6


"Inline size" is very important optimization. When not used secondary index 
lookup may become extraordinary slow. 
Let's print a warning when certain indexes cannot hold their values in index 
pages, so that user can adjust index configuration accordingly.



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

Re: work with files and directories

[Dmitriy Govorukhin]

Andrey,

My point is, it will be very cool if there is some component who will know
about persistence folder and files,
and we can move all generic code, for work with files,  to this component.

On Wed, May 16, 2018 at 12:59 AM, Pavel Kovalenko 
wrote:

> Andrey,
>
> I think the main idea of that not about how to unify writing content to
> file. It's about creating peristence files and folders. For other
> persistence components (WAL, Checkpoint, etc.) it should be like
> FileFactory object with methods like "public File
> getOrCreatePartitionFile(...), public void commitFIle(..) and etc". So, all
> logic about how files should look will be moved to centralized point and it
> will be more easier to understand our persistence structure.
>
> 2018-05-16 0:42 GMT+03:00 Andrey Gura :
>
> > Hi,
> >
> > I understand you idea but it just increases dependencies of different
> > component from one that is in general bad practice.
> >
> > We have different components where each one can use different approach
> for
> > file management. For example page store and WAL have different file IO
> > implementations due to performance reasons and we have to provide
> different
> > mechanics for work with files.
> >
> > Of course we can refactor mentioned components in more structured manner
> > but we should not strongly link it with one implementation.
> >
> > вт, 15 мая 2018 г., 20:10 Dmitry Pavlov :
> >
> > > Hi Maxim,
> > >
> > > FileWriteAheadLogManager  &  FsyncModeFileWriteAheadLogManager  were
> > > intentionally copy-pasted in hope we will soon delete FsyncManager.
> > >
> > > But it is still shows this tool works good. Probably we could integrate
> > > this tool to our processes.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > >
> > > вт, 15 мая 2018 г. в 20:06, Maxim Muzafarov :
> > >
> > > > +1 also for something like "resource manager".
> > > >
> > > > Recently, I've found for myself sonarcloud.io tool for code
> analisys.
> > > It's
> > > > free for open source project and I've made Ignite project initial run
> > > [1].
> > > >
> > > > I've prepeared analisys for mysefl and found a lot of duplicated code
> > > > blocks [1]. Of course it's not the ideal tool but gave us direction
> of
> > > > thoughts. E.g. these classes [3]:
> > > > 1) FileWriteAheadLogManager.java
> > > > 2) FsyncModeFileWriteAheadLogManager.java
> > > >
> > > >
> > > > [1] https://sonarcloud.io/dashboard?id=org.apache.
> > ignite%3Aapache-ignite
> > > > [2]
> > > >
> > > >
> > > https://sonarcloud.io/component_measures?id=org.
> > apache.ignite%3Aapache-ignite=duplicated_blocks
> > > > [3]
> > > >
> > > >
> > > https://sonarcloud.io/component_measures?id=org.
> > apache.ignite%3Aapache-ignite=duplicated_blocks&
> > selected=org.apache.ignite%3Aignite-core%3Asrc%2Fmain%
> > 2Fjava%2Forg%2Fapache%2Fignite%2Finternal%2Fprocessors%2Fcache%
> > 2Fpersistence%2Fwal%2FFsyncModeFileWriteAheadLogManager.java
> > > >
> > > > вт, 15 мая 2018 г. в 19:26, Pavel Kovalenko :
> > > >
> > > > > +1 to this approach,
> > > > >
> > > > > It can be also very helpful in failover scenarios when something
> > wrong
> > > > > happened with disk. In this case we're reducing the number of
> points
> > of
> > > > > failure.
> > > > >
> > > > > 2018-05-15 18:37 GMT+03:00 Dmitriy Govorukhin <
> > > > > dmitriy.govoruk...@gmail.com>
> > > > > :
> > > > >
> > > > > > Hi Ignite,
> > > > > >
> > > > > > Do we have a general approach to work with a file and
> directories?
> > > > > > I see many duplication logic for write through .tmp file.
> > > > > >
> > > > > > For example,
> > > > > >
> > > > > > GridCacheDatabaseSharedManager.writeCheckpointEntry();
> > > > > > GridCacheDatabaseSharedManage.nodeStart();
> > > > > > FileWriteAheadLogManager.FileArchiver.archiveSegment();
> > > > > >
> > > > > > All of these methods implement the same logic, write to tmp file
> > and
> > > > > rename
> > > > > > to normal name.
> > > > > >
> > > > > > I guess, will be better if we stopping write duplication logic
> code
> > > and
> > > > > > start to consolidate all in one place.
> > > > > >
> > > > > > Also, I think that current approach to creating files is not
> quite
> > > > right
> > > > > > faithful. Each internal component
> > > > > > create/delete files inside himself, and nobody knows where which
> > > files
> > > > > > located.
> > > > > >
> > > > > > I suggest refactoring code and create something (maybe new
> manager)
> > > > that
> > > > > > will know about all files inside the node. All internal
> components
> > > must
> > > > > > create files only through this one.
> > > > > >
> > > > > > It makes help to write tests for persistence easier and reduce
> > > > > duplication
> > > > > > code in working with files.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Thin clients features wiki page

[Igor Sapego]

Pavel,

This is about concurrent usage of the same connection (client)
by several threads.

By the ways guys, I wanted to ask you, if your clients support this
feature, as I was not sure. I mean, protocol seems to be designed
to support such use-case, but I was not sure about clients.

Best Regards,
Igor

On Tue, May 15, 2018 at 10:46 PM, Pavel Tupitsyn 
wrote:

> Hi Igor,
>
> Thanks for creating this!
> One question: what is `Multithreading` feature?
>
> Pavel
>
> On Tue, May 15, 2018 at 9:45 PM, Denis Magda  wrote:
>
> > Igor,
> >
> > That's a valid point. Will see how it goes. As for the new documentation
> > engine, there are no more arguments. We will try to migrate within 2.6.
> > Just need to find more contributors who would help with this.
> >
> > --
> > Denis
> >
> > On Tue, May 15, 2018 at 2:11 AM, Igor Sapego  wrote:
> >
> > > Thanks for proposals, guys, I will do this.
> > >
> > > Denis,
> > > Readme.io is not very convenient for some big tables. They look OK,
> > > while they have 3-4 columns, but if we are going to add more clients
> > > (or should I say "when") it is going to be a mess. This may be a one
> > > more argument when we consider to change documentation engine.
> > >
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Tue, May 15, 2018 at 2:37 AM, Denis Magda 
> > wrote:
> > >
> > >> Igor, thanks for putting together the page.
> > >>
> > >> As for the immediate improvements, I'm backing up Alexey's
> suggestions.
> > >>
> > >> This page deserves to be moved to the readme.io. We'll do that once
> > it's
> > >> sorted out how to group the thin clients' documentation.
> > >>
> > >> --
> > >> Denis
> > >>
> > >> On Mon, May 14, 2018 at 12:39 PM, Alexey Kosenchuk <
> > >> alexey.kosenc...@nobitlost.com> wrote:
> > >>
> > >>> Hi Igor,
> > >>>
> > >>> "Get Binary Cache" (if it is about getting a complex object in a
> > >>> "binary" form, w/o deserialization) - is supported by NodeJS:
> > >>> BinaryObject is returned for a complex object if an app has not
> > >>> specified another JavaScript Object for deserialization.
> > >>>
> > >>> Maybe worth to add type registration functionality:
> > >>> - complex object type registration (supported by NodeJS)
> > >>> - enum type registration (not supported by NodeJS)
> > >>> - type name registration (not supported by NodeJS)
> > >>>
> > >>> Also, maybe add a list of all type codes, supported for read and
> write.
> > >>> But not sure, as all of them are supported by all three clients.
> > >>>
> > >>> Thanks,
> > >>> -Alexey
> > >>>
> > >>> 14.05.2018 22:06, Igor Sapego пишет:
> > >>>
> > >>> Hello Igniters,
> > 
> >  I've created a new page in wiki, that summarizes a features
> >  availability of thin clients. It should help us to plan development
> >  of thin clients while also helping out users to understand a state
> >  of clients.
> > 
> >  Check it out and tell me what you think. And if there are some
> >  mistakes, don't hesitate telling me.
> > 
> >  [1] -
> >  https://cwiki.apache.org/confluence/display/IGNITE/Thin+clie
> >  nts+features
> > 
> >  Best Regards,
> >  Igor
> > 
> > 
> > >>
> > >
> >
>

Re: supporting different configuration format json,yaml...

[Dmitriy Govorukhin]

Folks,

Why do you interpret the question as a necessity for action?
In my first message, "Are there any reasons why ignite does not support
yaml or json format for configuration? or some other popular format?"

On Wed, May 16, 2018 at 10:35 AM, Dmitriy Setrakyan 
wrote:

> I generally agree with Andrey Gura. I do not think that the effort required
> to implement another format for configuration justifies the means. Let's
> stick to the Spring configuration.
>
> D.
>
> On Wed, May 16, 2018 at 10:10 AM, Pavel Tupitsyn 
> wrote:
>
> > Andrey G, +1
> >
> >
> > Andrey K,
> >
> > > json-schema
> > It's a draft. XML schema is a mature standard.
> >
> > > eye fatigue
> > Here is Ignite.NET config:   > name='myCache'   />
> > Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
> > "Replicated", "name": "myCache" }
> > Enough said I guess :)
> >
> >
> >
> > On Wed, May 16, 2018 at 12:48 AM, Andrey Gura  wrote:
> >
> > > Guys,
> > >
> > > Spring is IoC and you can't offer any format that can  replace Spring.
> It
> > > will just limited DSL.
> > >
> > > Once again. We have enough problems with main functionality. Why do you
> > > want to focus on minor features?
> > >
> > >
> > > вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov :
> > >
> > > > Pavel,
> > > >
> > > > One can use json-schema if necessary. Of course, XML is more powerful
> > in
> > > > many aspects, but produces more eye fatigue for humans. Of course, we
> > are
> > > > to stay with XML if switching to another configuration format
> requires
> > > > significant effort.
> > > >
> > > > BTW, first time I heard about JSON from [1] : " JSON is like XML,
> > except
> > > it
> > > > doesn't suck ".
> > > >
> > > > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> > > master/Readme.txt
> > > >
> > > >
> > > > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn :
> > > >
> > > > > JSON sucks for config files anyway, there are no comments, no
> > schemas,
> > > > > quotes are required around keys, etc
> > > > >
> > > > > Just answer one question: what issue are we trying to solve?
> > > > > XML is not a problem IMO, complexity of our config is.
> > > > >
> > > > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego 
> > > wrote:
> > > > >
> > > > > > How are you going to translate this YAML config to Spring config?
> > > > > >
> > > > > > How would you deal with something like [1]?
> > > > > >
> > > > > > [1] -
> > > > > > https://github.com/apache/ignite/blob/master/modules/
> > > > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <
> > jokse...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Igor,
> > > > > > >
> > > > > > > Just get one of the config samples and translate it directly to
> > > YAML:
> > > > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > > > YAML - https://pastebin.com/akGu3e81
> > > > > > >
> > > > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego :
> > > > > > >
> > > > > > > > Guys, if you think the YAML or JSON would be better, how
> about
> > > > > > > > you provide us a brief example of how such configs are going
> to
> > > > > > > > look, so we can compare and see, if this ever have any sense.
> > > > > > > >
> > > > > > > > Best Regards,
> > > > > > > > Igor
> > > > > > > >
> > > > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > > > ilya.kasnach...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > Maybe we should take .Net configuration as a standard,
> extend
> > > it
> > > > to
> > > > > > > JSON
> > > > > > > > > and YAML?
> > > > > > > > >
> > > > > > > > > 
> > > > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > > > >
> > > > > > > > > It should be fairly robust, and there's much less
> > boilerplate.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Ilya Kasnacheev
> > > > > > > > >
> > > > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <
> > jokse...@gmail.com
> > > >:
> > > > > > > > >
> > > > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > > > >
> > > > > > > > > > Since we're moving Ignite towards outside of Java world,
> we
> > > > > should
> > > > > > > > > > definitely care about config usability for users who are
> > not
> > > > > > familiar
> > > > > > > > > with
> > > > > > > > > > Java/Spring.
> > > > > > > > > > If we take a look at any of our XML-configs, we can see a
> > lot
> > > > of
> > > > > > > > > > boilerplate like "", ""
> -
> > > > terms
> > > > > > > which
> > > > > > > > > say
> > > > > > > > > > nothing to users outside of Java world.
> > > > > > > > > > When I see such configs my eyes are filled with bloody
> > 

[GitHub] ignite pull request #3991: IGNITE-8161 Suspend-resume TX test is flaky on TC...

[voipp]

GitHub user voipp reopened a pull request:

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

IGNITE-8161 Suspend-resume TX test is flaky on TC (~5% fail rate)



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

$ git pull https://github.com/voipp/ignite IGNITE-8161

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

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


commit fee0950a7bb642b6be8cea7aeeeb059bf196d155
Author: voipp 
Date:   2018-05-15T15:08:05Z

IGNITE-8161 test for suspend\resume operations fixed




---

[GitHub] ignite pull request #3991: IGNITE-8161 Suspend-resume TX test is flaky on TC...

[voipp]

Github user voipp closed the pull request at:

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


---

[GitHub] ignite pull request #3661: IGNITE-7993 Striped pool can't be disabled

[gromtech]

Github user gromtech closed the pull request at:

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


---

Re: supporting different configuration format json,yaml...

[Dmitriy Setrakyan]

I generally agree with Andrey Gura. I do not think that the effort required
to implement another format for configuration justifies the means. Let's
stick to the Spring configuration.

D.

On Wed, May 16, 2018 at 10:10 AM, Pavel Tupitsyn 
wrote:

> Andrey G, +1
>
>
> Andrey K,
>
> > json-schema
> It's a draft. XML schema is a mature standard.
>
> > eye fatigue
> Here is Ignite.NET config:   name='myCache'   />
> Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
> "Replicated", "name": "myCache" }
> Enough said I guess :)
>
>
>
> On Wed, May 16, 2018 at 12:48 AM, Andrey Gura  wrote:
>
> > Guys,
> >
> > Spring is IoC and you can't offer any format that can  replace Spring. It
> > will just limited DSL.
> >
> > Once again. We have enough problems with main functionality. Why do you
> > want to focus on minor features?
> >
> >
> > вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov :
> >
> > > Pavel,
> > >
> > > One can use json-schema if necessary. Of course, XML is more powerful
> in
> > > many aspects, but produces more eye fatigue for humans. Of course, we
> are
> > > to stay with XML if switching to another configuration format requires
> > > significant effort.
> > >
> > > BTW, first time I heard about JSON from [1] : " JSON is like XML,
> except
> > it
> > > doesn't suck ".
> > >
> > > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> > master/Readme.txt
> > >
> > >
> > > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn :
> > >
> > > > JSON sucks for config files anyway, there are no comments, no
> schemas,
> > > > quotes are required around keys, etc
> > > >
> > > > Just answer one question: what issue are we trying to solve?
> > > > XML is not a problem IMO, complexity of our config is.
> > > >
> > > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego 
> > wrote:
> > > >
> > > > > How are you going to translate this YAML config to Spring config?
> > > > >
> > > > > How would you deal with something like [1]?
> > > > >
> > > > > [1] -
> > > > > https://github.com/apache/ignite/blob/master/modules/
> > > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko <
> jokse...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Igor,
> > > > > >
> > > > > > Just get one of the config samples and translate it directly to
> > YAML:
> > > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > > YAML - https://pastebin.com/akGu3e81
> > > > > >
> > > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego :
> > > > > >
> > > > > > > Guys, if you think the YAML or JSON would be better, how about
> > > > > > > you provide us a brief example of how such configs are going to
> > > > > > > look, so we can compare and see, if this ever have any sense.
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Igor
> > > > > > >
> > > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > > ilya.kasnach...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > Maybe we should take .Net configuration as a standard, extend
> > it
> > > to
> > > > > > JSON
> > > > > > > > and YAML?
> > > > > > > >
> > > > > > > > 
> > > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > > >
> > > > > > > > It should be fairly robust, and there's much less
> boilerplate.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko <
> jokse...@gmail.com
> > >:
> > > > > > > >
> > > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > > >
> > > > > > > > > Since we're moving Ignite towards outside of Java world, we
> > > > should
> > > > > > > > > definitely care about config usability for users who are
> not
> > > > > familiar
> > > > > > > > with
> > > > > > > > > Java/Spring.
> > > > > > > > > If we take a look at any of our XML-configs, we can see a
> lot
> > > of
> > > > > > > > > boilerplate like "", "" -
> > > terms
> > > > > > which
> > > > > > > > say
> > > > > > > > > nothing to users outside of Java world.
> > > > > > > > > When I see such configs my eyes are filled with bloody
> tears.
> > > > > > > > >
> > > > > > > > > I think we should really consider YAML as our additional
> > > approach
> > > > > to
> > > > > > > > > configure Ignite with full replacement instead of XML in
> > > future.
> > > > > > > > > Comparing to XML, YAML is significantly more human-readable
> > and
> > > > > > > > lightweight
> > > > > > > > > format and has stable Java library to parse and translate
> > > config
> > > > > > files
> > > > > > > to
> > > > > > > > > Java objects without extra-magic.
> > > > > > > > >
> > > > > > > > > We can find a lot of famous projects which are using YAML:
> > 

[jira] [Created] (IGNITE-8506) Visor CMD: Show consistent ID in node tables.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8506:
-

 Summary: Visor CMD: Show consistent ID in node tables.
 Key: IGNITE-8506
 URL: https://issues.apache.org/jira/browse/IGNITE-8506
 Project: Ignite
  Issue Type: Bug
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko


Add for topology command.

Check other command and add on node tables if exist.



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

Re: supporting different configuration format json,yaml...

[Pavel Tupitsyn]

Andrey G, +1


Andrey K,

> json-schema
It's a draft. XML schema is a mature standard.

> eye fatigue
Here is Ignite.NET config:  
Equivalent JSON excerpt:  "cacheConfiguration": { "cacheMode":
"Replicated", "name": "myCache" }
Enough said I guess :)



On Wed, May 16, 2018 at 12:48 AM, Andrey Gura  wrote:

> Guys,
>
> Spring is IoC and you can't offer any format that can  replace Spring. It
> will just limited DSL.
>
> Once again. We have enough problems with main functionality. Why do you
> want to focus on minor features?
>
>
> вт, 15 мая 2018 г., 23:26 Andrey Kuznetsov :
>
> > Pavel,
> >
> > One can use json-schema if necessary. Of course, XML is more powerful in
> > many aspects, but produces more eye fatigue for humans. Of course, we are
> > to stay with XML if switching to another configuration format requires
> > significant effort.
> >
> > BTW, first time I heard about JSON from [1] : " JSON is like XML, except
> it
> > doesn't suck ".
> >
> > [1] https://github.com/cajun-jsonapi/cajun-jsonapi/blob/
> master/Readme.txt
> >
> >
> > 2018-05-15 22:43 GMT+03:00 Pavel Tupitsyn :
> >
> > > JSON sucks for config files anyway, there are no comments, no schemas,
> > > quotes are required around keys, etc
> > >
> > > Just answer one question: what issue are we trying to solve?
> > > XML is not a problem IMO, complexity of our config is.
> > >
> > > On Tue, May 15, 2018 at 8:00 PM, Igor Sapego 
> wrote:
> > >
> > > > How are you going to translate this YAML config to Spring config?
> > > >
> > > > How would you deal with something like [1]?
> > > >
> > > > [1] -
> > > > https://github.com/apache/ignite/blob/master/modules/
> > > > platforms/cpp/odbc-test/config/queries-ssl-32.xml
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Tue, May 15, 2018 at 7:10 PM, Pavel Kovalenko  >
> > > > wrote:
> > > >
> > > > > Igor,
> > > > >
> > > > > Just get one of the config samples and translate it directly to
> YAML:
> > > > > XML - https://pastebin.com/wtQXXq8f
> > > > > YAML - https://pastebin.com/akGu3e81
> > > > >
> > > > > 2018-05-15 18:49 GMT+03:00 Igor Sapego :
> > > > >
> > > > > > Guys, if you think the YAML or JSON would be better, how about
> > > > > > you provide us a brief example of how such configs are going to
> > > > > > look, so we can compare and see, if this ever have any sense.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > > On Tue, May 15, 2018 at 4:20 PM, Ilya Kasnacheev <
> > > > > > ilya.kasnach...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > Maybe we should take .Net configuration as a standard, extend
> it
> > to
> > > > > JSON
> > > > > > > and YAML?
> > > > > > >
> > > > > > > 
> > > > > > > https://apacheignite-net.readme.io/docs/configuration
> > > > > > >
> > > > > > > It should be fairly robust, and there's much less boilerplate.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > > 2018-05-15 16:09 GMT+03:00 Pavel Kovalenko  >:
> > > > > > >
> > > > > > > > +1 to Dmitriy G. proposal.
> > > > > > > >
> > > > > > > > Since we're moving Ignite towards outside of Java world, we
> > > should
> > > > > > > > definitely care about config usability for users who are not
> > > > familiar
> > > > > > > with
> > > > > > > > Java/Spring.
> > > > > > > > If we take a look at any of our XML-configs, we can see a lot
> > of
> > > > > > > > boilerplate like "", "" -
> > terms
> > > > > which
> > > > > > > say
> > > > > > > > nothing to users outside of Java world.
> > > > > > > > When I see such configs my eyes are filled with bloody tears.
> > > > > > > >
> > > > > > > > I think we should really consider YAML as our additional
> > approach
> > > > to
> > > > > > > > configure Ignite with full replacement instead of XML in
> > future.
> > > > > > > > Comparing to XML, YAML is significantly more human-readable
> and
> > > > > > > lightweight
> > > > > > > > format and has stable Java library to parse and translate
> > config
> > > > > files
> > > > > > to
> > > > > > > > Java objects without extra-magic.
> > > > > > > >
> > > > > > > > We can find a lot of famous projects which are using YAML:
> > Apache
> > > > > > Flink,
> > > > > > > > Apache Storm/Heron and one of the our main rivals - Apache
> > > > Cassandra.
> > > > > > > >
> > > > > > > > Some of the projects use simple = config form
> > > > (Kafka,
> > > > > > > > Spark), some of the projects use their own YAML-like format
> > > > > (Aerospike,
> > > > > > > > Tarantool), but it's really difficult to find such project
> > which
> > > > has
> > > > > so
> > > > > > > > heavy config as us (maybe VoltDB).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >