[jira] [Created] (IGNITE-14327) Flaky IgniteCacheNearRestartRollbackSelfTest.

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-14327:
---

 Summary: Flaky IgniteCacheNearRestartRollbackSelfTest.
 Key: IGNITE-14327
 URL: https://issues.apache.org/jira/browse/IGNITE-14327
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.10
Reporter: Stanilovsky Evgeny
 Attachments: image-2021-03-17-08-39-28-729.png, 
image-2021-03-17-08-40-29-865.png

IgniteCacheNearRestartRollbackSelfTest seems flaky,
!image-2021-03-17-08-39-28-729.png! 
 !image-2021-03-17-08-40-29-865.png! 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSSION] IEP-69 The evolutionary release process

[Valentin Kulichenko]

Hi Maxim,

Thanks for summarizing. +1 for the versioning scheme.

-Val

On Tue, Mar 16, 2021 at 11:05 AM Maxim Muzafarov  wrote:

> Folks,
>
>
> Thanks to everyone for participating in the call. Here is the list of
> points we've agreed on and the list of actions which should be
> discussed in more details.
>
>
> = AGREED =
>
> == Versioning ==
>
> grand.major.bugfix[-rc_number]
>
> The 'grand' version is fixed while both Ignite architectures (current
> version 2.x and 3.x) are in a state of active development/maintained
> or until otherwise is discussed further. This means:
> - the master branch of the ignite repository [2] always release under
> the '2.x.x' version
> - the main branch of the ignite-3 repository [1] always release under
> the '3.x.x' version
>
> The 'major' versions for each architecture may contain breaking
> backwards compatibility changes compared to the previous one if the
> following criteria are met:
> - users should be warned about breaking release changes (the ways of
> notification should be additionally discussed and agreed upon)
> - the deprecation rules may be applied for the current 'major' release
> (the ways of deprecation must be additionally discussed and agreed
> upon)
> - current @deprecated already have enough time live and some of them
> can be removed using common sense
>
> The 'bugfix' version is used for emergency releases and can't contain
> any breaking backwards compatibility changes.
>
> == Commitments ==
>
> Any commitment to support previous releases (e.g. 1 year, 1 quarter)
> have no sense to the open-source Ignite community in the case of
> observed backward compatibility violations, however, in any of such
> cases, an emergency release can be performed according to the accepted
> release procedure.
>
>
> = DISCUSSION & SUGGESTIONS =
>
>
> == Deprecation rules ==
>
> The API deprecation rules must be discussed and agreed upon in more
> details. The list of options we have:
> - deprecate and remove API allowed in the next release
> - deprecate and remove API allowed through the one release
> - deprecation may contain comments - the release version then the API
> will be changed
> - deprecation may contain comments - the date from which the API changes
> allowed
>
> I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
> adds the `forRemoval` and `since` optional elements to the deprecated
> annotation and I think we can use a similar approach here with some
> additions. For instance, if the last released version is 2.10 my
> suggestions would be the following:
> - [case: change API as quickly as possible] mark some API as
> deprecated, set 'since' version 2.12, change it in the 2.12 release
> major version.
> - [case: deprecate API without intention to change] mark API as
> deprecated without 'since' options, change it without notifications
> since 2.13 releases and so on.
>
>
> == User notification rules ==
>
> Uses must be well-notified about the planned backward compatibility
> violations. The options we have:
> - the notification thought the source code with well-described JavaDocs
> - add labels to the JIRA issue if some deprecations occur in the related
> patch
> - add deprecation and backward compatibility paragraph to the RELEASE_NOTES
> - add a page to the Apache Ignite website with a backwards
> compatibility description between the closest versions
>
> All of the above must be done.
>
>
> == Experimental and unstable APIs ==
>
> The options we have:
> - only the new API can be marked as unstable and/or experimental
> - such APIs can be changed without any notifications
>
>
> Please, share your thoughts.
>
>
> [1] https://github.com/apache/ignite-3
> [2] https://github.com/apache/ignite
> [3] https://openjdk.java.net/jeps/277
>
> On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov  wrote:
> >
> > Folks,
> >
> > let me add my 50 cents. I don't see major issues with this IEP, for now.
> > And I really looking forward to talking about it. I can't get what causes
> > misunderstanding.
> >
> > The only thing that concerns me here is that IEP requires the community
> to
> > support solutions for 1 year, 1 quarter, etc.
> >
> > Apache community is not a commercial company that provides support of any
> > kind, and I would be reluctant to add these or similar statements to any
> > public documents. At any point in time, the community and PMC can vote
> and
> > introduce any major feature breaking compatibility. We tend to avoid such
> > actions to keep users best interest. But it is not a commitment.
> >
> > Sincerely
> >
> >
> > чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov :
> >
> > > Val,
> > >
> > >
> > > I'm sorry if anything from what I've said sounded disrespectful. All
> > > of you are examples for me to follow :-)
> > >
> > > Have you checked the `motivation` [1] topic on the IEP-69 page? Should
> > > I add more details to it prior to the call? I want to make Ignite
> > > better and also think that the current 2.x version with all the
> > > 

Re: IEP-70: Async Continuation Executor

[Alexey Kukushkin]

Pavel,

So what you are saying is submitting a continuation to .NET Thread Pool
already respects current  SynchronizationContext and ConfigureAwait. In
this case the IEP looks complete (for some reason I thought that we should
take care about the SynchronizationContext inside the Ignite.NET
implementation).

-- 
Best regards,
Alexey

Re: IEP-70: Async Continuation Executor

[Pavel Tupitsyn]

Raymond,

> If it is present in memory, then a Sync operation will
> be more performant. Is it possible to do a two step operation like this
> 'Cache.GetIfInMemory() ?? await Cache.GetAsync()'

Ignite already does that - if the key is present locally (primary, backup,
near cache, platform cache),
the operation will be performed synchronously and you'll get a completed
Task back;
there won't be any thread jumps.

We'll make sure this does not change with the IEP - I'll add tests.

Having said that, you can do a two-step op:
cache.TryLocalPeek(1, out var v) ? v : await cache.GetAsync(1)

This performs better for local entries, because we avoid
async method overhead, and worse for non-local entries, because we do two
calls.

On Tue, Mar 16, 2021 at 10:58 PM Pavel Tupitsyn 
wrote:

