Baseline Topology Phase III

[Raymond Wilson]

Hi,

In
https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches
there
is a Phase III effort mentioned that allows graceful reduction of server
nodes with caches having zero backups.

Is this Phase III effort planned to be implemented?

Thanks,
Raymond.

Contribute to ticket IGNITE-11894

[Amit Chavan]

Hello,

I joined the Ignite community last week and I want to start contributing. I
would like to start with this ticket - IGNITE-11894
. Can someone please
assign me the ticket?

Thanks,
Amit

Re: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)

[Denis Magda]

Yuriy,

If you are ready to take over the full-text search indexes then please go
ahead. The primary reason why the community wants to discontinue them first
(and, probable, resurrect later) are the limitations listed by Andrey and
minimal support from the community end.

-
Denis


On Thu, Aug 29, 2019 at 1:29 PM Andrey Mashenkov 
wrote:

> Hi Yuriy,
>
> Unfortunatelly, there is a plan to discontinue TextQueries in Ignite [1].
> Motivation here is text indexes are not persistent, not transactional and
> can't be user together with SQL or inside SQL.
> and there is a lack of interest from community side.
> You are weclome to take on these issues and make TextQueries great.
>
> 1,  PageSize can't be used to limit resultset.
> Query results return from data node to client-side cursor in page-by-page
> manner and
> this parameter is designed control page size. It is supposed query executes
> lazily on server side and
> it is not excepted full resultset be loaded to memory on server side at
> once, but by pages.
> Do you mean you found Lucene load entire resultset into memory before first
> page is sent to client?
>
> I'd think a new parameter should be added to limit result. The best
> solution is to use query language commands for this, e.g. "LIMIT/OFFSET" in
> SQL.
>
> This task doesn't look trivial. Query is distributed operation and same
> user query will be executed on data nodes
> and then results from all nodes should be correcly merged before being
> returned via client-cursor.
> So, LIMIT should be applied on every node and then on merge phase.
>
> Also, this may be non-obviuos, limiting results make no sence without
> sorting,
> as there is no guarantee every next query run will return same data because
> of page reordeing.
> Basically, merge phase receive results from data nodes asynchronously and
> messages from different nodes can't be ordered.
>
> 2.
> a. "tokenize" param name (for @QueryTextFiled) looks more verbose, isn't
> it.
> b,c. What about distributed query? How partial results from nodes will be
> merged?
>  Does Lucene allows to configure comparator for data sorting?
> What comparator Ignite should choose to sort result on merge phase?
>
> 3. For now Lucene engine is not configurable at all. E.g. it is impossible
> to configure Tokenizer.
> I'd think about possible ways to configure engine at first and only then go
> further to discuss\implement complex features,
> that may depends on engine config.
>
>
>
> On Thu, Aug 29, 2019 at 8:17 PM Yuriy Shuliga  wrote:
>
> > Dear community,
> >
> > By starting this chain I'd like to open discussion that would come to
> > contribution results in subj. area.
> >
> > Ignite has indexing capabilities, backed up by different mechanisms,
> > including Lucene.
> >
> > Currently, Lucene 7.5.0 is used (past year release).
> > This is a wide spread and mature technology that covers text search area
> > and beyond (e.g. spacial data indexing).
> >
> > My goal is to *expose more Lucene functionality to Ignite indexing and
> > query mechanisms for text data*.
> >
> > It's quite simple request at current stage. It is coming from our
> project's
> > needs, but i believe, will be useful for a lot more people.
> > Let's walk through and vote or discuss about Jira tickets for them.
> >
> > 1.[trivial] Use  dataQuery.getPageSize()  to limit search response items
> > inside GridLuceneIndex.query(). Currently it is calling
> > IndexSearcher.search(query, *Integer.MAX_VALUE*) - so basically all
> scored
> > matches will me returned, what we do not need in most cases.
> >
> > 2.[simple] Add sorting.  Then more capable search call can be
> > executed: *IndexSearcher.search(query, count,
> > sort) *
> > Implementation steps:
> > a) Introduce boolean *sortField* parameter in *@QueryTextFiled *
> > annotation. If
> > *true *the filed will be indexed but not tokenized. Number types are
> > preferred here.
> > b) Add *sort* collection to *TextQuery* constructor. It should define
> > desired sort fields used for querying.
> > c) Implement Lucene sort usage in GridLuceneIndex.query().
> >
> > 3.[moderate] Build complex queries with *TextQuery*, including
> > terms/queries boosting.
> > *This section for voting only, as requires more detailed work. Should be
> > extended if community is interested in it.*
> >
> > Looking forward to your comments!
> >
> > BR,
> > Yuriy Shuliha
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)

[Andrey Mashenkov]

Hi Yuriy,

Unfortunatelly, there is a plan to discontinue TextQueries in Ignite [1].
Motivation here is text indexes are not persistent, not transactional and
can't be user together with SQL or inside SQL.
and there is a lack of interest from community side.
You are weclome to take on these issues and make TextQueries great.

1,  PageSize can't be used to limit resultset.
Query results return from data node to client-side cursor in page-by-page
manner and
this parameter is designed control page size. It is supposed query executes
lazily on server side and
it is not excepted full resultset be loaded to memory on server side at
once, but by pages.
Do you mean you found Lucene load entire resultset into memory before first
page is sent to client?

I'd think a new parameter should be added to limit result. The best
solution is to use query language commands for this, e.g. "LIMIT/OFFSET" in
SQL.

This task doesn't look trivial. Query is distributed operation and same
user query will be executed on data nodes
and then results from all nodes should be correcly merged before being
returned via client-cursor.
So, LIMIT should be applied on every node and then on merge phase.

Also, this may be non-obviuos, limiting results make no sence without
sorting,
as there is no guarantee every next query run will return same data because
of page reordeing.
Basically, merge phase receive results from data nodes asynchronously and
messages from different nodes can't be ordered.

2.
a. "tokenize" param name (for @QueryTextFiled) looks more verbose, isn't
it.
b,c. What about distributed query? How partial results from nodes will be
merged?
 Does Lucene allows to configure comparator for data sorting?
What comparator Ignite should choose to sort result on merge phase?

3. For now Lucene engine is not configurable at all. E.g. it is impossible
to configure Tokenizer.
I'd think about possible ways to configure engine at first and only then go
further to discuss\implement complex features,
that may depends on engine config.



On Thu, Aug 29, 2019 at 8:17 PM Yuriy Shuliga  wrote:

> Dear community,
>
> By starting this chain I'd like to open discussion that would come to
> contribution results in subj. area.
>
> Ignite has indexing capabilities, backed up by different mechanisms,
> including Lucene.
>
> Currently, Lucene 7.5.0 is used (past year release).
> This is a wide spread and mature technology that covers text search area
> and beyond (e.g. spacial data indexing).
>
> My goal is to *expose more Lucene functionality to Ignite indexing and
> query mechanisms for text data*.
>
> It's quite simple request at current stage. It is coming from our project's
> needs, but i believe, will be useful for a lot more people.
> Let's walk through and vote or discuss about Jira tickets for them.
>
> 1.[trivial] Use  dataQuery.getPageSize()  to limit search response items
> inside GridLuceneIndex.query(). Currently it is calling
> IndexSearcher.search(query, *Integer.MAX_VALUE*) - so basically all scored
> matches will me returned, what we do not need in most cases.
>
> 2.[simple] Add sorting.  Then more capable search call can be
> executed: *IndexSearcher.search(query, count,
> sort) *
> Implementation steps:
> a) Introduce boolean *sortField* parameter in *@QueryTextFiled *
> annotation. If
> *true *the filed will be indexed but not tokenized. Number types are
> preferred here.
> b) Add *sort* collection to *TextQuery* constructor. It should define
> desired sort fields used for querying.
> c) Implement Lucene sort usage in GridLuceneIndex.query().
>
> 3.[moderate] Build complex queries with *TextQuery*, including
> terms/queries boosting.
> *This section for voting only, as requires more detailed work. Should be
> extended if community is interested in it.*
>
> Looking forward to your comments!
>
> BR,
> Yuriy Shuliha
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Nabble message wrapping

[Denis Magda]

Denis,

I granted your account the admin access. Please do all the required changes
and let me know once done.

-
Denis


On Thu, Aug 29, 2019 at 2:00 AM Denis Mekhanikov 
wrote:

> Guys,
>
> Any update? Who has a Nabble admin account for the developers list?
>
> Denis
> On 27 Aug 2019, 14:55 +0300, Dmitriy Pavlov , wrote:
> > Hi Denis,
> >
> > AFAIK, nabble forums are service, which resides outside of ASF infra.
> They
> > have their separate support/feedback form.
> >
> > Maybe some PMC members could have some credentials for this service. If
> so,
> > please share login info in SVN/private/credentials.
> >
> > Sincerely,
> > Dmitriy Pavlov
>