> Alexey,
>
> I'm not sure your understanding is entirely correct.
> The proposal won't break or change anything for UI apps and other apps
> with SynchronizationContext.
> The code in Button1_Click works now and will work after the proposal:
> continuations are routed to SynchronizationContext automatically when it
> is present,
> we don't have to worry about that in our code [1].
>
> > Sometimes you know that your continuation is really fast and safe and you
> > want to avoid switching threads to improve performance
>
> This is a valid point, that's why the new behavior is configurable - safe
> by default,
> but can be overridden when you know what you are doing.
>
> > In this case you use ConfigureAwait(false)
>
> Not correct: ConfigureAwait() does nothing when there is no
> SyncronizationContext:
> in ASP.NET Core apps, in Console apps, basically everywhere except WPF,
> WinForms, and Legacy ASP.NET.
>
>
> [1] https://devblogs.microsoft.com/dotnet/configureawait-faq/
>
> On Tue, Mar 16, 2021 at 10:54 PM Alexey Kukushkin <
> kukushkinale...@gmail.com> wrote:
>
>> Raymond,
>>
>> The article you referenced
>>  is great! It
>> seems to me the article rather proved what I suggested: an async operation
>> implementation:
>>
>>- Uses the async operation thread (Ignite's thread) if ConfigureAwait
>> is
>>false (by default it is true)
>>- Uses caller's current SynchornizationContext if it is specified
>>- Uses caller's TaskScheduler.Current if current
>>SynchornizationContext is null
>>
>> In the application code (outside framework callbacks) the
>> SynchornizationContext.Current will be null and TaskScheduler.Current is
>> the .NET's fork-join thread pool. Thus, normally the .NET thread pool
>> would
>> be used for continuations as Pavel suggested in the IEP.
>>
>> Executing Async operation in a context where
>> SynchornizationContext.Current is not null means some framework explicitly
>> configured the context and that means it is important to execute the
>> continuation in that context (like UI or xUnit main thread)
>>
>> I agree that routing back to original context might result in waiting,
>> which is very dangerous for an Ignite thread. We can create a worker
>> thread
>> to route continuation to original context.
>>
>>
>> вт, 16 мар. 2021 г. в 21:40, Raymond Wilson :
>>
>> > There is a (long) discussion here (
>> > https://devblogs.microsoft.com/dotnet/configureawait-faq/) regarding
>> use
>> > of
>> > ConfigureAwait().
>> >
>> > Putting edge cases aside, there is a general use case for
>> > .ConfigureAwait(true) in application UI contexts to ensure the
>> continuation
>> > joins a UI thread (for example), where failing to do so results in an
>> > error.
>> >
>> > The other general use case relates more to library code where you are
>> > typically running your tasks on the managed thread pool (assuming no
>> custom
>> > task schedulers etc). In this case the .library is agnostic about which
>> > thread pool thread picks up the continuation, so forcing the
>> continuation
>> > to join to the original thread may be both a performance penalty from
>> the
>> > join overhead, but also may add latency waiting for that thread to
>> become
>> > available again.
>> >
>> > I don't have good insight into how the striped thread pool is used in
>> > Ignite, but in highly concurrent environments letting those threads
>> escape
>> > into the calling client context seems like a bad idea in general.
>> >
>> > Stepping back a little, the Cache Async operations are good for when
>> there
>> > will be an IO operation incurred because the requested element is not
>> > present in memory. If it is present in memory, then a Sync operation
>> will
>> > be more performant. Is it possible to do a two step operation like this
>> > 'Cache.GetIfInMemory() ?? await Cache.GetAsync()' to allow the calling
>> > context to optimise the calling model dynamically?
>> >
>> > Thanks,
>> > Raymond.
>> >
>> >
>> > On Wed, Mar 17, 2021 at 6:14 AM Alexey Kukushkin <
>> > kukushkinale...@gmail.com>
>> > wrote:
>> >
>> > > Pavel,
>> > >
>> > > My understanding might be wrong but I think the best 

Re: IEP-70: Async Continuation Executor

[Pavel Tupitsyn]

Alexey,

I'm not sure your understanding is entirely correct.
The proposal won't break or change anything for UI apps and other apps with
SynchronizationContext.
The code in Button1_Click works now and will work after the proposal:
continuations are routed to SynchronizationContext automatically when it is
present,
we don't have to worry about that in our code [1].

> Sometimes you know that your continuation is really fast and safe and you
> want to avoid switching threads to improve performance

This is a valid point, that's why the new behavior is configurable - safe
by default,
but can be overridden when you know what you are doing.

> In this case you use ConfigureAwait(false)

Not correct: ConfigureAwait() does nothing when there is no
SyncronizationContext:
in ASP.NET Core apps, in Console apps, basically everywhere except WPF,
WinForms, and Legacy ASP.NET.


[1] https://devblogs.microsoft.com/dotnet/configureawait-faq/

On Tue, Mar 16, 2021 at 10:54 PM Alexey Kukushkin 
wrote:

> Raymond,
>
> The article you referenced
>  is great! It
> seems to me the article rather proved what I suggested: an async operation
> implementation:
>
>- Uses the async operation thread (Ignite's thread) if ConfigureAwait is
>false (by default it is true)
>- Uses caller's current SynchornizationContext if it is specified
>- Uses caller's TaskScheduler.Current if current
>SynchornizationContext is null
>
> In the application code (outside framework callbacks) the
> SynchornizationContext.Current will be null and TaskScheduler.Current is
> the .NET's fork-join thread pool. Thus, normally the .NET thread pool would
> be used for continuations as Pavel suggested in the IEP.
>
> Executing Async operation in a context where
> SynchornizationContext.Current is not null means some framework explicitly
> configured the context and that means it is important to execute the
> continuation in that context (like UI or xUnit main thread)
>
> I agree that routing back to original context might result in waiting,
> which is very dangerous for an Ignite thread. We can create a worker thread
> to route continuation to original context.
>
>
> вт, 16 мар. 2021 г. в 21:40, Raymond Wilson :
>
> > There is a (long) discussion here (
> > https://devblogs.microsoft.com/dotnet/configureawait-faq/) regarding use
> > of
> > ConfigureAwait().
> >
> > Putting edge cases aside, there is a general use case for
> > .ConfigureAwait(true) in application UI contexts to ensure the
> continuation
> > joins a UI thread (for example), where failing to do so results in an
> > error.
> >
> > The other general use case relates more to library code where you are
> > typically running your tasks on the managed thread pool (assuming no
> custom
> > task schedulers etc). In this case the .library is agnostic about which
> > thread pool thread picks up the continuation, so forcing the continuation
> > to join to the original thread may be both a performance penalty from the
> > join overhead, but also may add latency waiting for that thread to become
> > available again.
> >
> > I don't have good insight into how the striped thread pool is used in
> > Ignite, but in highly concurrent environments letting those threads
> escape
> > into the calling client context seems like a bad idea in general.
> >
> > Stepping back a little, the Cache Async operations are good for when
> there
> > will be an IO operation incurred because the requested element is not
> > present in memory. If it is present in memory, then a Sync operation will
> > be more performant. Is it possible to do a two step operation like this
> > 'Cache.GetIfInMemory() ?? await Cache.GetAsync()' to allow the calling
> > context to optimise the calling model dynamically?
> >
> > Thanks,
> > Raymond.
> >
> >
> > On Wed, Mar 17, 2021 at 6:14 AM Alexey Kukushkin <
> > kukushkinale...@gmail.com>
> > wrote:
> >
> > > Pavel,
> > >
> > > My understanding might be wrong but I think the best practice (or even
> > > strongly recommended way) to implement async methods in .NET is to
> > execute
> > > continuation on the caller's thread if ConfigureAwait(false) was not
> > > specified. Pseudo-code might look like:
> > >
> > > async Task PutAsync(K k, V v)
> > > {
> > > var continuationExecutor = configureAwait
> > > ? (SynchronizationContext.Current ?? TaskScheduler.Current)
> > > : null;
> > >
> > > await <>
> > >
> > > continuationExecutor.Post(continuation);
> > > }
> > >
> > > I got this understanding from reading some blog
> > > about SynchronizationContext lots of time ago. They were saying they
> > > created SynchronizationContext specifically to allow posting
> > continuations
> > > to the caller's thread.
> > >
> > > The reason for that is to simplify the user's code to avoid routing in
> > the
> > > code. Suppose you have a UI (like WPF or WinForms) event handler that
> > must
> > > be processed on the U 

Re: IEP-70: Async Continuation Executor

[Alexey Kukushkin]

Raymond,

The article you referenced
 is great! It
seems to me the article rather proved what I suggested: an async operation
implementation:

   - Uses the async operation thread (Ignite's thread) if ConfigureAwait is
   false (by default it is true)
   - Uses caller's current SynchornizationContext if it is specified
   - Uses caller's TaskScheduler.Current if current
   SynchornizationContext is null

In the application code (outside framework callbacks) the
SynchornizationContext.Current will be null and TaskScheduler.Current is
the .NET's fork-join thread pool. Thus, normally the .NET thread pool would
be used for continuations as Pavel suggested in the IEP.

Executing Async operation in a context where
SynchornizationContext.Current is not null means some framework explicitly
configured the context and that means it is important to execute the
continuation in that context (like UI or xUnit main thread)

I agree that routing back to original context might result in waiting,
which is very dangerous for an Ignite thread. We can create a worker thread
to route continuation to original context.


вт, 16 мар. 2021 г. в 21:40, Raymond Wilson :

> There is a (long) discussion here (
> https://devblogs.microsoft.com/dotnet/configureawait-faq/) regarding use
> of
> ConfigureAwait().
>
> Putting edge cases aside, there is a general use case for
> .ConfigureAwait(true) in application UI contexts to ensure the continuation
> joins a UI thread (for example), where failing to do so results in an
> error.
>
> The other general use case relates more to library code where you are
> typically running your tasks on the managed thread pool (assuming no custom
> task schedulers etc). In this case the .library is agnostic about which
> thread pool thread picks up the continuation, so forcing the continuation
> to join to the original thread may be both a performance penalty from the
> join overhead, but also may add latency waiting for that thread to become
> available again.
>
> I don't have good insight into how the striped thread pool is used in
> Ignite, but in highly concurrent environments letting those threads escape
> into the calling client context seems like a bad idea in general.
>
> Stepping back a little, the Cache Async operations are good for when there
> will be an IO operation incurred because the requested element is not
> present in memory. If it is present in memory, then a Sync operation will
> be more performant. Is it possible to do a two step operation like this
> 'Cache.GetIfInMemory() ?? await Cache.GetAsync()' to allow the calling
> context to optimise the calling model dynamically?
>
> Thanks,
> Raymond.
>
>
> On Wed, Mar 17, 2021 at 6:14 AM Alexey Kukushkin <
> kukushkinale...@gmail.com>
> wrote:
>
> > Pavel,
> >
> > My understanding might be wrong but I think the best practice (or even
> > strongly recommended way) to implement async methods in .NET is to
> execute
> > continuation on the caller's thread if ConfigureAwait(false) was not
> > specified. Pseudo-code might look like:
> >
> > async Task PutAsync(K k, V v)
> > {
> > var continuationExecutor = configureAwait
> > ? (SynchronizationContext.Current ?? TaskScheduler.Current)
> > : null;
> >
> > await <>
> >
> > continuationExecutor.Post(continuation);
> > }
> >
> > I got this understanding from reading some blog
> > about SynchronizationContext lots of time ago. They were saying they
> > created SynchronizationContext specifically to allow posting
> continuations
> > to the caller's thread.
> >
> > The reason for that is to simplify the user's code to avoid routing in
> the
> > code. Suppose you have a UI (like WPF or WinForms) event handler that
> must
> > be processed on the U thread:
> >
> > async Task Button1_Click(EventArgs args)
> > {
> > ignite.PutAsync(args.Key, args.Value);
> > Button1.Disabled = true;
> > }
> >
> > Executing the "Button1.Disabled = true" on a ForkJoinPool pool would
> cause
> > a "Trying to modify UI on a non-UI thread" exception. But if you
> > capture SynchronizationContext.Current in PutAsync and then route
> > continuation to the captured context then the code would work.
> >
> > I think the users really expect the continuations to be executed on the
> > caller's thread.
> >
> > Sometimes you know that your continuation is really fast and safe and you
> > want to avoid switching threads to improve performance. In this case you
> > use ConfigureAwait(false) like
> >
> > ignite.PutAsync(args.Key, args.Value).ConfigureAwat(false);
> >
> > In this case the continuation executes on the Ignite thread without
> routing
> > to the caller's thread.
> >
> > вт, 16 мар. 2021 г. в 18:49, Pavel Tupitsyn :
> >
> > > Alexey,
> > >
> > > .NET thick API delegates to Java directly.
> > >
> > > When you do ICache.PutAsync():
> > > * Future is created on Java side, .listen() is called
> > > * TaskCompletionSource is created on .NET 

Re: [DISCUSSION] Documentation feedback button

[Denis Magda]

Nikita, thanks for starting the conversation. I'll just cast my vote for
the bugyard.io for its ability to select and comment on a specific
problematic point on a documentation page (a paragraph, sentence, picture,
code snippet, etc.). It makes it trivial to share feedback and then it's
easy to process it on the other side. Those who'd like to experience it,
click the "Documentation Feedback" button on the GridGain docs:
https://www.gridgain.com/docs/latest/getting-started/what-is-gridgain

-
Denis


On Tue, Mar 16, 2021 at 3:14 PM Никита Сафонов 
wrote:

> Hello Igniters,
>
> I would like to propose an enhancement that can significantly improve the
> quality of our documentation.
>
> I suggest adding a feedback button (let’s call it a «Documentation
> feedback» button) to the web site documentation pages so everyone could
> leave a comment to what is already published.
>
> The feedback may refer to the Ignite documentation in general or to a
> particular section, paragraph, or even term or value.
>
> I do believe that we would harvest dozens and hundreds of ideas,
> suggestions, and observations.
>
> I would also suggest using bugyard.io as a solid service for gathering
> feedback (I’m quite familiar with it, it is easy to implement, use, and
> maintain).
>
> So folks, what do you think of this?
>
> With best regards,
> Nikita
>

Access to Ignite Confluence

[Никита Сафонов]

Hi everyone,

Could you please grant me the necessary rights to comment on the confluence
articles?

My full name: Nikita Safonov
Email: vlasovpavel2...@gmail.com

Thank you!

Regards,
Nikita

[DISCUSSION] Documentation feedback button

[Никита Сафонов]

Hello Igniters,

I would like to propose an enhancement that can significantly improve the
quality of our documentation.

I suggest adding a feedback button (let’s call it a «Documentation
feedback» button) to the web site documentation pages so everyone could
leave a comment to what is already published.

The feedback may refer to the Ignite documentation in general or to a
particular section, paragraph, or even term or value.

I do believe that we would harvest dozens and hundreds of ideas,
suggestions, and observations.

I would also suggest using bugyard.io as a solid service for gathering
feedback (I’m quite familiar with it, it is easy to implement, use, and
maintain).

So folks, what do you think of this?

With best regards,
Nikita

Re: IEP-54: Schema-first approach for 3.0

[Andrey Mashenkov]

Pavel, good point.
Thanks. I've added async methods.

On Fri, Mar 12, 2021 at 2:29 PM Pavel Tupitsyn  wrote:

> Andrey,
>
> What about corresponding async APIs, do we add them now or later?
>
> On Thu, Mar 11, 2021 at 8:11 PM Andrey Mashenkov <
> andrey.mashen...@gmail.com>
> wrote:
>
> > Hi Igniters.
> >
> > I've created a PR for Table access API [1].
> > This is an initial version. So, any suggestions\objections are welcomed.
> > Please, do not hesitate to write your comments and\or examples to the PR.
> >
> > Ignite-api module contains API classes, e.g. TableView classes as
> > projections for a table for different purposes.
> > Ignite-table contains dummy implementation and Example class explained
> how
> > it is supposed to be used.
> >
> >
> > Also, I'm still waiting for any feedback for Schema configuration public
> > API PR [2].
> >
> > [1] https://github.com/apache/ignite-3/pull/33
> > [2] https://github.com/apache/ignite-3/pull/2
> >
> > On Wed, Jan 20, 2021 at 6:05 PM Andrey Mashenkov <
> > andrey.mashen...@gmail.com>
> > wrote:
> >
> > >
> > > I've updated a PR regarding your feedback [1].
> > >
> > > [1] https://github.com/apache/ignite-3/pull/2
> > >
> > > On Mon, Jan 11, 2021 at 10:58 AM Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > >> Folks,
> > >>
> > >> I updated the IEP to contain the missing pieces; actually, most of the
> > >> questions here were covered by the text. Please let me know if there
> is
> > >> something still missing or unclear.
> > >>
> > >> чт, 31 дек. 2020 г. в 12:48, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > >> >:
> > >>
> > >> > Mikhail and Igniters,
> > >> >
> > >> > Thanks for your comments. The questions are reasonable, though I
> think
> > >> all
> > >> > concerns are addressed by the IEP as Val mentioned. I will update
> the
> > >> > document according to your questions in the following week or so, so
> > we
> > >> can
> > >> > have a constructive discussion further.
> > >> >
> > >> > ср, 30 дек. 2020 г. в 11:45, Michael Cherkasov <
> > >> > michael.cherka...@gmail.com>:
> > >> >
> > >> >> Hi Val, Andrey,
> > >> >>
> > >> >> thank you for clarifying.
> > >> >>
> > >> >> I still have a few comments.
> > >> >>
> > >> >> 1. one table == one schema. KV vs SQL:
> > >> >> Looks like all agreed that KV is just a special case of a regular
> > table
> > >> >> with (blob,blob) schema.
> > >> >> I worry about the case when the user starts from KV case and later
> > will
> > >> >> try
> > >> >> to expand it and try to leverage SQL for the existing KV table it
> > >> won't be
> > >> >> able to do so and will require to reload data. which isn't
> convenient
> > >> and
> > >> >> sometimes not even possible. Is it possible to extract a new field
> > from
> > >> >> (blob, blob) schema and apply index on it?
> > >> >>
> > >> >> 2. Could you please also list all ways of schema definition in the
> > >> IEP? It
> > >> >> significant change and I bet the main point of this IEP, everyone
> > hates
> > >> >> QueryEntities, they are difficult to manage and in general, it's
> very
> > >> >> confusing to have a data model(schemas) and node/cluster
> > configuration
> > >> in
> > >> >> one place.
> > >> >>
> > >> >> So there will be SchemaBuilder and SQL to define schemas, but
> Andrey
> > >> also
> > >> >> mentioned annotations.
> > >> >>
> > >> >> I personally against configuration via annotations, while it's
> > >> convenient
> > >> >> for development, it difficult to manage because different classes
> can
> > >> be
> > >> >> deployed on different clients/servers nodes and it can lead to
> > >> >> unpredictable results.
> > >> >>
> > >> >> 3. IEP doesn't mention field type changes, only drop/add fields.
> > Field
> > >> >> type
> > >> >> changes are extremely painful right now(if even possible), so it
> > would
> > >> be
> > >> >> nice if some scenarios would be supported(like int8->int16, or
> > >> >> int8->String).
> > >> >>
> > >> >> 4. got it, I thought IEP will have more details about the
> > >> implementation.
> > >> >> I've seen Andrey even sent benchmark results for a new
> serialization,
> > >> will
> > >> >> ping him about this.
> > >> >>
> > >> >> 5. Thanks for the clarification. I had a wrong understanding of
> > strick
> > >> >> mode.
> > >> >>
> > >> >>
> > >> >> вт, 29 дек. 2020 г. в 19:32, Valentin Kulichenko <
> > >> >> valentin.kuliche...@gmail.com>:
> > >> >>
> > >> >> > Hi Mike,
> > >> >> >
> > >> >> > Thanks for providing your feedback. Please see my comments below.
> > >> >> >
> > >> >> > I would also encourage you to go through the IEP-54 [1] - it has
> a
> > >> lot
> > >> >> of
> > >> >> > detail on the topic.
> > >> >> >
> > >> >> > [1]
> > >> >> >
> > >> >> >
> > >> >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach
> > >> >> >
> > >> >> > -Val
> > >> >> >
> > >> >> > On Mon, Dec 28, 2020 at 11:22 PM Michael Cherkasov <
> > >> >> > michael.cherka...@gmail.com> wrote:
> > >> >> >

Re: IEP-70: Async Continuation Executor

[Raymond Wilson]

There is a (long) discussion here (
https://devblogs.microsoft.com/dotnet/configureawait-faq/) regarding use of
ConfigureAwait().

Putting edge cases aside, there is a general use case for
.ConfigureAwait(true) in application UI contexts to ensure the continuation
joins a UI thread (for example), where failing to do so results in an error.

The other general use case relates more to library code where you are
typically running your tasks on the managed thread pool (assuming no custom
task schedulers etc). In this case the .library is agnostic about which
thread pool thread picks up the continuation, so forcing the continuation
to join to the original thread may be both a performance penalty from the
join overhead, but also may add latency waiting for that thread to become
available again.

I don't have good insight into how the striped thread pool is used in
Ignite, but in highly concurrent environments letting those threads escape
into the calling client context seems like a bad idea in general.

Stepping back a little, the Cache Async operations are good for when there
will be an IO operation incurred because the requested element is not
present in memory. If it is present in memory, then a Sync operation will
be more performant. Is it possible to do a two step operation like this
'Cache.GetIfInMemory() ?? await Cache.GetAsync()' to allow the calling
context to optimise the calling model dynamically?

Thanks,
Raymond.


On Wed, Mar 17, 2021 at 6:14 AM Alexey Kukushkin 
wrote:

> Pavel,
>
> My understanding might be wrong but I think the best practice (or even
> strongly recommended way) to implement async methods in .NET is to execute
> continuation on the caller's thread if ConfigureAwait(false) was not
> specified. Pseudo-code might look like:
>
> async Task PutAsync(K k, V v)
> {
> var continuationExecutor = configureAwait
> ? (SynchronizationContext.Current ?? TaskScheduler.Current)
> : null;
>
> await <>
>
> continuationExecutor.Post(continuation);
> }
>
> I got this understanding from reading some blog
> about SynchronizationContext lots of time ago. They were saying they
> created SynchronizationContext specifically to allow posting continuations
> to the caller's thread.
>
> The reason for that is to simplify the user's code to avoid routing in the
> code. Suppose you have a UI (like WPF or WinForms) event handler that must
> be processed on the U thread:
>
> async Task Button1_Click(EventArgs args)
> {
> ignite.PutAsync(args.Key, args.Value);
> Button1.Disabled = true;
> }
>
> Executing the "Button1.Disabled = true" on a ForkJoinPool pool would cause
> a "Trying to modify UI on a non-UI thread" exception. But if you
> capture SynchronizationContext.Current in PutAsync and then route
> continuation to the captured context then the code would work.
>
> I think the users really expect the continuations to be executed on the
> caller's thread.
>
> Sometimes you know that your continuation is really fast and safe and you
> want to avoid switching threads to improve performance. In this case you
> use ConfigureAwait(false) like
>
> ignite.PutAsync(args.Key, args.Value).ConfigureAwat(false);
>
> In this case the continuation executes on the Ignite thread without routing
> to the caller's thread.
>
> вт, 16 мар. 2021 г. в 18:49, Pavel Tupitsyn :
>
> > Alexey,
> >
> > .NET thick API delegates to Java directly.
> >
> > When you do ICache.PutAsync():
> > * Future is created on Java side, .listen() is called
> > * TaskCompletionSource is created on .NET side, its Task is returned to
> the
> > user
> > * Operation completes, Future listener is called on the Java side
> > * Listener invokes JNI callback to .NET, where
> > TaskCompletionSource.SetResult is called
> >
> > Therefore, .NET user code (in ContinueWith or after await) will be
> executed
> > on the Java
> > thread that invokes the future listener.
> >
> > After the proposed fix, future listeners will be invoked on
> > ForkJoinPool#commonPool (instead of striped pool).
> > So .NET continuations will end up in commonPool as well, which solves the
> > problem for .NET automatically, no changes required.
> >
> > Does that make sense?
> >
> > On Tue, Mar 16, 2021 at 1:52 PM Alexey Kukushkin <
> > kukushkinale...@gmail.com>
> > wrote:
> >
> > > Hi Pavel,
> > >
> > > Extending Java async API with additional Executor parameters looks OK
> to
> > > me.
> > >
> > > It is not clear from the IEP how you are going to do that for .NET
> async
> > > API. My understanding is in .NET we do not add any Executors. Instead,
> > the
> > > Ignite Async API should use (SynchronizationContext.Current ??
> > > TaskScheduler.Current) by default and it should have exciting behavior
> > (use
> > > Ignite striped pool) if ConfigureAwait(false) was specified for the
> Task
> > > result.
> > >
> > > Is my understanding correct?
> > >
> > >
> > > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> > >
> > > > Igniters,
> > > >
> > > > Please review 

[jira] [Created] (IGNITE-14326) Add CacheEntry#setTtl method

[Stephen Darlington (Jira)]

Stephen Darlington created IGNITE-14326:
---

 Summary: Add CacheEntry#setTtl method
 Key: IGNITE-14326
 URL: https://issues.apache.org/jira/browse/IGNITE-14326
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.3
Reporter: Stephen Darlington
Assignee: Stephen Darlington


Ignite provides a way to specify an expiry policy on per entry level, but there 
is no way to know the current TTL for a particular key.

We can add {{CacheEntry#ttl()}} and/or {{IgniteCache#ttl(K key)}} method that 
will provide this information. Looks like it's already available via 
{{GridCacheMapEntry#ttl()}}, so we just need to properly expose it to public 
API.

Here is the user forum discussion about this: 
http://apache-ignite-users.70518.x6.nabble.com/Get-TTL-of-the-specific-K-V-entry-td19817.html



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSSION] IEP-69 The evolutionary release process

[Maxim Muzafarov]

Folks,


Thanks to everyone for participating in the call. Here is the list of
points we've agreed on and the list of actions which should be
discussed in more details.


= AGREED =

== Versioning ==

grand.major.bugfix[-rc_number]

The 'grand' version is fixed while both Ignite architectures (current
version 2.x and 3.x) are in a state of active development/maintained
or until otherwise is discussed further. This means:
- the master branch of the ignite repository [2] always release under
the '2.x.x' version
- the main branch of the ignite-3 repository [1] always release under
the '3.x.x' version

The 'major' versions for each architecture may contain breaking
backwards compatibility changes compared to the previous one if the
following criteria are met:
- users should be warned about breaking release changes (the ways of
notification should be additionally discussed and agreed upon)
- the deprecation rules may be applied for the current 'major' release
(the ways of deprecation must be additionally discussed and agreed
upon)
- current @deprecated already have enough time live and some of them
can be removed using common sense

The 'bugfix' version is used for emergency releases and can't contain
any breaking backwards compatibility changes.

== Commitments ==

Any commitment to support previous releases (e.g. 1 year, 1 quarter)
have no sense to the open-source Ignite community in the case of
observed backward compatibility violations, however, in any of such
cases, an emergency release can be performed according to the accepted
release procedure.


= DISCUSSION & SUGGESTIONS =


== Deprecation rules ==

The API deprecation rules must be discussed and agreed upon in more
details. The list of options we have:
- deprecate and remove API allowed in the next release
- deprecate and remove API allowed through the one release
- deprecation may contain comments - the release version then the API
will be changed
- deprecation may contain comments - the date from which the API changes allowed

I've checked the `JEP 277 Enhanced Deprecation` [3] proposal which
adds the `forRemoval` and `since` optional elements to the deprecated
annotation and I think we can use a similar approach here with some
additions. For instance, if the last released version is 2.10 my
suggestions would be the following:
- [case: change API as quickly as possible] mark some API as
deprecated, set 'since' version 2.12, change it in the 2.12 release
major version.
- [case: deprecate API without intention to change] mark API as
deprecated without 'since' options, change it without notifications
since 2.13 releases and so on.


== User notification rules ==

Uses must be well-notified about the planned backward compatibility
violations. The options we have:
- the notification thought the source code with well-described JavaDocs
- add labels to the JIRA issue if some deprecations occur in the related patch
- add deprecation and backward compatibility paragraph to the RELEASE_NOTES
- add a page to the Apache Ignite website with a backwards
compatibility description between the closest versions

All of the above must be done.


== Experimental and unstable APIs ==

The options we have:
- only the new API can be marked as unstable and/or experimental
- such APIs can be changed without any notifications


Please, share your thoughts.


[1] https://github.com/apache/ignite-3
[2] https://github.com/apache/ignite
[3] https://openjdk.java.net/jeps/277

On Mon, 15 Mar 2021 at 19:41, Dmitriy Pavlov  wrote:
>
> Folks,
>
> let me add my 50 cents. I don't see major issues with this IEP, for now.
> And I really looking forward to talking about it. I can't get what causes
> misunderstanding.
>
> The only thing that concerns me here is that IEP requires the community to
> support solutions for 1 year, 1 quarter, etc.
>
> Apache community is not a commercial company that provides support of any
> kind, and I would be reluctant to add these or similar statements to any
> public documents. At any point in time, the community and PMC can vote and
> introduce any major feature breaking compatibility. We tend to avoid such
> actions to keep users best interest. But it is not a commitment.
>
> Sincerely
>
>
> чт, 11 мар. 2021 г. в 23:11, Maxim Muzafarov :
>
> > Val,
> >
> >
> > I'm sorry if anything from what I've said sounded disrespectful. All
> > of you are examples for me to follow :-)
> >
> > Have you checked the `motivation` [1] topic on the IEP-69 page? Should
> > I add more details to it prior to the call? I want to make Ignite
> > better and also think that the current 2.x version with all the
> > advantages and disadvantages is far from exhausted its capabilities.
> > I'm pretty sure the same motivation page exists for 3.0 version
> > describing the advantages and disadvantages of developing mentioned
> > IEPs. It will be good to share it prior to the cal also.
> >
> >
> > [1]
> > 

Re: IEP-70: Async Continuation Executor

[Alexey Kukushkin]

Pavel,

My understanding might be wrong but I think the best practice (or even
strongly recommended way) to implement async methods in .NET is to execute
continuation on the caller's thread if ConfigureAwait(false) was not
specified. Pseudo-code might look like:

async Task PutAsync(K k, V v)
{
var continuationExecutor = configureAwait
? (SynchronizationContext.Current ?? TaskScheduler.Current)
: null;

await <>

continuationExecutor.Post(continuation);
}

I got this understanding from reading some blog
about SynchronizationContext lots of time ago. They were saying they
created SynchronizationContext specifically to allow posting continuations
to the caller's thread.

The reason for that is to simplify the user's code to avoid routing in the
code. Suppose you have a UI (like WPF or WinForms) event handler that must
be processed on the U thread:

async Task Button1_Click(EventArgs args)
{
ignite.PutAsync(args.Key, args.Value);
Button1.Disabled = true;
}

Executing the "Button1.Disabled = true" on a ForkJoinPool pool would cause
a "Trying to modify UI on a non-UI thread" exception. But if you
capture SynchronizationContext.Current in PutAsync and then route
continuation to the captured context then the code would work.

I think the users really expect the continuations to be executed on the
caller's thread.

Sometimes you know that your continuation is really fast and safe and you
want to avoid switching threads to improve performance. In this case you
use ConfigureAwait(false) like

ignite.PutAsync(args.Key, args.Value).ConfigureAwat(false);

In this case the continuation executes on the Ignite thread without routing
to the caller's thread.

вт, 16 мар. 2021 г. в 18:49, Pavel Tupitsyn :

> Alexey,
>
> .NET thick API delegates to Java directly.
>
> When you do ICache.PutAsync():
> * Future is created on Java side, .listen() is called
> * TaskCompletionSource is created on .NET side, its Task is returned to the
> user
> * Operation completes, Future listener is called on the Java side
> * Listener invokes JNI callback to .NET, where
> TaskCompletionSource.SetResult is called
>
> Therefore, .NET user code (in ContinueWith or after await) will be executed
> on the Java
> thread that invokes the future listener.
>
> After the proposed fix, future listeners will be invoked on
> ForkJoinPool#commonPool (instead of striped pool).
> So .NET continuations will end up in commonPool as well, which solves the
> problem for .NET automatically, no changes required.
>
> Does that make sense?
>
> On Tue, Mar 16, 2021 at 1:52 PM Alexey Kukushkin <
> kukushkinale...@gmail.com>
> wrote:
>
> > Hi Pavel,
> >
> > Extending Java async API with additional Executor parameters looks OK to
> > me.
> >
> > It is not clear from the IEP how you are going to do that for .NET async
> > API. My understanding is in .NET we do not add any Executors. Instead,
> the
> > Ignite Async API should use (SynchronizationContext.Current ??
> > TaskScheduler.Current) by default and it should have exciting behavior
> (use
> > Ignite striped pool) if ConfigureAwait(false) was specified for the Task
> > result.
> >
> > Is my understanding correct?
> >
> >
> > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> >
> > > Igniters,
> > >
> > > Please review the IEP [1] and let me know your thoughts.
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
> > >
> >
> >
> > --
> > Best regards,
> > Alexey
> >
>


-- 
Best regards,
Alexey

Re: IEP-70: Async Continuation Executor

[Igor Sapego]

Pavel, I like the proposal,

+1 from me

Best Regards,
Igor


On Tue, Mar 16, 2021 at 6:49 PM Pavel Tupitsyn  wrote:

> Alexey,
>
> .NET thick API delegates to Java directly.
>
> When you do ICache.PutAsync():
> * Future is created on Java side, .listen() is called
> * TaskCompletionSource is created on .NET side, its Task is returned to the
> user
> * Operation completes, Future listener is called on the Java side
> * Listener invokes JNI callback to .NET, where
> TaskCompletionSource.SetResult is called
>
> Therefore, .NET user code (in ContinueWith or after await) will be executed
> on the Java
> thread that invokes the future listener.
>
> After the proposed fix, future listeners will be invoked on
> ForkJoinPool#commonPool (instead of striped pool).
> So .NET continuations will end up in commonPool as well, which solves the
> problem for .NET automatically, no changes required.
>
> Does that make sense?
>
> On Tue, Mar 16, 2021 at 1:52 PM Alexey Kukushkin <
> kukushkinale...@gmail.com>
> wrote:
>
> > Hi Pavel,
> >
> > Extending Java async API with additional Executor parameters looks OK to
> > me.
> >
> > It is not clear from the IEP how you are going to do that for .NET async
> > API. My understanding is in .NET we do not add any Executors. Instead,
> the
> > Ignite Async API should use (SynchronizationContext.Current ??
> > TaskScheduler.Current) by default and it should have exciting behavior
> (use
> > Ignite striped pool) if ConfigureAwait(false) was specified for the Task
> > result.
> >
> > Is my understanding correct?
> >
> >
> > пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
> >
> > > Igniters,
> > >
> > > Please review the IEP [1] and let me know your thoughts.
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
> > >
> >
> >
> > --
> > Best regards,
> > Alexey
> >
>

[jira] [Created] (IGNITE-14325) SQL COPY command: when conversion fails, the error does not contain information about line number and the failed value

[Alexey Goncharuk (Jira)]

Alexey Goncharuk created IGNITE-14325:
-

 Summary: SQL COPY command: when conversion fails, the error does 
not contain information about line number and the failed value
 Key: IGNITE-14325
 URL: https://issues.apache.org/jira/browse/IGNITE-14325
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.10
Reporter: Alexey Goncharuk


I was trying to import data from a CSV file to Ignite cache through sqlline.

When a file contains a value that cannot be converted to the schema format, the 
error message printed by the client is absolutely useless:

{code}
Error: Server error: class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Value 
conversion failed [column=PICKUP_DATETIME, from=java.lang.String, 
to=java.sql.Timestamp] (state=5,code=1)
java.sql.SQLException: Server error: class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Value 
conversion failed [column=PICKUP_DATETIME, from=java.lang.String, 
to=java.sql.Timestamp]
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.sendFile(JdbcThinStatement.java:336)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:243)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
at sqlline.Commands.executeSingleQuery(Commands.java:1054)
at sqlline.Commands.execute(Commands.java:1003)
at sqlline.Commands.sql(Commands.java:967)
at sqlline.SqlLine.dispatch(SqlLine.java:734)
at sqlline.SqlLine.begin(SqlLine.java:541)
at sqlline.SqlLine.start(SqlLine.java:267)
at sqlline.SqlLine.main(SqlLine.java:206)
{code}

The server log does not contain any helpful information as well.

When input validation failed, we need to output the following context 
information:
 * Line number of the source file that triggered the error
 * A few values preceding the wrong column
 * The exact value that failed parse/conversion error
 * For complex types (such as date/timestamp), the acceptable input formats



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: IEP-70: Async Continuation Executor

[Pavel Tupitsyn]

Alexey,

.NET thick API delegates to Java directly.

When you do ICache.PutAsync():
* Future is created on Java side, .listen() is called
* TaskCompletionSource is created on .NET side, its Task is returned to the
user
* Operation completes, Future listener is called on the Java side
* Listener invokes JNI callback to .NET, where
TaskCompletionSource.SetResult is called

Therefore, .NET user code (in ContinueWith or after await) will be executed
on the Java
thread that invokes the future listener.

After the proposed fix, future listeners will be invoked on
ForkJoinPool#commonPool (instead of striped pool).
So .NET continuations will end up in commonPool as well, which solves the
problem for .NET automatically, no changes required.

Does that make sense?

On Tue, Mar 16, 2021 at 1:52 PM Alexey Kukushkin 
wrote:

> Hi Pavel,
>
> Extending Java async API with additional Executor parameters looks OK to
> me.
>
> It is not clear from the IEP how you are going to do that for .NET async
> API. My understanding is in .NET we do not add any Executors. Instead, the
> Ignite Async API should use (SynchronizationContext.Current ??
> TaskScheduler.Current) by default and it should have exciting behavior (use
> Ignite striped pool) if ConfigureAwait(false) was specified for the Task
> result.
>
> Is my understanding correct?
>
>
> пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :
>
> > Igniters,
> >
> > Please review the IEP [1] and let me know your thoughts.
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
> >
>
>
> --
> Best regards,
> Alexey
>

Review request - allocated RAM is always 0 for non-persistent regions

[Ilya Kasnacheev]

Hello!

Guys, can you please review
https://issues.apache.org/jira/browse/IGNITE-13878 ?

I could not find a reviewer for this ticket.

Regards,
-- 
Ilya Kasnacheev

Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)

[Maxim Muzafarov]

Denis,


Thank you. I'll prepare a blog post notes for the major 2.10 features.
The release hasn't been announced yet, some artefacts still waiting to
be published. Hope everything will be ready by the end of this week.


> Btw, don't we want to arrange a meetup gathering for Virtual or 
> Russian-speaking meetup or both?

It depends on our goals. If we want to promote Ignite Summit 2021, so
the English-speaking meetup makes sense.

On Tue, 16 Mar 2021 at 16:00, Denis Magda  wrote:
>
> Hi Maxim,
>
> Ideally, a blog post should be published together with the announcement
> email. So that the readers can learn more details from the article. Anyway,
> you can post it later for 2.10 as long as the release is already completed.
>
> Btw, don't we want to arrange a meetup gathering for Virtual or
> Russian-speaking meetup, or both?
>
> -
> Denis
>
>
> On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov  wrote:
>
> > Folks,
> >
> > I've done almost all the release steps with publishing accepted changes.
> > What should I do with an announcement blog post for blogs.apache.org?
> > Should it also be prepared prior to an announcement message?
> >
> > On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov  wrote:
> > >
> > > Pavel,
> > >
> > > Thank you! I'll prepare a new rc shortly.
> > >
> > > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn 
> > wrote:
> > > >
> > > > Maxim, thanks!
> > > > I've cherry-picked IGNITE-14293.
> > > >
> > > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov 
> > wrote:
> > > >
> > > > > Pavel,
> > > > >
> > > > > Sorry, my bad. Entangled in my local branches during trying to
> > > > > cherry-pick related commits.
> > > > > I've reverted this change.
> > > > >
> > > > >
> > > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn 
> > wrote:
> > > > > >
> > > > > > Maxim,
> > > > > >
> > > > > > I see that you have already cherry-picked IGNITE-13979 - was that
> > > > > > intentional?
> > > > > > If we keep it, let's cherry-pick 14250 as well?
> > > > > >
> > > > > > On Wed, Mar 10, 2021 at 8:21 PM Maxim Muzafarov  > >
> > > > > wrote:
> > > > > >
> > > > > > > Pavel,
> > > > > > >
> > > > > > >
> > > > > > > I think it is better and safe to cherry-pick the `IGNITE-14293
> > .NET:
> > > > > > > AffinityKey does not work` only. I will be very happy to accept
> > your
> > > > > > > help with it.
> > > > > > >
> > > > > > >
> > > > > > > The IGNITE-13979 (.NET: Modernize examples) is very big and has
> > some
> > > > > > > related issues too (most of them are fixed), so I think it is
> > better
> > > > > > > here to postpone it to the next release and give it a bit of
> > time for
> > > > > > > the self-stabilization process :-)
> > > > > > >
> > > > > > > On Wed, 10 Mar 2021 at 20:17, Pavel Tupitsyn <
> > ptupit...@apache.org>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Maxim,
> > > > > > > >
> > > > > > > > Sure, I can assist with cherry-picks.
> > > > > > > >
> > > > > > > > 13661 is fixed by 13979, as indicated by the "fixed by" link
> > in Jira
> > > > > and
> > > > > > > a comment.
> > > > > > > >
> > > > > > > > IGNITE-14293 .NET: AffinityKey does not work is quite an
> > unpleasant
> > > > > > > regression,
> > > > > > > > I think we should include it in the release. It CAN be included
> > > > > without
> > > > > > > 14250 and 13979.
> > > > > > > >
> > > > > > > > 14250 does not make sense without 13979.
> > > > > > > >
> > > > > > > > Ultimately, the question is - do we want to include 13979
> > (.NET:
> > > > > > > Modernize examples),
> > > > > > > > or not. Thoughts?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Mar 10, 2021 at 7:45 PM Maxim Muzafarov <
> > mmu...@apache.org>
> > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> Pavel,
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Can you assist a bit with the cherry-picking process of `.NET:
> > > > > > > >> AffinityKey does not work` IGNITE-14293? I'm not sure I can
> > > > > understand
> > > > > > > >> all the details of implementation and actually, I'm stuck a
> > bit with
> > > > > > > >> the `.NET: Race condition in Events example` IGNITE-14250 [2]
> > issue
> > > > > > > >> not sure what exactly I can exclude from the commit to resolve
> > > > > > > >> conflicts since it has some of them with the 2.10 branch. I'm
> > > > > worried
> > > > > > > >> about missing some important parts of the code.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> - I dive a bit in addition to the .NET examples and found an
> > issue
> > > > > [4]
> > > > > > > >> that has `Fixed` status, however, I can't find it either by
> > id or by
> > > > > > > >> history.
> > > > > > > >> - It is also an important issue (probably I've missed) the
> > .NET:
> > > > > > > >> Modernize examples [5]. Currently, it's not included in 2.10
> > (the
> > > > > fix
> > > > > > > >> `.NET: Race condition in Events example` depends on it)
> > > > > > > >>
> > > > > > > >> So, summarize all if mentioned above:
> > > > > > > >>
> > > > > > > >> Can we cherry-pick 

Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)

[Denis Magda]

Hi Maxim,

Ideally, a blog post should be published together with the announcement
email. So that the readers can learn more details from the article. Anyway,
you can post it later for 2.10 as long as the release is already completed.

Btw, don't we want to arrange a meetup gathering for Virtual or
Russian-speaking meetup, or both?

-
Denis


On Mon, Mar 15, 2021 at 8:55 PM Maxim Muzafarov  wrote:

> Folks,
>
> I've done almost all the release steps with publishing accepted changes.
> What should I do with an announcement blog post for blogs.apache.org?
> Should it also be prepared prior to an announcement message?
>
> On Thu, 11 Mar 2021 at 00:10, Maxim Muzafarov  wrote:
> >
> > Pavel,
> >
> > Thank you! I'll prepare a new rc shortly.
> >
> > On Wed, 10 Mar 2021 at 23:20, Pavel Tupitsyn 
> wrote:
> > >
> > > Maxim, thanks!
> > > I've cherry-picked IGNITE-14293.
> > >
> > > On Wed, Mar 10, 2021 at 10:05 PM Maxim Muzafarov 
> wrote:
> > >
> > > > Pavel,
> > > >
> > > > Sorry, my bad. Entangled in my local branches during trying to
> > > > cherry-pick related commits.
> > > > I've reverted this change.
> > > >
> > > >
> > > > On Wed, 10 Mar 2021 at 21:58, Pavel Tupitsyn 
> wrote:
> > > > >
> > > > > Maxim,
> > > > >
> > > > > I see that you have already cherry-picked IGNITE-13979 - was that
> > > > > intentional?
> > > > > If we keep it, let's cherry-pick 14250 as well?
> > > > >
> > > > > On Wed, Mar 10, 2021 at 8:21 PM Maxim Muzafarov  >
> > > > wrote:
> > > > >
> > > > > > Pavel,
> > > > > >
> > > > > >
> > > > > > I think it is better and safe to cherry-pick the `IGNITE-14293
> .NET:
> > > > > > AffinityKey does not work` only. I will be very happy to accept
> your
> > > > > > help with it.
> > > > > >
> > > > > >
> > > > > > The IGNITE-13979 (.NET: Modernize examples) is very big and has
> some
> > > > > > related issues too (most of them are fixed), so I think it is
> better
> > > > > > here to postpone it to the next release and give it a bit of
> time for
> > > > > > the self-stabilization process :-)
> > > > > >
> > > > > > On Wed, 10 Mar 2021 at 20:17, Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > wrote:
> > > > > > >
> > > > > > > Maxim,
> > > > > > >
> > > > > > > Sure, I can assist with cherry-picks.
> > > > > > >
> > > > > > > 13661 is fixed by 13979, as indicated by the "fixed by" link
> in Jira
> > > > and
> > > > > > a comment.
> > > > > > >
> > > > > > > IGNITE-14293 .NET: AffinityKey does not work is quite an
> unpleasant
> > > > > > regression,
> > > > > > > I think we should include it in the release. It CAN be included
> > > > without
> > > > > > 14250 and 13979.
> > > > > > >
> > > > > > > 14250 does not make sense without 13979.
> > > > > > >
> > > > > > > Ultimately, the question is - do we want to include 13979
> (.NET:
> > > > > > Modernize examples),
> > > > > > > or not. Thoughts?
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Mar 10, 2021 at 7:45 PM Maxim Muzafarov <
> mmu...@apache.org>
> > > > > > wrote:
> > > > > > >>
> > > > > > >> Pavel,
> > > > > > >>
> > > > > > >>
> > > > > > >> Can you assist a bit with the cherry-picking process of `.NET:
> > > > > > >> AffinityKey does not work` IGNITE-14293? I'm not sure I can
> > > > understand
> > > > > > >> all the details of implementation and actually, I'm stuck a
> bit with
> > > > > > >> the `.NET: Race condition in Events example` IGNITE-14250 [2]
> issue
> > > > > > >> not sure what exactly I can exclude from the commit to resolve
> > > > > > >> conflicts since it has some of them with the 2.10 branch. I'm
> > > > worried
> > > > > > >> about missing some important parts of the code.
> > > > > > >>
> > > > > > >>
> > > > > > >> - I dive a bit in addition to the .NET examples and found an
> issue
> > > > [4]
> > > > > > >> that has `Fixed` status, however, I can't find it either by
> id or by
> > > > > > >> history.
> > > > > > >> - It is also an important issue (probably I've missed) the
> .NET:
> > > > > > >> Modernize examples [5]. Currently, it's not included in 2.10
> (the
> > > > fix
> > > > > > >> `.NET: Race condition in Events example` depends on it)
> > > > > > >>
> > > > > > >> So, summarize all if mentioned above:
> > > > > > >>
> > > > > > >> Can we cherry-pick only the `.NET: AffinityKey does not work`
> > > > > > >> IGNITE-14293 without all dependent issues? Or we should apply
> all
> > > > from
> > > > > > >> the chain?
> > > > > > >>
> > > > > > >>
> > > > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-14293
> > > > > > >> [2] https://issues.apache.org/jira/browse/IGNITE-14250
> > > > > > >> [3] https://issues.apache.org/jira/browse/IGNITE-13661
> > > > > > >> [4] https://issues.apache.org/jira/browse/IGNITE-13661
> > > > > > >> [5] https://issues.apache.org/jira/browse/IGNITE-13979
> > > > > > >>
> > > > > > >> On Wed, 10 Mar 2021 at 18:50, Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > > > wrote:
> > > > > > >> >
> > > > > > >> > Maxim,
> > > > > > >> >
> > > > > > >> > No objections to 

[jira] [Created] (IGNITE-14324) EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s

[Alexandr Shapkin (Jira)]

Alexandr Shapkin created IGNITE-14324:
-

 Summary: EVT_CLIENT_NODE_DISCONNECTED is not triggered in k8s
 Key: IGNITE-14324
 URL: https://issues.apache.org/jira/browse/IGNITE-14324
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.9.1
Reporter: Alexandr Shapkin
Assignee: Alexandr Shapkin
 Fix For: 2.11


Scenario:

Kubernetes world, a server node, a k8s service, and a thick client. The client 
is subscribed to EVT_CLIENT_NODE_DISCONNECTED event and is connected to the 
server node.

When a service goes down alongside the server, no EVT_CLIENT_NODE_DISCONNECTED 
is caught and the client reports only about a socket exception and inability to 
resolve IP addresses from the services, cause k8s resource is not available. 
The DEBUG logs (attached) show that discovery is constantly trying to use 
KubernetesIpFinder and restore the connection.

Expected:
Discovery realizes that a client is disconnected, no more reconnection attempts 
happen and EVT_CLIENT_NODE_DISCONNECTED is thrown.

Solution:

Count resolution attempts and if it’s more than the threshold (2 if 
failuredetectiontimeout is not configured, otherwise #reconnCount) give up and 
invoke disconnection logic



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14323) Messaging naming unification

[Sergey Chugunov (Jira)]

Sergey Chugunov created IGNITE-14323:


 Summary: Messaging naming unification
 Key: IGNITE-14323
 URL: https://issues.apache.org/jira/browse/IGNITE-14323
 Project: Ignite
  Issue Type: Sub-task
  Components: networking
Reporter: Sergey Chugunov
 Fix For: 3.0.0-alpha2


Naming of methods for message sending in NetworkCluster interface could be 
unified.

# *send* method returning CompletableFuture with semantics "send message and 
wait when remote node replies with result".
# *sendNoAck* method returning void with semantics "send message to remote node 
and returns immediately when message is sent to it (written to output 
connection)"



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: IEP-70: Async Continuation Executor

[Alexey Kukushkin]

Hi Pavel,

Extending Java async API with additional Executor parameters looks OK to me.

It is not clear from the IEP how you are going to do that for .NET async
API. My understanding is in .NET we do not add any Executors. Instead, the
Ignite Async API should use (SynchronizationContext.Current ??
TaskScheduler.Current) by default and it should have exciting behavior (use
Ignite striped pool) if ConfigureAwait(false) was specified for the Task
result.

Is my understanding correct?


пн, 15 мар. 2021 г. в 19:24, Pavel Tupitsyn :

> Igniters,
>
> Please review the IEP [1] and let me know your thoughts.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-70%3A+Async+Continuation+Executor
>


-- 
Best regards,
Alexey

Re: Hello

[Ilya Kasnacheev]

Hello!

I have added you to Contributors role, you may assign tickets to yourself.

Please make sure to read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


пн, 15 мар. 2021 г. в 23:44, Marius Filip :

> Hi Ilya
>
> My ID on Apache JIRA is marius_filip.
>
> Kind regards,
> Marius Filip
>
> On Mon, Mar 15, 2021 at 10:25 AM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> wrote:
>
> > Hello!
> >
> > Please write your JIRA account name, when you have it, so that I can add
> it
> > to contributors role.
> >
> > Ask me if you have any questions.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вс, 14 мар. 2021 г. в 19:54, Marius Filip :
> >
> > > Hi
> > >
> > > My name is Marius Filip, I am based in London and I am Lead of APIs and
> > > Back-end Services with a small company that produces software for
> > Commodity
> > > Trading called Amphora Inc.
> > >
> > > We are building the new version of our flagship product (which is
> > > successful but in need of modernization) and Apache Ignite is an
> > essential
> > > part of this effort.
> > >
> > > I would like to contribute to Ignite since not only is so important to
> > the
> > > company I work for but also is of great interest to me.
> > >
> > > I have long experience in system programming (from OS to trading
> > platforms)
> > > and for Amphora our main domains of concern are Ignite's
> > transactionality,
> > > persistence and continuous querying so those are the areas where,
> > naturally
> > > I would like mostly to contribute to.
> > >
> > > But I could also help, at least in the beginning, to things like bug
> > > fixing, testing or documentation.
> > >
> > > This endeavour starts with the consent of my employer. Currently I am
> > > following the steps from here (
> > > https://ignite.apache.org/community/resources.html) and here (
> > >
> > >
> >
> https://ignite.apache.org/community/contribute.html#:~:text=Contribute%20by%20Helping%20Others,mailing%20list%20or%20on%20StackOverflow
> > > .)
> > > but more surely I will soon need a bit of info beyond that.
> > >
> > > Regards,
> > > Marius Filip
> > >
> >
>

Re: How to Contribute 2021

[Kseniya Romanova]

So we do have 3 sources for how to contribute:

1. https://ignite.apache.org/community/contribute.html
2. https://github.com/apache/ignite/blob/master/CONTRIBUTING.md
3. https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021

Seems that wiki is more technical, right? But is there any reason for 2
different versions for GitHub and the website?

вт, 16 мар. 2021 г. в 13:11, Ilya Kasnacheev :

> Hello again!
>
> Based on the feedback, I have removed ASCII art from the git section,
> making it shorter and clearer.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 16 мар. 2021 г. в 11:47, Ilya Kasnacheev :
>
> > Hello, Pavel!
> >
> > At the very minimum, a newcomer should be able to run tests on TC or
> MTCGA.
> >
> > Explaining that process takes most of the contribution guide.
> >
> > Even if somebody is ready to run those tests for a newcomer once or twice
> > (already a long shot, it's hard to even get a simple review), they have
> no
> > opportunity to learn except for this guide. They really don't have
> anybody
> > to ask.
> >
> > As I have said, I can't create two documents at the same time so if we
> > need a separate one for committers, it may only be written after the
> fact,
> > and we can't remove essential information in the meantime.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 15 мар. 2021 г. в 18:26, Pavel Tupitsyn :
> >
> >> Ilya,
> >>
> >> Thanks for the effort!
> >>
> >> I think this guide should be much shorter and simple.
> >> Right now it is intimidating for newcomers.
> >>
> >> What they need is basically
> >> * Register in Jira, pick a ticket, assign, put In Progress
> >> * Create a fork, implement
> >> * Create a PR
> >> * Ask for review
> >>
> >> Maybe we should have a separate, detailed guide for Committers,
> >> and a simple one for Contributors?
> >>
> >> On Mon, Mar 15, 2021 at 6:19 PM Ilya Kasnacheev <
> >> ilya.kasnach...@gmail.com>
> >> wrote:
> >>
> >> > Hello!
> >> >
> >> > Please see inline.
> >> >
> >> > пн, 15 мар. 2021 г. в 18:06, Maxim Muzafarov :
> >> >
> >> > > Hello,
> >> > >
> >> > >
> >> > > > Ignite employs both Review-Then-Commit processes.
> >> > >
> >> > > The Commit-Then-Review (CTR) removed?
> >> > >
> >> > I don't see any applications of CTR during the few last years.
> Streamers
> >> > were supposed to be CTR but Saikat Maitra still asked for the review
> of
> >> > streamers-related commits.
> >> >
> >> > > Information for committers
> >> > >
> >> > > Do we need this on a page for newcomers? I'd like to mention that
> some
> >> > > of the committers still use the commit script, however, I think it
> >> > > will be better to configure the GitHub interaction.
> >> > >
> >> > I don't think there's a separate page for committers. If there is,
> >> please
> >> > point me to it, and we can remove the section. I don't think we should
> >> be
> >> > writing two pages at once, so I decided not to drop any essential
> >> > information.
> >> >
> >> > > Components and their maintainers
> >> > >
> >> > > It seems that this list should be updated too.
> >> > >
> >> > I would be glad if somebody does it, but I don't have any more
> >> information
> >> > to fill there.
> >> >
> >> >
> >> > > > Working on a ticket
> >> > > I think we should mention the Intellij IDEA checkstyle plugin and
> its
> >> > > configuration (importation of checkstyle.xml to the IDE).
> >> > >
> >> > I would be glad if somebody contributes to it, or we may just provide
> a
> >> > link to coding guidelines and mention it there.
> >> >
> >> >
> >> >
> >> > > > GIT workflow
> >> > >
> >> > > Do we need it?
> >> > >
> >> > I think we do, this workflow is non-trivial and I don't think it is
> >> > documented anywhere. We can get rid of ASCII art section, though.
> >> >
> >> > WDYT?
> >> >
> >> > Regards,
> >> >
> >> >
> >> > >
> >> > >
> >> > > On Mon, 15 Mar 2021 at 17:25, Ilya Kasnacheev <
> >> ilya.kasnach...@gmail.com
> >> > >
> >> > > wrote:
> >> > > >
> >> > > > Hello!
> >> > > >
> >> > > > When adding new users to the Contributor role, we usually give
> them
> >> a
> >> > > link
> >> > > > to "How to Contribute" wiki page.
> >> > > >
> >> > > > However, I was feeling that it was in many ways outdated,
> referring
> >> to
> >> > > > outdated development practices and not emphasising TC tests and
> >> MTCGA
> >> > > bot.
> >> > > >
> >> > > > So we took liberty to rewrite this page, meet
> >> > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021
> >> > > >
> >> > > > We tried to streamline it, make it more friendly to newcomers and
> >> just
> >> > > > shorter.
> >> > > >
> >> > > > Please check it out, share your feelings.
> >> > > >
> >> > > > I plan to replace the legacy
> >> > > >
> >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> >> > > with
> >> > > > this page based on your feedback..
> >> > > >
> >> > > > Regards,
> >> > > > --
> >> > > > Ilya Kasnacheev
> >> > >
> >> >
> >>
> >
>

Re: How to Contribute 2021

[Ilya Kasnacheev]

Hello again!

Based on the feedback, I have removed ASCII art from the git section,
making it shorter and clearer.

Regards,
-- 
Ilya Kasnacheev


вт, 16 мар. 2021 г. в 11:47, Ilya Kasnacheev :

> Hello, Pavel!
>
> At the very minimum, a newcomer should be able to run tests on TC or MTCGA.
>
> Explaining that process takes most of the contribution guide.
>
> Even if somebody is ready to run those tests for a newcomer once or twice
> (already a long shot, it's hard to even get a simple review), they have no
> opportunity to learn except for this guide. They really don't have anybody
> to ask.
>
> As I have said, I can't create two documents at the same time so if we
> need a separate one for committers, it may only be written after the fact,
> and we can't remove essential information in the meantime.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 15 мар. 2021 г. в 18:26, Pavel Tupitsyn :
>
>> Ilya,
>>
>> Thanks for the effort!
>>
>> I think this guide should be much shorter and simple.
>> Right now it is intimidating for newcomers.
>>
>> What they need is basically
>> * Register in Jira, pick a ticket, assign, put In Progress
>> * Create a fork, implement
>> * Create a PR
>> * Ask for review
>>
>> Maybe we should have a separate, detailed guide for Committers,
>> and a simple one for Contributors?
>>
>> On Mon, Mar 15, 2021 at 6:19 PM Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com>
>> wrote:
>>
>> > Hello!
>> >
>> > Please see inline.
>> >
>> > пн, 15 мар. 2021 г. в 18:06, Maxim Muzafarov :
>> >
>> > > Hello,
>> > >
>> > >
>> > > > Ignite employs both Review-Then-Commit processes.
>> > >
>> > > The Commit-Then-Review (CTR) removed?
>> > >
>> > I don't see any applications of CTR during the few last years. Streamers
>> > were supposed to be CTR but Saikat Maitra still asked for the review of
>> > streamers-related commits.
>> >
>> > > Information for committers
>> > >
>> > > Do we need this on a page for newcomers? I'd like to mention that some
>> > > of the committers still use the commit script, however, I think it
>> > > will be better to configure the GitHub interaction.
>> > >
>> > I don't think there's a separate page for committers. If there is,
>> please
>> > point me to it, and we can remove the section. I don't think we should
>> be
>> > writing two pages at once, so I decided not to drop any essential
>> > information.
>> >
>> > > Components and their maintainers
>> > >
>> > > It seems that this list should be updated too.
>> > >
>> > I would be glad if somebody does it, but I don't have any more
>> information
>> > to fill there.
>> >
>> >
>> > > > Working on a ticket
>> > > I think we should mention the Intellij IDEA checkstyle plugin and its
>> > > configuration (importation of checkstyle.xml to the IDE).
>> > >
>> > I would be glad if somebody contributes to it, or we may just provide a
>> > link to coding guidelines and mention it there.
>> >
>> >
>> >
>> > > > GIT workflow
>> > >
>> > > Do we need it?
>> > >
>> > I think we do, this workflow is non-trivial and I don't think it is
>> > documented anywhere. We can get rid of ASCII art section, though.
>> >
>> > WDYT?
>> >
>> > Regards,
>> >
>> >
>> > >
>> > >
>> > > On Mon, 15 Mar 2021 at 17:25, Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com
>> > >
>> > > wrote:
>> > > >
>> > > > Hello!
>> > > >
>> > > > When adding new users to the Contributor role, we usually give them
>> a
>> > > link
>> > > > to "How to Contribute" wiki page.
>> > > >
>> > > > However, I was feeling that it was in many ways outdated, referring
>> to
>> > > > outdated development practices and not emphasising TC tests and
>> MTCGA
>> > > bot.
>> > > >
>> > > > So we took liberty to rewrite this page, meet
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021
>> > > >
>> > > > We tried to streamline it, make it more friendly to newcomers and
>> just
>> > > > shorter.
>> > > >
>> > > > Please check it out, share your feelings.
>> > > >
>> > > > I plan to replace the legacy
>> > > >
>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>> > > with
>> > > > this page based on your feedback..
>> > > >
>> > > > Regards,
>> > > > --
>> > > > Ilya Kasnacheev
>> > >
>> >
>>
>

[jira] [Created] (IGNITE-14322) False warning about DataRegionConfiguration.maxWalArchiveSize property usage

[Aleksandr Polovtcev (Jira)]

Aleksandr Polovtcev created IGNITE-14322:


 Summary: False warning about 
DataRegionConfiguration.maxWalArchiveSize property usage
 Key: IGNITE-14322
 URL: https://issues.apache.org/jira/browse/IGNITE-14322
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev


On every non-persistent startup the following is printed:

DataRegionConfiguration.maxWalArchiveSize instead 
DataRegionConfiguration.walHistorySize would be used for removing old archive 
wal files

This does not make sense when persistence is totally off.

Also, syntax should be fixed, "instead of", should be more clear what's going 
on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: How to Contribute 2021

[Ilya Kasnacheev]

Hello, Pavel!

At the very minimum, a newcomer should be able to run tests on TC or MTCGA.

Explaining that process takes most of the contribution guide.

Even if somebody is ready to run those tests for a newcomer once or twice
(already a long shot, it's hard to even get a simple review), they have no
opportunity to learn except for this guide. They really don't have anybody
to ask.

As I have said, I can't create two documents at the same time so if we need
a separate one for committers, it may only be written after the fact, and
we can't remove essential information in the meantime.

Regards,
-- 
Ilya Kasnacheev


пн, 15 мар. 2021 г. в 18:26, Pavel Tupitsyn :

> Ilya,
>
> Thanks for the effort!
>
> I think this guide should be much shorter and simple.
> Right now it is intimidating for newcomers.
>
> What they need is basically
> * Register in Jira, pick a ticket, assign, put In Progress
> * Create a fork, implement
> * Create a PR
> * Ask for review
>
> Maybe we should have a separate, detailed guide for Committers,
> and a simple one for Contributors?
>
> On Mon, Mar 15, 2021 at 6:19 PM Ilya Kasnacheev  >
> wrote:
>
> > Hello!
> >
> > Please see inline.
> >
> > пн, 15 мар. 2021 г. в 18:06, Maxim Muzafarov :
> >
> > > Hello,
> > >
> > >
> > > > Ignite employs both Review-Then-Commit processes.
> > >
> > > The Commit-Then-Review (CTR) removed?
> > >
> > I don't see any applications of CTR during the few last years. Streamers
> > were supposed to be CTR but Saikat Maitra still asked for the review of
> > streamers-related commits.
> >
> > > Information for committers
> > >
> > > Do we need this on a page for newcomers? I'd like to mention that some
> > > of the committers still use the commit script, however, I think it
> > > will be better to configure the GitHub interaction.
> > >
> > I don't think there's a separate page for committers. If there is, please
> > point me to it, and we can remove the section. I don't think we should be
> > writing two pages at once, so I decided not to drop any essential
> > information.
> >
> > > Components and their maintainers
> > >
> > > It seems that this list should be updated too.
> > >
> > I would be glad if somebody does it, but I don't have any more
> information
> > to fill there.
> >
> >
> > > > Working on a ticket
> > > I think we should mention the Intellij IDEA checkstyle plugin and its
> > > configuration (importation of checkstyle.xml to the IDE).
> > >
> > I would be glad if somebody contributes to it, or we may just provide a
> > link to coding guidelines and mention it there.
> >
> >
> >
> > > > GIT workflow
> > >
> > > Do we need it?
> > >
> > I think we do, this workflow is non-trivial and I don't think it is
> > documented anywhere. We can get rid of ASCII art section, though.
> >
> > WDYT?
> >
> > Regards,
> >
> >
> > >
> > >
> > > On Mon, 15 Mar 2021 at 17:25, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > When adding new users to the Contributor role, we usually give them a
> > > link
> > > > to "How to Contribute" wiki page.
> > > >
> > > > However, I was feeling that it was in many ways outdated, referring
> to
> > > > outdated development practices and not emphasising TC tests and MTCGA
> > > bot.
> > > >
> > > > So we took liberty to rewrite this page, meet
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute+2021
> > > >
> > > > We tried to streamline it, make it more friendly to newcomers and
> just
> > > > shorter.
> > > >
> > > > Please check it out, share your feelings.
> > > >
> > > > I plan to replace the legacy
> > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > with
> > > > this page based on your feedback..
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > >
> >
>

Re: Long transaction suspended

[Zhenya Stanilovsky]

hi jjimeno, plz check your throughput once more by using 
OPTIMISTIC, SERIALIZABLE options, hope it would be more faster than default.

 
>
>
>--- Forwarded message ---
>From: jjimeno < jjim...@omp.com >
>To:  u...@ignite.apache.org
>Cc:
>Subject: Long transaction suspended
>Date: Thu, 04 Feb 2021 12:32:20 +0300
>
>Hi all,
>
>I'm trying to commit a very large transaction (8M keys and ~4GB of data).
>
>After a while, I can see this diagnostics message in node log:
>[08:56:31,721][WARNING][sys-#989][diagnostic] >>> Transaction
>[startTime=08:55:22.095, curTime=08:56:31.712, ... *state=SUSPENDED* ...
>
>Does anyone know why it is suspended, and how to avoid it?
>
>Thanks in advance
>José
>
>
>
>
>
>--
>Sent from:  http://apache-ignite-users.70518.x6.nabble.com/ 
 
 
 
 

[jira] [Created] (IGNITE-14321) Forced index rebuilding does not work correctly

[Kirill Tkalenko (Jira)]

Kirill Tkalenko created IGNITE-14321:


 Summary: Forced index rebuilding does not work correctly
 Key: IGNITE-14321
 URL: https://issues.apache.org/jira/browse/IGNITE-14321
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 2.11


At the moment, it is not possible to force an index rebuild twice (or more) 
even if the first run fails, and this also applies to command *control.sh 
--cache indexes_force_rebuild*.

Thus, you need to fix:
* *GridCacheDatabaseSharedManager#forceRebuildIndexes*
* *CacheIndexesForceRebuild#execute*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)