Re: New Сommitter: Maxim Muzafarov

[Maxim Muzafarov]

Folks,

Thank you all

On Thu, 29 Aug 2019 at 11:56, Vyacheslav Daradur  wrote:
>
> Good job Maxim, congratulations!
>
> On Thu, Aug 29, 2019 at 9:59 AM Anton Vinogradov  wrote:
> >
> > Welcome aboard :)
> >
> > On Thu, Aug 29, 2019 at 3:35 AM Roman Shtykh 
> > wrote:
> >
> > > Maxim, congratulations!
> > >
> > > -- Roman
> > >
> > >
> > > On Thursday, August 29, 2019, 12:11:29 a.m. GMT+9, Dmitriy Pavlov <
> > > dpav...@apache.org> wrote:
> > >
> > >  Dear community,
> > >
> > > The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> > > Muzafarov to become a committer and we are pleased to announce that he has
> > > accepted.
> > >
> > > PMC recognizes Maxim's efforts in developing file transfer for 
> > > rebalancing,
> > > removal of WAL applying steps from Partition Map Exchange, finding and
> > > fixing non-trivial issues with the product, like mem leaks, and in setting
> > > up code inspections and maintaining this process.
> > >
> > > Being a committer enables easier contribution to the project since there 
> > > is
> > > no need to go via the patch submission process. This should enable better
> > > productivity.
> > >
> > > Best regards,
> > > Dmitriy Pavlov
> > > on behalf of PMC, Apache Ignite
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.

Text queries/indexes (GridLuceneIndex, @QueryTextFiled)

[Yuriy Shuliga]

Dear community,

By starting this chain I'd like to open discussion that would come to
contribution results in subj. area.

Ignite has indexing capabilities, backed up by different mechanisms,
including Lucene.

Currently, Lucene 7.5.0 is used (past year release).
This is a wide spread and mature technology that covers text search area
and beyond (e.g. spacial data indexing).

My goal is to *expose more Lucene functionality to Ignite indexing and
query mechanisms for text data*.

It's quite simple request at current stage. It is coming from our project's
needs, but i believe, will be useful for a lot more people.
Let's walk through and vote or discuss about Jira tickets for them.

1.[trivial] Use  dataQuery.getPageSize()  to limit search response items
inside GridLuceneIndex.query(). Currently it is calling
IndexSearcher.search(query, *Integer.MAX_VALUE*) - so basically all scored
matches will me returned, what we do not need in most cases.

2.[simple] Add sorting.  Then more capable search call can be
executed: *IndexSearcher.search(query, count,
sort) *
Implementation steps:
a) Introduce boolean *sortField* parameter in *@QueryTextFiled * annotation. If
*true *the filed will be indexed but not tokenized. Number types are
preferred here.
b) Add *sort* collection to *TextQuery* constructor. It should define
desired sort fields used for querying.
c) Implement Lucene sort usage in GridLuceneIndex.query().

3.[moderate] Build complex queries with *TextQuery*, including
terms/queries boosting.
*This section for voting only, as requires more detailed work. Should be
extended if community is interested in it.*

Looking forward to your comments!

BR,
Yuriy Shuliha

[jira] [Created] (IGNITE-12125) Concurrency problem in PagesWriteThrottle

[Sergey Antonov (Jira)]

Sergey Antonov created IGNITE-12125:
---

 Summary: Concurrency problem in PagesWriteThrottle
 Key: IGNITE-12125
 URL: https://issues.apache.org/jira/browse/IGNITE-12125
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
 Fix For: 2.8


In IGNITE-12006 and IGNITE-9231 were added code:
{code}
parkThrds.forEach(LockSupport::unpark);
parkThrds.clear();
{code}
This code isn't thread-safe. We should remove from {{parkThrds}} only unparked 
threads.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (IGNITE-12124) Stopping the cache does not wait for expiration process, which may be started and may lead to errors

[Vyacheslav Koptilin (Jira)]

Vyacheslav Koptilin created IGNITE-12124:


 Summary: Stopping the cache does not wait for expiration process, 
which may be started and may lead to errors
 Key: IGNITE-12124
 URL: https://issues.apache.org/jira/browse/IGNITE-12124
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
 Fix For: 2.8






--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Hello

[Alexei Scherbakov]

Hi Yuri.

Glad to hear it!
I'm personally think text queries are very important feature and should get
more attention from community.

Awaiting your contributions.

ср, 28 авг. 2019 г. в 17:31, Dmitriy Pavlov :

> Hi Yuriy,
>
> I've added your account to contributors list, now you can assign an issue
> to yourself.
>
> Please see the short guide on how to start contributing here
>
> https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite
> and
> full guide here
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> Should you have any questions don't hesitate to contact the community here.
>
> Unfortunately for text queries, there are no maintainers and I'm not sure
> about our vision about the future of this module in Apache Ignite. It may
> worth to start a separate discussion about changes proposed. I also suggest
> using an email with the subject containing GridLuceneIndex &
> QueryTextFiled, so experts may notice this email and chime in.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 28 авг. 2019 г. в 16:54, Yuriy Shuliga :
>
> > UPD:
> > Jira ID:  Yuriy_Shuliha
> > To whom it may concern, please add me as contributor
> > 
> > Yuriy
> >
> > -- Forwarded message -
> > Від: Yuriy Shuliga 
> > Date: ср, 28 серп. 2019 о 16:03
> > Subject: Hello
> > To: 
> >
> >
> > Dear Ignite Team!
> >
> > My name is Yuriy Shuliha,
> > My current work is dedicated to Search services for various businesses.
> > Now we are working with Ignite as main computation facility, and are
> > interested in development of its TextQuery capabilities backed up by
> > Lucene inside.
> >
> > My contribution goal is to extend GridLuceneIndex functionality by :
> > 1)  Ability to set limits to returned TopDocs.
> > 2) Adding Sort fields to index/query (potentially via new annotation)
> > 3) Adding Boost to certain indexed fields (by @QueryTextFiled annotation
> > extending)
> >
> > Looking forward to productive  collaboration!
> >
> > Yuriy Shluiha
> >
>


-- 

Best regards,
Alexei Scherbakov

[jira] [Created] (IGNITE-12123) Cache throws npe at {null, null, null} array key.

[Stepachev Maksim (Jira)]

Stepachev Maksim created IGNITE-12123:
-

 Summary: Cache throws npe at {null, null, null} array key.
 Key: IGNITE-12123
 URL: https://issues.apache.org/jira/browse/IGNITE-12123
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Stepachev Maksim
Assignee: Stepachev Maksim
 Fix For: 2.8






--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Making Ignite Collaboration 100% Open and Transparent

[Andrey Gura]

Why chat is called chat? [1] Just ignore modern definitions :) Chat is
"bla-bla-bla".

IMO, there are no any pros for using Slack in order to make Ignite
Collaboration 100% Open and Transparent. Chat is just garbage of some
phrases that aren't structured into discussions (please, don't talk me
about threads in Slack, they are useless).  So  transparency isn't
chat's property. If some topics have parallel discussion we will have
as result something like salad "Asynchronous":
tomacucumtoes,bersmayonn,aise. Moreover, the same salad we will have
for discussion of one topic by many members.

Mailing list is the best mean for easygoing interaction. It
asynchronous by nature and doesn't have any means for pressure to
community members (like notifications). Discussions on mailing list
are organized into threads and any new message to the thread will
follow up thread to the top of unread messages. All you need and
nothing more.

Mailing list are indexed by search engines while Slack channels
aren't. It is stone in the garden of openтess.

I always can refer to discussion on mailing list. But it's impossible
for discussion in Slack channel due to reasons mentioned above.

I do not mind the idea as a whole. Chat could be nice and fun. But
openness, transparency, and also important searchability, it is all
about mailing lists, not chats.

[1] https://www.merriam-webster.com/dictionary/chat

On Thu, Aug 29, 2019 at 12:40 AM Павлухин Иван  wrote:
>
> + Meeting minutes
>
> 2019-08-28 22:29 GMT+11:00, Alexey Zinoviev :
> > I am totally support the idea with the planned and widely announced Hangout
> > meeting between commiters and contributers and posting the link to the
> > dev-list with the special Topic Name and short agenda. Maybe, the recorded
> > video could be added to the YouTube (or to another platform) to share with
> > the community members.
> >
> > пн, 26 авг. 2019 г. в 22:23, Amit Chavan :
> >
> >> Hi Denis,
> >>
> >> I really like the initiative for transparency and collaboration. Are
> >> there
> >> any plans to help get new contributors up to speed with the project where
> >> they can contribute effectively? Sometimes it can be intimidating to
> >> start
> >> on a large project without some help or advice. Maybe assigning a mentor
> >> or
> >> an existing committer can be useful or some slack channel people can ping
> >> on. I am starting new on the project and have picked out newbie ticket
> >> from
> >> the Jira board. As I make myself familiar with the code base maybe its
> >> good
> >> to have some direction on which area should I focus more on etc.
> >>
> >> Thanks,
> >> Amit
> >>
> >> On Mon, Aug 26, 2019 at 11:54 AM Denis Magda  wrote:
> >>
> >> > Folks, let me share more details on why Anton started the conversation
> >> > about Ignite Slack:
> >> >
> >> >
> >> http://apache-ignite-developers.2346864.n4.nabble.com/The-ASF-Slack-td43233.html
> >> >
> >> > Recently, a group of GridGain and Sberbank committers of Ignite has met
> >> to
> >> > discuss how to make our community more transparent and open. Anton and
> >> > I
> >> > took part in that meeting. The primary problems we see in regards to
> >> > transparency and openness are as follows:
> >> >
> >> >- A lot of discussions on the dev list abrupts suddenly and it's
> >> unclear
> >> >whether a discussion is abandoned or something else is going on in
> >> > the
> >> >background with a task/bug/improvement. In many cases, we tend to
> >> > fall
> >> > back
> >> >to faster communication ways like instant messaging, calls, or
> >> > face-to-face
> >> >meetings that are not visible to the rest of the community. Emails
> >> (dev
> >> >list) are the right communication channel but not for all of the
> >> stages.
> >> >- Change reviews seem to be in a chaotic state. Sometimes it takes
> >> many
> >> >rounds for a committer to urge another committer to do a review. In
> >> many
> >> >cases, the other committer might be simply overwhelmed with regular
> >> > tasks
> >> >imposed by an employer. It will be good to come up with some public
> >> >tracking approach that will help us all to see who and when will be
> >> > able to
> >> >review certain changes and make them to Ignite.
> >> >
> >> > To address the problems we want to propose the following:
> >> >
> >> >- Keep using dev list the way you do today. No changes need to be
> >> > done
> >> >here.
> >> >- Introduce Ignite Slack for instant messaging across all the
> >> community
> >> >members who are obviously employed by different companies. Ignite
> >> > PMC
> >> > will
> >> >be managing channels for various topics. Go to Slack when email (dev
> >> > list)
> >> >conversation is no longer effective, the way we do daily, no need to
> >> >complicate our lives just because we work on an open-source project
> >> >together.
> >> >- Two or more committers need to talk verbally? Go ahead and
> >> > schedule
> >> a
> >> >

Re: Remove setIncludeEventTypes from GridAbstractTest.

[Alexei Scherbakov]

Zhenya Stanilovsky,

Enabling all events has benefit of additional test coverage and disabling
some of them may break tests in unpredictable manner.
I would first check TC run time gain before applying the change.
Please create a PR and compare run durations with and without change.
Showing here results would be good.


чт, 29 авг. 2019 г. в 13:11, Zhenya Stanilovsky :

> Igniters, after dummy perf vs flamegraph tests i found all events are
> enabled on  GridAbstractTest:
> cfg.setIncludeEventTypes(EventType.EVTS_ALL); ticket [1] with flamegraph
> attached show 7-8% spending in GridCacheEventManager::addEvent, i suppose
> this extra functional for all inheritors.
>
> If no objections i plan to set this events only for really requiring tests.
>
> thanks!
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12122
>
> --
> Zhenya Stanilovsky



-- 

Best regards,
Alexei Scherbakov

Remove setIncludeEventTypes from GridAbstractTest.

[Zhenya Stanilovsky]

Igniters, after dummy perf vs flamegraph tests i found all events are enabled 
on  GridAbstractTest:
cfg.setIncludeEventTypes(EventType.EVTS_ALL); ticket [1] with flamegraph 
attached show 7-8% spending in GridCacheEventManager::addEvent, i suppose this 
extra functional for all inheritors.

If no objections i plan to set this events only for really requiring tests.

thanks!

[1] https://issues.apache.org/jira/browse/IGNITE-12122

-- 
Zhenya Stanilovsky

[jira] [Created] (IGNITE-12122) Remove setIncludeEventTypes from GridAbstractTest.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-12122:
---

 Summary: Remove setIncludeEventTypes from GridAbstractTest.
 Key: IGNITE-12122
 URL: https://issues.apache.org/jira/browse/IGNITE-12122
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.7.5
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
 Attachments: flamegraph-18988.svg

Simple cache.put() hot threads measurements shows that  
GridCacheEventManager::addEvent consumes about 7% of  overall time, i suggest 
to remove this events from GridAbstractTest::getConfiguration and stores only 
for really requiring tests.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (IGNITE-12121) Double checkpoint triggering due to incorrect place of update current checkpoint

[Anton Kalashnikov (Jira)]

Anton Kalashnikov created IGNITE-12121:
--

 Summary: Double checkpoint triggering due to incorrect place of 
update current checkpoint
 Key: IGNITE-12121
 URL: https://issues.apache.org/jira/browse/IGNITE-12121
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Double checkpoint triggering due to incorrect place of update current 
checkpoint. This can lead to two ckeckpoints one by one if checkpoint trigger 
was 'too many dirty pages'.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (IGNITE-12120) Change log level in GridCacheWritebehindStore

[Sunny Chan (Jira)]

Sunny Chan created IGNITE-12120:
---

 Summary: Change log level in GridCacheWritebehindStore
 Key: IGNITE-12120
 URL: https://issues.apache.org/jira/browse/IGNITE-12120
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.7.5
Reporter: Sunny Chan


In the 
[GridCacheWriteBehindStore|https://github.com/apache/ignite/blob/7e73098d4d6e3d5f78326cb11dac7e083a2312dd/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L893],
 when the updateStore failed to write to underlying store, it logs this as 
error:

{{LT.error(log, e, "Unable to update underlying store: " + store);}}

After this line logged the error, it would return false so that it would retry 
the store (by returning false).  

While later on in the updatStore function, when the writeCache overflows, it 
would log this:

{{log.warning("Failed to update store (value will be lost as current buffer 
size is greater " + …}}

then it will remove the failed entry.

I think the severity of the log messages is not right, as the fail update would 
still be retried.

So I propose to change the log severity level so that the first one would be a 
warn, and second one would be error



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Nabble message wrapping

[Denis Mekhanikov]

Guys,

Any update? Who has a Nabble admin account for the developers list?

Denis
On 27 Aug 2019, 14:55 +0300, Dmitriy Pavlov , wrote:
> Hi Denis,
>
> AFAIK, nabble forums are service, which resides outside of ASF infra. They
> have their separate support/feedback form.
>
> Maybe some PMC members could have some credentials for this service. If so,
> please share login info in SVN/private/credentials.
>
> Sincerely,
> Dmitriy Pavlov

Re: New Сommitter: Maxim Muzafarov

[Vyacheslav Daradur]

Good job Maxim, congratulations!

On Thu, Aug 29, 2019 at 9:59 AM Anton Vinogradov  wrote:
>
> Welcome aboard :)
>
> On Thu, Aug 29, 2019 at 3:35 AM Roman Shtykh 
> wrote:
>
> > Maxim, congratulations!
> >
> > -- Roman
> >
> >
> > On Thursday, August 29, 2019, 12:11:29 a.m. GMT+9, Dmitriy Pavlov <
> > dpav...@apache.org> wrote:
> >
> >  Dear community,
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> > Muzafarov to become a committer and we are pleased to announce that he has
> > accepted.
> >
> > PMC recognizes Maxim's efforts in developing file transfer for rebalancing,
> > removal of WAL applying steps from Partition Map Exchange, finding and
> > fixing non-trivial issues with the product, like mem leaks, and in setting
> > up code inspections and maintaining this process.
> >
> > Being a committer enables easier contribution to the project since there is
> > no need to go via the patch submission process. This should enable better
> > productivity.
> >
> > Best regards,
> > Dmitriy Pavlov
> > on behalf of PMC, Apache Ignite
> >



-- 
Best Regards, Vyacheslav D.

Re: New Сommitter: Maxim Muzafarov

[Anton Vinogradov]

Welcome aboard :)

On Thu, Aug 29, 2019 at 3:35 AM Roman Shtykh 
wrote:

> Maxim, congratulations!
>
> -- Roman
>
>
> On Thursday, August 29, 2019, 12:11:29 a.m. GMT+9, Dmitriy Pavlov <
> dpav...@apache.org> wrote:
>
>  Dear community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> Muzafarov to become a committer and we are pleased to announce that he has
> accepted.
>
> PMC recognizes Maxim's efforts in developing file transfer for rebalancing,
> removal of WAL applying steps from Partition Map Exchange, finding and
> fixing non-trivial issues with the product, like mem leaks, and in setting
> up code inspections and maintaining this process.
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
> Best regards,
> Dmitriy Pavlov
> on behalf of PMC, Apache Ignite
>