Re: [DISCUSS] ThreadGroup for IgniteThread

[Ivan Pavlukhin]

Igniters,

I prepared PR removing custom ThreadGroup for a ticket [1]. Everybody
is welcome to review. If there will be no objections I am going to
merge the patch by the end of this week.

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

пт, 24 янв. 2020 г. в 13:15, Alexey Goncharuk :
>
> Ivan,
>
> I believe that the removal of the thread group is harmless. Let's check
> with the rest of the community, and if there is no objections, remove it.
>
> пт, 24 янв. 2020 г. в 11:13, Ivan Pavlukhin :
>
> > Alex,
> >
> > > We can either remove it (not sure if this is a breaking public API
> > change?)
> > > or create a separate thread group per Ignite instance and pass it to the
> > > constructor of IgniteThread (quite a lot of refactoring).
> >
> > Recently there were a discussion about "magic stuff" in codebase. And
> > it seems that we should eliminate such stuff if there is no chance to
> > understand why is it needed.
> >
> > I run TC after dropping special ThreadGroup and did not get any new
> > failures [1]. It can imagine that dedicated ThreadGroup has some sense
> > for application servers. But personally I would prefer to get rid of
> > that ThreadGroup. A more conservative approach is to use some flag
> > (system property) to control it.
> >
> > [1]
> > https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/7297/head=Latest
> >
> > вт, 21 янв. 2020 г. в 16:39, Alexey Goncharuk  > >:
> > >
> > > Ivan,
> > >
> > > I cannot recall why exactly a separate thread group was needed. I guess
> > the
> > > intention was to collect all threads related to Ignite to one group, but
> > I
> > > see no practical use of that particular implementation.
> > >
> > > We can either remove it (not sure if this is a breaking public API
> > change?)
> > > or create a separate thread group per Ignite instance and pass it to the
> > > constructor of IgniteThread (quite a lot of refactoring).
> > >
> > > вт, 21 янв. 2020 г. в 13:17, Ivan Pavlukhin :
> > >
> > > > Hi,
> > > >
> > > > As you might know, IgniteThread class captures calling ThreadGroup on
> > > > initialization (as IgniteThread.DFLT_GRP) and includes all new ignite
> > > > threads into this group. A user reported an issue [1] related to it.
> > > > And the root cause here is that captured DFLT_GRP is out of control of
> > > > IgniteThread class. Looks like a design fault. Consequently several
> > > > unclear points:
> > > > 1. What is the real need for IgniteThread.DFLT_GRP?
> > > > 2. Can we simply stop using this trick?
> > > > 3. Could there be any better options to do the same?
> > > >
> > > > Please share your thoughts.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-12554
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

Andrey.

> My choice: correctness over performance

I don’t think we should select performance OR correctness here.
It seems we can got both.

> May be we should rollback all metrics related changes because we don't have 
> benchmark results

I perform benchmarking for initial refactoring of 
TcpCommunicationMetricsListener.
Initial refactoring of TcpCommunicationMetricsListener doesn’t bring any 
performance drop according to the results of the tests I performed.

I want to perform benchmarking just to be sure everything OK.
Please, wait while I gather benchmark results for this PR.

> 27 янв. 2020 г., в 22:33, Andrey Gura  написал(а):
> 
>> We still can’t accept patches that badly affects the performance of 
>> TcpCommuncationMetricsListener.
>> So we should perform yardstick tests before the merge.
> 
> Absolutely all metrics are on the hot path. They inevitably affect
> performance and this case is the same. May be we should rollback all
> metrics related changes because we don't have benchmark results&
> 
>> I can help to run yardstick benchmarks if you don’t have free servers to do 
>> it.
> 
> I don't need help in benchmarking. Once again, еhe current behavior is
> incorrect and should be fixed regardless of performance.
> 
> Or... this functionality should be removed if performance is more
> important. In case of incorrect behavior it is the best option.
> 
> My choice: correctness over performance.
> 
> On Mon, Jan 27, 2020 at 10:02 PM Nikolay Izhikov  wrote:
>> 
>>> I think it could be fixed easily by adding metricsEnabled flag to 
>>> TcpCommunicationSpi.
>> 
>> We still can’t accept patches that badly affects the performance of 
>> TcpCommuncationMetricsListener.
>> So we should perform yardstick tests before the merge.
>> 
>> I can help to run yardstick benchmarks if you don’t have free servers to do 
>> it.
>> 
>> 
>>> 27 янв. 2020 г., в 21:47, Andrey Gura  написал(а):
>>> 
> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
 Please, clarify, what do you mean by «doesn’t work»?
 Are there any unresolved bugs?
>>> 
>>> Obviously some communication metrics can't be monitored or analyzed
>>> retrospectively due to changing node ID during node restart. It's bug.
>>> 
> User can disable metrics if it will affect performance.
 Users can’t disable TcpCommunicationListener nor in any release nor in 
 current master so we should change this code carefully
>>> 
>>> This is another bug. I think it could be fixed easily by adding
>>> metricsEnabled flag to TcpCommunicationSpi.
>>> 
>>> On Mon, Jan 27, 2020 at 9:17 PM Nikolay Izhikov  wrote:
 
 Andrey.
 
> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
 
 Please, clarify, what do you mean by «doesn’t work»?
 Are there any unresolved bugs?
 
> IGINTE-12576 affects it minimally
 
 All I asking for is to confirm this statement with the benchmark results.
 
> User can disable metrics if it will affect performance.
 
 Users can’t disable TcpCommunicationListener nor in any release nor in 
 current master so we should change this code carefully
 
 https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L1178
 
> 27 янв. 2020 г., в 20:40, Andrey Gura  написал(а):
> 
> Nikolay,
> 
>> But, we must gather yardstick benchmark results for PR(comparing to 
>> current master) before merge to ensure there is no performance drop.
> 
> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> 
> I believe that benchmarks ignite-2.7.6 vs ignite-2.8 will show
> noticeable drop in performance for ignite-2.8. But it is cumulative
> effect and IGINTE-12576 affects it minimally.
> 
>> Note, that these metrics updated on each communication message.
> 
> Metrics are not free at all. User can disable metrics if it will
> affect performance.
> 
> On Mon, Jan 27, 2020 at 8:23 PM Nikolay Izhikov  
> wrote:
>> 
>> Hello, Andrey.
>> 
>> I’m OK to include these changes to 2.8.
>> I don’t review PR, but the ticket description makes sense to me.
>> 
>> But, we must gather yardstick benchmark results for PR(comparing to 
>> current master) before merge to ensure there is no performance drop.
>> Note, that these metrics updated on each communication message.
>> 
>>> 27 янв. 2020 г., в 18:19, Andrey Gura  написал(а):
>>> 
>>> Igniters,
>>> 
>>> I want to add one more issue to the Apache Ignite 2.8 release scope [1].
>>> 
>>> The problem is impossibility of using communication metrics gathered
>>> for nodes in the cluster because node ID will changed in case of
>>> restart. Obvious solution is using consistent ID instead of node ID.
>>> 
>>> PR is already implemented and ready for review.

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Andrey Gura]

> We still can’t accept patches that badly affects the performance of 
> TcpCommuncationMetricsListener.
> So we should perform yardstick tests before the merge.

 Absolutely all metrics are on the hot path. They inevitably affect
performance and this case is the same. May be we should rollback all
metrics related changes because we don't have benchmark results&

> I can help to run yardstick benchmarks if you don’t have free servers to do 
> it.

I don't need help in benchmarking. Once again, еhe current behavior is
incorrect and should be fixed regardless of performance.

Or... this functionality should be removed if performance is more
important. In case of incorrect behavior it is the best option.

My choice: correctness over performance.

On Mon, Jan 27, 2020 at 10:02 PM Nikolay Izhikov  wrote:
>
> > I think it could be fixed easily by adding metricsEnabled flag to 
> > TcpCommunicationSpi.
>
> We still can’t accept patches that badly affects the performance of 
> TcpCommuncationMetricsListener.
> So we should perform yardstick tests before the merge.
>
> I can help to run yardstick benchmarks if you don’t have free servers to do 
> it.
>
>
> > 27 янв. 2020 г., в 21:47, Andrey Gura  написал(а):
> >
> >>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> >> Please, clarify, what do you mean by «doesn’t work»?
> >> Are there any unresolved bugs?
> >
> > Obviously some communication metrics can't be monitored or analyzed
> > retrospectively due to changing node ID during node restart. It's bug.
> >
> >>> User can disable metrics if it will affect performance.
> >> Users can’t disable TcpCommunicationListener nor in any release nor in 
> >> current master so we should change this code carefully
> >
> > This is another bug. I think it could be fixed easily by adding
> > metricsEnabled flag to TcpCommunicationSpi.
> >
> > On Mon, Jan 27, 2020 at 9:17 PM Nikolay Izhikov  wrote:
> >>
> >> Andrey.
> >>
> >>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> >>
> >> Please, clarify, what do you mean by «doesn’t work»?
> >> Are there any unresolved bugs?
> >>
> >>> IGINTE-12576 affects it minimally
> >>
> >> All I asking for is to confirm this statement with the benchmark results.
> >>
> >>> User can disable metrics if it will affect performance.
> >>
> >> Users can’t disable TcpCommunicationListener nor in any release nor in 
> >> current master so we should change this code carefully
> >>
> >> https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L1178
> >>
> >>> 27 янв. 2020 г., в 20:40, Andrey Gura  написал(а):
> >>>
> >>> Nikolay,
> >>>
>  But, we must gather yardstick benchmark results for PR(comparing to 
>  current master) before merge to ensure there is no performance drop.
> >>>
> >>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> >>>
> >>> I believe that benchmarks ignite-2.7.6 vs ignite-2.8 will show
> >>> noticeable drop in performance for ignite-2.8. But it is cumulative
> >>> effect and IGINTE-12576 affects it minimally.
> >>>
>  Note, that these metrics updated on each communication message.
> >>>
> >>> Metrics are not free at all. User can disable metrics if it will
> >>> affect performance.
> >>>
> >>> On Mon, Jan 27, 2020 at 8:23 PM Nikolay Izhikov  
> >>> wrote:
> 
>  Hello, Andrey.
> 
>  I’m OK to include these changes to 2.8.
>  I don’t review PR, but the ticket description makes sense to me.
> 
>  But, we must gather yardstick benchmark results for PR(comparing to 
>  current master) before merge to ensure there is no performance drop.
>  Note, that these metrics updated on each communication message.
> 
> > 27 янв. 2020 г., в 18:19, Andrey Gura  написал(а):
> >
> > Igniters,
> >
> > I want to add one more issue to the Apache Ignite 2.8 release scope [1].
> >
> > The problem is impossibility of using communication metrics gathered
> > for nodes in the cluster because node ID will changed in case of
> > restart. Obvious solution is using consistent ID instead of node ID.
> >
> > PR is already implemented and ready for review.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12576
> >
> > On Fri, Jan 24, 2020 at 4:06 PM Maxim Muzafarov  
> > wrote:
> >>
> >> Folks,
> >>
> >>
> >> I've cherry-picked these issues [1] [2] to the 2.8 release branch.
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12540
> >> Update versions of vulnerable dependencies
> >>
> >> [2] https://issues.apache.org/jira/browse/IGNITE-12486
> >> Truncation of archived WAL segments doesn't work
> >>
> >> On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  
> >> wrote:
> >>>
> >>> Hi igniters,
> >>>
> >>> there's a potential data corruption fix that I'd like you 

Re: Internal classes are exposed in public API

[Andrey Gura]

>> I just want to remove the deprecations on the classes for which there is no 
>> a well-defined replacement.
> Well-defined replacement for these classes exists.

Nikolay, statements like this are not arguments. At least because
there are people who disagree with this.

Current implementation is not well-defined due to API is not
well-defined enough. Also there are lack of functionality
(enabling/disabling metrics, requirement for end user to configure new
exporter in order to get a couple of new metrics while it is still
possible to use old MBeans but without this metrics) and potential
performance problems (that couldn't be solved because metrics couldn't
be switched off).

We are walking in a circle instead of moving forward. On comments
about API you provide new PRs that change API while denying problems
with the API. This is illogical and process doesn't converge because
it is attempt to close gaps in a hurry.

The best we can do now is stop, take a deep breath and follow the
offers of Alexey about deprecation, my proposal and Denis' idea about
one additional iteration.

On Mon, Jan 27, 2020 at 4:37 PM Nikolay Izhikov  wrote:
>
> > it's better to remove deprecation for the old APIs in AI 2.8
>
> Are you suggest to have 2 concurrent metrics implementations(both not 
> deprecated)?
>
> > Let's say I am writing a custom exporter in binary format and I need to 
> > write the number of exported metrics in a packet beforehand.
>
> This an `MetricExporterSPI` implementation task.
> Exporter has the listeners that can be used to track all registry events - 
> creation, removal
>
> > There is no separation on public and internal metrics
>
> I think we should write in the documentation that ANY metric can be changed.
> We will try to keep them, but if we found that some metric doesn’t required 
> any more or implemented in the wrong way - we can remove it.
>
> > Will we allow users to register their own metrics?
>
> No. Why we should considering this feature?
>
> > It's still not clear how a user will map old interfaces and methods to the 
> > new metric names.
>
> With the documentation.
> We can write separate deprecation comment for each metric providing method.
>
> > I just want to remove the deprecations on the classes for which there is no 
> > a well-defined replacement.
>
> Well-defined replacement for these classes exists.
>
> > 27 янв. 2020 г., в 16:21, Alexey Goncharuk  
> > написал(а):
> >
> > Nikolay,
> >
> > I've reviewed your changes and I tend to agree with Andrey, it's better to
> > remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
> > facade (IGNITE-12553) in a more calm and structured way. My observations on
> > the changes:
> >
> >   - I am not sure if Iterable would suffice both for the exporter and
> >   public APIs. Should we provide a way to know the number of metrics and
> >   registries in advance? Let's say I am writing a custom exporter in binary
> >   format and I need to write the number of exported metrics in a packet
> >   beforehand.
> >   - There is no separation on public and internal metrics, when public
> >   metrics preserve their name and semantics, and internal metrics may 
> > change.
> >   I remember we discussed this, but it's not reflected in the APIs in any 
> > way.
> >   - Will we allow users to register their own metrics? Again I remember we
> >   discussed a possibility for this. If so, why the registry is called
> >   'ReadyOnly'?
> >   - It's still not clear how a user will map old interfaces and methods to
> >   the new metric names.
> >
> > As you can see in the original message, I am not pushing for the new APIs
> > in the nearest release, I just want to remove the deprecations on the
> > classes for which there is no a well-defined replacement.
> >
> > пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov :
> >
> >> Folks,
> >>
> >>
> >> I'm sorry for not being too attentive to the whole thread discussion
> >> and maybe missing some details.
> >>
> >> But... who will perform the review of [1] issue?
> >> Will we merge it to 2.8? (hope so)
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >> [IEP-35] public Java metric API
> >>
> >> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков  wrote:
> >>>
> >>> Andrey.
> >>>
> >>> With this API we are trying to fill the GAP Alexey pointed out at the
> >> start of this discussion.
> >>> I think it worth to be reviewed and merged.
> >>>
> >>> Can we, please, come back to the discussion of the changes itself?
> >>> I think API changes should be discussed in the other thread.
> >>>
>  Why do you think this is a wrong usage pattern? From the top of my
> >> head, here is a few cases of direct metric API usage that I know are
> >> currently being used in production:
>  * A custom task execution scheduling service with load balancing based
> >> on utilization metrics readings from Java code
>  * Cleanup task trigger based on metrics readings
>  * A custom health-check 

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

> I think it could be fixed easily by adding metricsEnabled flag to 
> TcpCommunicationSpi.

We still can’t accept patches that badly affects the performance of 
TcpCommuncationMetricsListener.
So we should perform yardstick tests before the merge.

I can help to run yardstick benchmarks if you don’t have free servers to do it.


> 27 янв. 2020 г., в 21:47, Andrey Gura  написал(а):
> 
>>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
>> Please, clarify, what do you mean by «doesn’t work»?
>> Are there any unresolved bugs?
> 
> Obviously some communication metrics can't be monitored or analyzed
> retrospectively due to changing node ID during node restart. It's bug.
> 
>>> User can disable metrics if it will affect performance.
>> Users can’t disable TcpCommunicationListener nor in any release nor in 
>> current master so we should change this code carefully
> 
> This is another bug. I think it could be fixed easily by adding
> metricsEnabled flag to TcpCommunicationSpi.
> 
> On Mon, Jan 27, 2020 at 9:17 PM Nikolay Izhikov  wrote:
>> 
>> Andrey.
>> 
>>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
>> 
>> Please, clarify, what do you mean by «doesn’t work»?
>> Are there any unresolved bugs?
>> 
>>> IGINTE-12576 affects it minimally
>> 
>> All I asking for is to confirm this statement with the benchmark results.
>> 
>>> User can disable metrics if it will affect performance.
>> 
>> Users can’t disable TcpCommunicationListener nor in any release nor in 
>> current master so we should change this code carefully
>> 
>> https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L1178
>> 
>>> 27 янв. 2020 г., в 20:40, Andrey Gura  написал(а):
>>> 
>>> Nikolay,
>>> 
 But, we must gather yardstick benchmark results for PR(comparing to 
 current master) before merge to ensure there is no performance drop.
>>> 
>>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
>>> 
>>> I believe that benchmarks ignite-2.7.6 vs ignite-2.8 will show
>>> noticeable drop in performance for ignite-2.8. But it is cumulative
>>> effect and IGINTE-12576 affects it minimally.
>>> 
 Note, that these metrics updated on each communication message.
>>> 
>>> Metrics are not free at all. User can disable metrics if it will
>>> affect performance.
>>> 
>>> On Mon, Jan 27, 2020 at 8:23 PM Nikolay Izhikov  wrote:
 
 Hello, Andrey.
 
 I’m OK to include these changes to 2.8.
 I don’t review PR, but the ticket description makes sense to me.
 
 But, we must gather yardstick benchmark results for PR(comparing to 
 current master) before merge to ensure there is no performance drop.
 Note, that these metrics updated on each communication message.
 
> 27 янв. 2020 г., в 18:19, Andrey Gura  написал(а):
> 
> Igniters,
> 
> I want to add one more issue to the Apache Ignite 2.8 release scope [1].
> 
> The problem is impossibility of using communication metrics gathered
> for nodes in the cluster because node ID will changed in case of
> restart. Obvious solution is using consistent ID instead of node ID.
> 
> PR is already implemented and ready for review.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-12576
> 
> On Fri, Jan 24, 2020 at 4:06 PM Maxim Muzafarov  wrote:
>> 
>> Folks,
>> 
>> 
>> I've cherry-picked these issues [1] [2] to the 2.8 release branch.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-12540
>> Update versions of vulnerable dependencies
>> 
>> [2] https://issues.apache.org/jira/browse/IGNITE-12486
>> Truncation of archived WAL segments doesn't work
>> 
>> On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  
>> wrote:
>>> 
>>> Hi igniters,
>>> 
>>> there's a potential data corruption fix that I'd like you to include in 
>>> the
>>> next release:
>>> https://issues.apache.org/jira/browse/IGNITE-12486https://issues.apache.org/jira/browse/IGNITE-12486
>>> 
>>> 
>>> Can you please cherry-pick it? Thank you!
>>> 
>>> ср, 22 янв. 2020 г. в 17:45, Pavel Tupitsyn :
>>> 
 Good idea about pre-release build of ignite-2.8 branch.
 However, I would not name it `rc`, since it is not really a release
 candidate. Make it `pre0` or something like that.
 
 For Ignite.NET I've uploaded pre-release NuGet packages built from 
 current
 ignite-2.8 branch:
 https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20200122
 
 
 On Wed, Jan 22, 2020 at 3:09 PM Ilya Kasnacheev 
  
 wrote:
 
> Hello!
> 
> I have committed the bumping of essential dependencies' versions:
> 

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Andrey Gura]

>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> Please, clarify, what do you mean by «doesn’t work»?
> Are there any unresolved bugs?

Obviously some communication metrics can't be monitored or analyzed
retrospectively due to changing node ID during node restart. It's bug.

>>  User can disable metrics if it will affect performance.
> Users can’t disable TcpCommunicationListener nor in any release nor in 
> current master so we should change this code carefully

This is another bug. I think it could be fixed easily by adding
metricsEnabled flag to TcpCommunicationSpi.

On Mon, Jan 27, 2020 at 9:17 PM Nikolay Izhikov  wrote:
>
> Andrey.
>
> > "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
>
> Please, clarify, what do you mean by «doesn’t work»?
> Are there any unresolved bugs?
>
> > IGINTE-12576 affects it minimally
>
> All I asking for is to confirm this statement with the benchmark results.
>
> > User can disable metrics if it will affect performance.
>
> Users can’t disable TcpCommunicationListener nor in any release nor in 
> current master so we should change this code carefully
>
> https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L1178
>
> > 27 янв. 2020 г., в 20:40, Andrey Gura  написал(а):
> >
> > Nikolay,
> >
> >> But, we must gather yardstick benchmark results for PR(comparing to 
> >> current master) before merge to ensure there is no performance drop.
> >
> > "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> >
> > I believe that benchmarks ignite-2.7.6 vs ignite-2.8 will show
> > noticeable drop in performance for ignite-2.8. But it is cumulative
> > effect and IGINTE-12576 affects it minimally.
> >
> >> Note, that these metrics updated on each communication message.
> >
> > Metrics are not free at all. User can disable metrics if it will
> > affect performance.
> >
> > On Mon, Jan 27, 2020 at 8:23 PM Nikolay Izhikov  wrote:
> >>
> >> Hello, Andrey.
> >>
> >> I’m OK to include these changes to 2.8.
> >> I don’t review PR, but the ticket description makes sense to me.
> >>
> >> But, we must gather yardstick benchmark results for PR(comparing to 
> >> current master) before merge to ensure there is no performance drop.
> >> Note, that these metrics updated on each communication message.
> >>
> >>> 27 янв. 2020 г., в 18:19, Andrey Gura  написал(а):
> >>>
> >>> Igniters,
> >>>
> >>> I want to add one more issue to the Apache Ignite 2.8 release scope [1].
> >>>
> >>> The problem is impossibility of using communication metrics gathered
> >>> for nodes in the cluster because node ID will changed in case of
> >>> restart. Obvious solution is using consistent ID instead of node ID.
> >>>
> >>> PR is already implemented and ready for review.
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-12576
> >>>
> >>> On Fri, Jan 24, 2020 at 4:06 PM Maxim Muzafarov  wrote:
> 
>  Folks,
> 
> 
>  I've cherry-picked these issues [1] [2] to the 2.8 release branch.
> 
> 
>  [1] https://issues.apache.org/jira/browse/IGNITE-12540
>  Update versions of vulnerable dependencies
> 
>  [2] https://issues.apache.org/jira/browse/IGNITE-12486
>  Truncation of archived WAL segments doesn't work
> 
>  On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  
>  wrote:
> >
> > Hi igniters,
> >
> > there's a potential data corruption fix that I'd like you to include in 
> > the
> > next release:
> > https://issues.apache.org/jira/browse/IGNITE-12486https://issues.apache.org/jira/browse/IGNITE-12486
> > 
> >
> > Can you please cherry-pick it? Thank you!
> >
> > ср, 22 янв. 2020 г. в 17:45, Pavel Tupitsyn :
> >
> >> Good idea about pre-release build of ignite-2.8 branch.
> >> However, I would not name it `rc`, since it is not really a release
> >> candidate. Make it `pre0` or something like that.
> >>
> >> For Ignite.NET I've uploaded pre-release NuGet packages built from 
> >> current
> >> ignite-2.8 branch:
> >> https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20200122
> >>
> >>
> >> On Wed, Jan 22, 2020 at 3:09 PM Ilya Kasnacheev 
> >>  >>>
> >> wrote:
> >>
> >>> Hello!
> >>>
> >>> I have committed the bumping of essential dependencies' versions:
> >>> https://issues.apache.org/jira/browse/IGNITE-12540
> >>>
> >>> Would you mind including this change into the scope of 2.8? No point 
> >>> of
> >>> shipping known problematic JARs in our deliverable.
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> ср, 22 янв. 2020 г. в 14:00, Maxim Muzafarov :
> >>>
>  Alexey,
> 
>  Sure, I've just thought about it too a few days ago.
> 
> 

[jira] [Created] (IGNITE-12586) Calcite integration. NodesMapping simplification.

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12586:
-

 Summary: Calcite integration. NodesMapping simplification.
 Key: IGNITE-12586
 URL: https://issues.apache.org/jira/browse/IGNITE-12586
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Seliverstov


Seems turning {{List assignments}} to {{Map 
assignments}} may significantly reduce occupied memory.



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

[jira] [Created] (IGNITE-12585) Calcite integration. Splitter improvements.

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12585:
-

 Summary: Calcite integration. Splitter improvements.
 Key: IGNITE-12585
 URL: https://issues.apache.org/jira/browse/IGNITE-12585
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Seliverstov


Currently in case a head fragment of a query plan have broadcast distribution 
it causes OptimisticPlanningException and additional fragment split each time 
it's mapped on topology on a client node. Seems it's quite usual case, so, we 
should cover it properly.



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

Re: [ANNOUNCE] New Apache Ignite PMC member: Igor Sapego

[Denis Magda]

Igor, thanks for being an invaluable member of the community all this time!
Congrats!

-
Denis


On Sun, Jan 26, 2020 at 9:58 PM Ivan Pavlukhin  wrote:

> Hello Ignite Community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Igor Sapego to join the PMC as a new member and we are pleased to
> announce that he has accepted.
>
> Igor is an active Community member for a long time. He made a
> worthless contribution in Ignite C++ development and continues to do
> it today. Moreover he drives thin clients development for other
> programming languages. Additionally, always helpful on users mailing
> list. Wrote blog posts and spoke publicly about Ignite.
>
> Being a PMC member enables assistance with the management and to guide
> the direction of the project.
>
> Please join me in congratulating Igor!
>
> Best regards,
> Ivan Pavlukhin
> on behalf of Apache Ignite PMC
>

Re: Apache Ignite contribution

[Denis Magda]

Folks,

We had this discussion about communication channels before and summarized
it on this wiki:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Collaborate

Dev list is a preferred channel but we're free to go to Slack or Telegram
(mention it there if you'd like) on some occasions.

-
Denis


On Mon, Jan 27, 2020 at 5:43 AM Alexey Zinoviev 
wrote:

> Of course, telegram/slack and etc are indexed by google and results
> couldn't be found there, but we should provide more options for onboarding
> for newcomers and share knowledge and help for them.
> I suggest to use official ASF slack for simple questions about development
> and asking help.
> The current telegram channel works as a fast user-list or stack-overflow.
> This is developer-user communication, not the right place to discuss
> developer deals.
>
> I'll suggest to add this links with explanation for newcomers (not only
> "how to contribute" but and "where to ask" and "who could help me with this
> task")
>
>
>
>
>
> пн, 27 янв. 2020 г. в 15:17, Ivan Pavlukhin :
>
> > I beleive that dev list should be the only mean of (technical)
> > decision making for the project.
> >
> > But other resources can show better productivity and especially for
> > newcomers. And I am little bit worried that means of communication
> > seems a little bit scattered. I will try telegram =)
> >
> > пн, 27 янв. 2020 г. в 14:57, Dmitriy Pavlov :
> > >
> > > Hi Igniters,
> > >
> > > I would name dev list as the only one official channel. Other options
> are
> > > supplementary channels just for convenience (Slack for voice calls &
> > chats,
> > > Russian local resources for easier communication without foreign
> language
> > > barrier). But still, I hope we're on the same page that
> > > _If it didn't happen on the list, it didn't happen._
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 27 янв. 2020 г. в 12:24, Alexey Zinoviev :
> > >
> > > > And dont forget asf slack with a few channel about Apache ignite
> > > >
> > > > пн, 27 янв. 2020 г., 12:20 Ivan Pavlukhin :
> > > >
> > > > > Maksim, folks,
> > > > >
> > > > > Actually I am curious what kind of communication channel is
> mentioned
> > > > > telegram channel? Should we add a link to it on official "community
> > > > > resources" page?
> > > > >
> > > > > пн, 27 янв. 2020 г. в 11:40, Maksim Stepachev <
> > > > maksim.stepac...@gmail.com
> > > > > >:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > If you have the telegram, join to Russian channel:
> > > > > https://t.me/RU_Ignite
> > > > > >
> > > > > > чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > I have added you to Contributors of our project, you can now
> > assign
> > > > > issues
> > > > > > > to yourself.
> > > > > > >
> > > > > > > Please read
> > > > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > чт, 23 янв. 2020 г. в 15:31, Лев Киселев <
> > lev.kiselev.1...@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > > I want to take part in the development of Apache Ignite.
> > > > > > > > Primary skills: Java SE, Java 8, Spring framework, SQL.
> > > > > > > > Also: Multithreading (incl. FJP), Design Patterns, Algorithms
> > and
> > > > > Data
> > > > > > > > Structures.
> > > > > > > >
> > > > > > > > My JIRA ID: l4ndsc4pe
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

Andrey.

> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)

Please, clarify, what do you mean by «doesn’t work»?
Are there any unresolved bugs?

> IGINTE-12576 affects it minimally

All I asking for is to confirm this statement with the benchmark results.

> User can disable metrics if it will affect performance.

Users can’t disable TcpCommunicationListener nor in any release nor in current 
master so we should change this code carefully

https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L1178

> 27 янв. 2020 г., в 20:40, Andrey Gura  написал(а):
> 
> Nikolay,
> 
>> But, we must gather yardstick benchmark results for PR(comparing to current 
>> master) before merge to ensure there is no performance drop.
> 
> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> 
> I believe that benchmarks ignite-2.7.6 vs ignite-2.8 will show
> noticeable drop in performance for ignite-2.8. But it is cumulative
> effect and IGINTE-12576 affects it minimally.
> 
>> Note, that these metrics updated on each communication message.
> 
> Metrics are not free at all. User can disable metrics if it will
> affect performance.
> 
> On Mon, Jan 27, 2020 at 8:23 PM Nikolay Izhikov  wrote:
>> 
>> Hello, Andrey.
>> 
>> I’m OK to include these changes to 2.8.
>> I don’t review PR, but the ticket description makes sense to me.
>> 
>> But, we must gather yardstick benchmark results for PR(comparing to current 
>> master) before merge to ensure there is no performance drop.
>> Note, that these metrics updated on each communication message.
>> 
>>> 27 янв. 2020 г., в 18:19, Andrey Gura  написал(а):
>>> 
>>> Igniters,
>>> 
>>> I want to add one more issue to the Apache Ignite 2.8 release scope [1].
>>> 
>>> The problem is impossibility of using communication metrics gathered
>>> for nodes in the cluster because node ID will changed in case of
>>> restart. Obvious solution is using consistent ID instead of node ID.
>>> 
>>> PR is already implemented and ready for review.
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-12576
>>> 
>>> On Fri, Jan 24, 2020 at 4:06 PM Maxim Muzafarov  wrote:
 
 Folks,
 
 
 I've cherry-picked these issues [1] [2] to the 2.8 release branch.
 
 
 [1] https://issues.apache.org/jira/browse/IGNITE-12540
 Update versions of vulnerable dependencies
 
 [2] https://issues.apache.org/jira/browse/IGNITE-12486
 Truncation of archived WAL segments doesn't work
 
 On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  wrote:
> 
> Hi igniters,
> 
> there's a potential data corruption fix that I'd like you to include in 
> the
> next release:
> https://issues.apache.org/jira/browse/IGNITE-12486https://issues.apache.org/jira/browse/IGNITE-12486
> 
> 
> Can you please cherry-pick it? Thank you!
> 
> ср, 22 янв. 2020 г. в 17:45, Pavel Tupitsyn :
> 
>> Good idea about pre-release build of ignite-2.8 branch.
>> However, I would not name it `rc`, since it is not really a release
>> candidate. Make it `pre0` or something like that.
>> 
>> For Ignite.NET I've uploaded pre-release NuGet packages built from 
>> current
>> ignite-2.8 branch:
>> https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20200122
>> 
>> 
>> On Wed, Jan 22, 2020 at 3:09 PM Ilya Kasnacheev 
>> >> 
>> wrote:
>> 
>>> Hello!
>>> 
>>> I have committed the bumping of essential dependencies' versions:
>>> https://issues.apache.org/jira/browse/IGNITE-12540
>>> 
>>> Would you mind including this change into the scope of 2.8? No point of
>>> shipping known problematic JARs in our deliverable.
>>> 
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>> 
>>> 
>>> ср, 22 янв. 2020 г. в 14:00, Maxim Muzafarov :
>>> 
 Alexey,
 
 Sure, I've just thought about it too a few days ago.
 
 On Wed, 22 Jan 2020 at 12:09, Anton Vinogradov  wrote:
> 
> Good Idea, this will also check that the release process is alive.
> 
> On Wed, Jan 22, 2020 at 12:04 PM Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
> 
>> Folks, Maxim,
>> 
>> Do you mind if I build the current state of ignite-2.8 branch and
 upload a
>> maven staging as rc0 (step 4.3.2 of the release process)? I want
>> run
 some
>> tests for the fixes that are already included to the branch.
>> 
>> вт, 21 янв. 2020 г. в 14:28, Maxim Muzafarov :
>> 
>>> Folks,
>>> 
>>> 
>>> I think both of these issues [1] [2] are critical to 2.8 release
>>> and
>>> we must include them.
>>> 
>>> [1] 

Re: Slim binary release and docker image for Apache Ignite

[Denis Magda]

Alex, could you please list all the modules that will be excluded? It will
help to confirm we haven't dumped anything essential.

-
Denis


On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Got it, sounds good!
> Should we consider the list of modules included in the slim package
> finalized?
>
> чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
>
> > Alexey, if I understand correctly, Ilya does not suggest to pre-built
> > binaries, just to ship it with configure script pre-generated, which
> > is a common practice for autotools packages. Building will be still
> > required for the user, but there will be less requirements and
> > possible errors during build.
> >
> > I like the idea. Let's do this.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I
> would
> > > not name it 'core' because indeed it would be confusing with the core
> > > module name.
> > >
> > > Agree that platforms support is useful, so I would keep them as Ilya
> > > suggested. As for the C++ packages pre-build - let's hear out Igor's
> > > opinion on this. Pre-built binaries certainly add usability, but I am
> not
> > > sure how those binaries should be tested afterwards.
> > >
> > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov :
> > >
> > > > I'm +1 for "SLIM" it is a common name in Docker world.
> > > >
> > > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov 
> > wrote:
> > > >
> > > > > +1 for slim binary
> > > > > Plus docker-slim
> > > > > Plus RPM / DEB packages modularisation like PHP distribution — with
> > > core
> > > > > and lots of integrations / modules.
> > > > >
> > > > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I think we should name it "core" since we already have
> ignite-core
> > > and
> > > > it
> > > > > > will be confusing. Maybe we should go full 00s and call it
> "lite"?
> > > > > >
> > > > > > I also think we should keep both .Net and C++. .Net is runnable
> out
> > > of
> > > > > box
> > > > > > which is awesome, and C++ needs building but it is rather small
> in
> > > > source
> > > > > > form.
> > > > > >
> > > > > > I also suggest a different change to build process. Let's ship
> C++
> > > with
> > > > > > automake, etc, already run, for all binary packaging options?
> > WDYT? I
> > > > can
> > > > > > assist in build process tuning.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> > > > > >
> > > > > >> Alex,
> > > > > >>
> > > > > >> I'm on your end and support the proposal. Could you also clarify
> > if
> > > > you
> > > > > >> suggest we keeping or removing C++ and .NET thick clients?
> > > > > >>
> > > > > >> Speaking of the naming, how about titling such packages as
> 'core'
> > > > > instead
> > > > > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > > > > >>
> > > > > >>
> > > > > >> -
> > > > > >> Denis
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > > > > ilya.kasnach...@gmail.com
> > > > > >>>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Hello!
> > > > > >>>
> > > > > >>> Pavel, I believe these JARs are fully covered by the list of
> > > modules
> > > > > >>> specified above.
> > > > > >>>
> > > > > >>> Regards,
> > > > > >>> --
> > > > > >>> Ilya Kasnacheev
> > > > > >>>
> > > > > >>>
> > > > > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >:
> > > > > >>>
> > > > >  I like the idea, current distribution is certainly too big.
> > > > > 
> > > > >  Here is a list of jar files we include in NuGet package:
> > > > > 
> > > > >  cache-api-1.0.0.jar
> > > > >  commons-codec-1.11.jar
> > > > >  commons-logging-1.1.1.jar
> > > > >  h2-1.4.197.jar
> > > > >  ignite-core-2.9.0-SNAPSHOT.jar
> > > > >  ignite-indexing-2.9.0-SNAPSHOT.jar
> > > > >  ignite-shmem-1.0.0.jar
> > > > >  ignite-spring-2.9.0-SNAPSHOT.jar
> > > > >  lucene-analyzers-common-7.4.0.jar
> > > > >  lucene-core-7.4.0.jar
> > > > >  lucene-queryparser-7.4.0.jar
> > > > >  spring-aop-4.3.18.RELEASE.jar
> > > > >  spring-beans-4.3.18.RELEASE.jar
> > > > >  spring-context-4.3.18.RELEASE.jar
> > > > >  spring-core-4.3.18.RELEASE.jar
> > > > >  spring-expression-4.3.18.RELEASE.jar
> > > > >  spring-jdbc-4.3.18.RELEASE.jar
> > > > >  spring-tx-4.3.18.RELEASE.jar
> > > > > 
> > > > >  Those are required for SQL and Spring configs to work
> properly,
> > > > >  maybe we want to include them into the slim distro as well.
> > > > > 
> > > > >  On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > > > > >>> ilya.kasnach...@gmail.com
> > > > > >
> 

Re: AWS EBS Discovery: Contributor Wanted

[Denis Magda]

I support the idea of triggering such tests on demand. We can create a wiki
page with instructions on how to run the tests. Unless there is a more
elegant solution.

Sergey, would you be able to review Emmanouil's changes in the IP Finder
source code?
https://issues.apache.org/jira/browse/IGNITE-8617

-
Denis


On Sun, Jan 26, 2020 at 2:22 AM Emmanouil Gkatziouras 
wrote:

> Hi all!
>
> I do believe being able to execute some AWS integration tests on demand
> would be of value, especially for reviewers who cannot have an AWS stack
> created on demand.
> More than happy to help on that.
>
> Kind regards
> *Emmanouil Gkatziouras*
> https://egkatzioura.com/ |
> https://www.linkedin.com/in/gkatziourasemmanouil/
> https://github.com/gkatzioura
>
>
> On Fri, 24 Jan 2020 at 15:15, Sergey Chugunov 
> wrote:
>
> > Hello Emmanouil,
> >
> > It would be great if we have at least basic integration tests in real AWS
> > environment. Even though they may require more work to keep them green (I
> > mean here AWS quotas and additional configuration/reconfiguration
> efforts)
> > it worth it because these tests can also be useful as an examples.
> >
> > As the same time as IpFinder is such a basic component I don't think we
> > need to include them in constantly triggered suites like Run All but to
> > trigger them manually before/right after merging them to master branch or
> > when developing something in related code.
> >
> > What do you think?
> >
> > --
> > Thank you,
> > Sergey Chugunov.
> >
> > On Thu, Jan 23, 2020 at 5:32 PM Emmanouil Gkatziouras <
> > gkatzio...@gmail.com>
> > wrote:
> >
> > > Hi all!
> > >
> > > Yes It seems possible to get some free quota for integration tests on
> AWS
> > > [1] however most probably they are not gonna last forever.
> > >
> > > [1]
> > >
> > >
> >
> https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
> > >
> > > King Regards
> > > *Emmanouil Gkatziouras*
> > > https://egkatzioura.com/ |
> > > https://www.linkedin.com/in/gkatziourasemmanouil/
> > > https://github.com/gkatzioura
> > >
> > >
> > > On Wed, 22 Jan 2020 at 16:48, Denis Magda  wrote:
> > >
> > > > Hi Emmanouil,
> > > >
> > > > Thanks for preparing a pull-request for Application Load Balancer:
> > > > https://issues.apache.org/jira/browse/IGNITE-8617
> > > >
> > > > Igniters, who is willing to step in as a primary reviewer?
> > > >
> > > > As for automated testing on AWS, are you aware of any sponsorship
> > program
> > > > of AWS for open source projects of our kind? It will be ideal to have
> > > real
> > > > testing on AWS but someone needs to pay.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Sun, Jan 19, 2020 at 6:45 AM Emmanouil Gkatziouras <
> > > > gkatzio...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi all!
> > > > >
> > > > > I have spinned up an Application Load Balancer and an autoscaling
> > group
> > > > on
> > > > > AWS and the Ignite discovery using TcpDiscoveryAlbIpFinder works as
> > > > > expected.
> > > > >
> > > > >- On startup nodes discover each other.
> > > > >- On ec2 node down, connection is lost and the cluster
> decreases.
> > > > >- On an extra node addition the cluster size increases
> > > > >
> > > > > This contribution is essential since the Previous ELB based
> discovery
> > > > uses
> > > > > the Classic Load Balancer which is still available however
> > > > > AWS advices users to use the Application one. [1]
> > > > > While my pull request gets reviewed I will also have a look at
> > > > > the IGNITE-12398 [2] issue which has to do with the S3 discovery.
> > > > > Another idea would also be to implement a `TCP Load Balancer based`
> > > > > discovery.
> > > > >
> > > > > In order to test this issue and future ones I implemented some
> > > terraform
> > > > > scripts (which I shall use for other issues too) [3].
> > > > > If some automated e2e testing on AWS is being considered they might
> > be
> > > of
> > > > > value.
> > > > > I can help on implementing those tests by provisioning the
> > > infrastructure
> > > > > in an automated way and validate the discovery.
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-to-application-load-balancer.html
> > > > > [2] https://issues.apache.org/jira/browse/IGNITE-12398
> > > > > [3] https://github.com/gkatzioura/ignite-aws-deploy
> > > > >
> > > > > Kind regards,
> > > > > *Emmanouil Gkatziouras*
> > > > > https://egkatzioura.com/ |
> > > > > https://www.linkedin.com/in/gkatziourasemmanouil/
> > > > > https://github.com/gkatzioura
> > > > >
> > > > >
> > > > > On Tue, 14 Jan 2020 at 22:22, Denis Magda 
> wrote:
> > > > >
> > > > > > Hi Emmanouil,
> > > > > >
> > > > > > Agree, let's check that the IP finder functions normally in the
> > cloud
> > > > > > environment and the mock tests can be used for regular testing on
> > > Team
> > > > > > City. That's the way we tested other 

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Andrey Gura]

Nikolay,

> But, we must gather yardstick benchmark results for PR(comparing to current 
> master) before merge to ensure there is no performance drop.

"If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)

I believe that benchmarks ignite-2.7.6 vs ignite-2.8 will show
noticeable drop in performance for ignite-2.8. But it is cumulative
effect and IGINTE-12576 affects it minimally.

> Note, that these metrics updated on each communication message.

Metrics are not free at all. User can disable metrics if it will
affect performance.

On Mon, Jan 27, 2020 at 8:23 PM Nikolay Izhikov  wrote:
>
> Hello, Andrey.
>
> I’m OK to include these changes to 2.8.
> I don’t review PR, but the ticket description makes sense to me.
>
> But, we must gather yardstick benchmark results for PR(comparing to current 
> master) before merge to ensure there is no performance drop.
> Note, that these metrics updated on each communication message.
>
> > 27 янв. 2020 г., в 18:19, Andrey Gura  написал(а):
> >
> > Igniters,
> >
> > I want to add one more issue to the Apache Ignite 2.8 release scope [1].
> >
> > The problem is impossibility of using communication metrics gathered
> > for nodes in the cluster because node ID will changed in case of
> > restart. Obvious solution is using consistent ID instead of node ID.
> >
> > PR is already implemented and ready for review.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12576
> >
> > On Fri, Jan 24, 2020 at 4:06 PM Maxim Muzafarov  wrote:
> >>
> >> Folks,
> >>
> >>
> >> I've cherry-picked these issues [1] [2] to the 2.8 release branch.
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12540
> >> Update versions of vulnerable dependencies
> >>
> >> [2] https://issues.apache.org/jira/browse/IGNITE-12486
> >> Truncation of archived WAL segments doesn't work
> >>
> >> On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  wrote:
> >>>
> >>> Hi igniters,
> >>>
> >>> there's a potential data corruption fix that I'd like you to include in 
> >>> the
> >>> next release:
> >>> https://issues.apache.org/jira/browse/IGNITE-12486https://issues.apache.org/jira/browse/IGNITE-12486
> >>> 
> >>>
> >>> Can you please cherry-pick it? Thank you!
> >>>
> >>> ср, 22 янв. 2020 г. в 17:45, Pavel Tupitsyn :
> >>>
>  Good idea about pre-release build of ignite-2.8 branch.
>  However, I would not name it `rc`, since it is not really a release
>  candidate. Make it `pre0` or something like that.
> 
>  For Ignite.NET I've uploaded pre-release NuGet packages built from 
>  current
>  ignite-2.8 branch:
>  https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20200122
> 
> 
>  On Wed, Jan 22, 2020 at 3:09 PM Ilya Kasnacheev 
>   >
>  wrote:
> 
> > Hello!
> >
> > I have committed the bumping of essential dependencies' versions:
> > https://issues.apache.org/jira/browse/IGNITE-12540
> >
> > Would you mind including this change into the scope of 2.8? No point of
> > shipping known problematic JARs in our deliverable.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 22 янв. 2020 г. в 14:00, Maxim Muzafarov :
> >
> >> Alexey,
> >>
> >> Sure, I've just thought about it too a few days ago.
> >>
> >> On Wed, 22 Jan 2020 at 12:09, Anton Vinogradov  wrote:
> >>>
> >>> Good Idea, this will also check that the release process is alive.
> >>>
> >>> On Wed, Jan 22, 2020 at 12:04 PM Alexey Goncharuk <
> >>> alexey.goncha...@gmail.com> wrote:
> >>>
>  Folks, Maxim,
> 
>  Do you mind if I build the current state of ignite-2.8 branch and
> >> upload a
>  maven staging as rc0 (step 4.3.2 of the release process)? I want
>  run
> >> some
>  tests for the fixes that are already included to the branch.
> 
>  вт, 21 янв. 2020 г. в 14:28, Maxim Muzafarov :
> 
> > Folks,
> >
> >
> > I think both of these issues [1] [2] are critical to 2.8 release
> > and
> > we must include them.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12547
> > Excessive AtomicLong instantiations lead to GC pressure.
> >
> > [2] https://issues.apache.org/jira/browse/IGNITE-12530
> > Pages list caching can cause IgniteOOME when the checkpoint is
> > triggered by "too many dirty pages" reason.
> >
> >
> > On Mon, 20 Jan 2020 at 19:00, Alex Plehanov <
> > plehanov.a...@gmail.com
> >>>
> > wrote:
> >>
> >> Guys,
> >>
> >> There is an issue [1] caused by page list caching [2], which
>  also
>  affects
> >> 2.8 release. IgniteOutOfMemoryException can be thrown in some
> > cases
>  (data
> >> region is small, a checkpoint is 

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

Hello, Andrey.

I’m OK to include these changes to 2.8.
I don’t review PR, but the ticket description makes sense to me.

But, we must gather yardstick benchmark results for PR(comparing to current 
master) before merge to ensure there is no performance drop.
Note, that these metrics updated on each communication message.

> 27 янв. 2020 г., в 18:19, Andrey Gura  написал(а):
> 
> Igniters,
> 
> I want to add one more issue to the Apache Ignite 2.8 release scope [1].
> 
> The problem is impossibility of using communication metrics gathered
> for nodes in the cluster because node ID will changed in case of
> restart. Obvious solution is using consistent ID instead of node ID.
> 
> PR is already implemented and ready for review.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-12576
> 
> On Fri, Jan 24, 2020 at 4:06 PM Maxim Muzafarov  wrote:
>> 
>> Folks,
>> 
>> 
>> I've cherry-picked these issues [1] [2] to the 2.8 release branch.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-12540
>> Update versions of vulnerable dependencies
>> 
>> [2] https://issues.apache.org/jira/browse/IGNITE-12486
>> Truncation of archived WAL segments doesn't work
>> 
>> On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  wrote:
>>> 
>>> Hi igniters,
>>> 
>>> there's a potential data corruption fix that I'd like you to include in the
>>> next release:
>>> https://issues.apache.org/jira/browse/IGNITE-12486https://issues.apache.org/jira/browse/IGNITE-12486
>>> 
>>> 
>>> Can you please cherry-pick it? Thank you!
>>> 
>>> ср, 22 янв. 2020 г. в 17:45, Pavel Tupitsyn :
>>> 
 Good idea about pre-release build of ignite-2.8 branch.
 However, I would not name it `rc`, since it is not really a release
 candidate. Make it `pre0` or something like that.
 
 For Ignite.NET I've uploaded pre-release NuGet packages built from current
 ignite-2.8 branch:
 https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20200122
 
 
 On Wed, Jan 22, 2020 at 3:09 PM Ilya Kasnacheev  
 wrote:
 
> Hello!
> 
> I have committed the bumping of essential dependencies' versions:
> https://issues.apache.org/jira/browse/IGNITE-12540
> 
> Would you mind including this change into the scope of 2.8? No point of
> shipping known problematic JARs in our deliverable.
> 
> Regards,
> --
> Ilya Kasnacheev
> 
> 
> ср, 22 янв. 2020 г. в 14:00, Maxim Muzafarov :
> 
>> Alexey,
>> 
>> Sure, I've just thought about it too a few days ago.
>> 
>> On Wed, 22 Jan 2020 at 12:09, Anton Vinogradov  wrote:
>>> 
>>> Good Idea, this will also check that the release process is alive.
>>> 
>>> On Wed, Jan 22, 2020 at 12:04 PM Alexey Goncharuk <
>>> alexey.goncha...@gmail.com> wrote:
>>> 
 Folks, Maxim,
 
 Do you mind if I build the current state of ignite-2.8 branch and
>> upload a
 maven staging as rc0 (step 4.3.2 of the release process)? I want
 run
>> some
 tests for the fixes that are already included to the branch.
 
 вт, 21 янв. 2020 г. в 14:28, Maxim Muzafarov :
 
> Folks,
> 
> 
> I think both of these issues [1] [2] are critical to 2.8 release
> and
> we must include them.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-12547
> Excessive AtomicLong instantiations lead to GC pressure.
> 
> [2] https://issues.apache.org/jira/browse/IGNITE-12530
> Pages list caching can cause IgniteOOME when the checkpoint is
> triggered by "too many dirty pages" reason.
> 
> 
> On Mon, 20 Jan 2020 at 19:00, Alex Plehanov <
> plehanov.a...@gmail.com
>>> 
> wrote:
>> 
>> Guys,
>> 
>> There is an issue [1] caused by page list caching [2], which
 also
 affects
>> 2.8 release. IgniteOutOfMemoryException can be thrown in some
> cases
 (data
>> region is small, a checkpoint is triggered by "too many dirty
>> pages"
> reason
>> and pages list cache is rather big).
>> The fix is ready and merged to master, I suggest to include
 this
>> fix to
> 2.8
>> release. What do you think?
>> 
>> [1]: https://issues.apache.org/jira/browse/IGNITE-12530
>> [2]: https://issues.apache.org/jira/browse/IGNITE-6930
>> 
>> пн, 20 янв. 2020 г. в 12:57, Alexey Goncharuk <
> alexey.goncha...@gmail.com>:
>> 
>>> Maxim,
>>> 
>>> I took a quick look at IGNITE-12456 and I am not sure it's
> about
>> data
>>> corruption. In the attached logs blocked system threads are
>> reported,
>>> however, there is no enough information to investigate the
> issue
>> (the
> 

Re: [ANNOUNCE] New Apache Ignite PMC member: Igor Sapego

[Alexey Zinoviev]

Great, congrats!

пн, 27 янв. 2020 г. в 19:03, Kseniya Romanova :

> My congratulations!
>
> пн, 27 янв. 2020 г. в 14:53, Dmitriy Pavlov :
>
> > Hi Igor,
> >
> > congrats with new role.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 27 янв. 2020 г. в 12:51, Petr Ivanov :
> >
> > > Congratulations, Igor.
> > >
> > > Well deserved!
> > >
> > >
> > > > On 27 Jan 2020, at 08:57, Ivan Pavlukhin 
> wrote:
> > > >
> > > > Hello Ignite Community,
> > > >
> > > > The Project Management Committee (PMC) for Apache Ignite has invited
> > > > Igor Sapego to join the PMC as a new member and we are pleased to
> > > > announce that he has accepted.
> > > >
> > > > Igor is an active Community member for a long time. He made a
> > > > worthless contribution in Ignite C++ development and continues to do
> > > > it today. Moreover he drives thin clients development for other
> > > > programming languages. Additionally, always helpful on users mailing
> > > > list. Wrote blog posts and spoke publicly about Ignite.
> > > >
> > > > Being a PMC member enables assistance with the management and to
> guide
> > > > the direction of the project.
> > > >
> > > > Please join me in congratulating Igor!
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > > on behalf of Apache Ignite PMC
> > >
> > >
> >
>

Re: [ANNOUNCE] New Apache Ignite PMC member: Igor Sapego

[Kseniya Romanova]

My congratulations!

пн, 27 янв. 2020 г. в 14:53, Dmitriy Pavlov :

> Hi Igor,
>
> congrats with new role.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 27 янв. 2020 г. в 12:51, Petr Ivanov :
>
> > Congratulations, Igor.
> >
> > Well deserved!
> >
> >
> > > On 27 Jan 2020, at 08:57, Ivan Pavlukhin  wrote:
> > >
> > > Hello Ignite Community,
> > >
> > > The Project Management Committee (PMC) for Apache Ignite has invited
> > > Igor Sapego to join the PMC as a new member and we are pleased to
> > > announce that he has accepted.
> > >
> > > Igor is an active Community member for a long time. He made a
> > > worthless contribution in Ignite C++ development and continues to do
> > > it today. Moreover he drives thin clients development for other
> > > programming languages. Additionally, always helpful on users mailing
> > > list. Wrote blog posts and spoke publicly about Ignite.
> > >
> > > Being a PMC member enables assistance with the management and to guide
> > > the direction of the project.
> > >
> > > Please join me in congratulating Igor!
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > > on behalf of Apache Ignite PMC
> >
> >
>

[MEETUP] Seattle Meetup in March

[Kseniya Romanova]

Hi Igniters! GridGain wants to start IMC meetup in Seattle[1] and the first
session can be as soon as in March.

Do we have here someone from Seattle? It would be cool if you want to
present a talk about Apache Ignite - please use this IMC CFP form[2]. Or
maybe your company can host the session? Or you know a good place to make
an event in?

Any advice would be greatly appreciated!

Regards,
Kseniya

[1] https://www.meetup.com/seattle-imc-meetup/
[2]
https://docs.google.com/forms/d/e/1FAIpQLSdK-zqm8YWlPgpYHZjhJtmH_v3ZR3XKIAmkvvS1ZbwnPt1MWA/viewform

Re: Internal classes are exposed in public API

[Maxim Muzafarov]

Folks,


Will it be better to schedule an ASF Slack call to choose the best
option which we have? Since this discussion thread is valuable for 2.8
release and we do not have a strong consensus here.

How about 30-th January 16-00 MSK time?

On Mon, 27 Jan 2020 at 16:37, Nikolay Izhikov  wrote:
>
> > it's better to remove deprecation for the old APIs in AI 2.8
>
> Are you suggest to have 2 concurrent metrics implementations(both not 
> deprecated)?
>
> > Let's say I am writing a custom exporter in binary format and I need to 
> > write the number of exported metrics in a packet beforehand.
>
> This an `MetricExporterSPI` implementation task.
> Exporter has the listeners that can be used to track all registry events - 
> creation, removal
>
> > There is no separation on public and internal metrics
>
> I think we should write in the documentation that ANY metric can be changed.
> We will try to keep them, but if we found that some metric doesn’t required 
> any more or implemented in the wrong way - we can remove it.
>
> > Will we allow users to register their own metrics?
>
> No. Why we should considering this feature?
>
> > It's still not clear how a user will map old interfaces and methods to the 
> > new metric names.
>
> With the documentation.
> We can write separate deprecation comment for each metric providing method.
>
> > I just want to remove the deprecations on the classes for which there is no 
> > a well-defined replacement.
>
> Well-defined replacement for these classes exists.
>
> > 27 янв. 2020 г., в 16:21, Alexey Goncharuk  
> > написал(а):
> >
> > Nikolay,
> >
> > I've reviewed your changes and I tend to agree with Andrey, it's better to
> > remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
> > facade (IGNITE-12553) in a more calm and structured way. My observations on
> > the changes:
> >
> >   - I am not sure if Iterable would suffice both for the exporter and
> >   public APIs. Should we provide a way to know the number of metrics and
> >   registries in advance? Let's say I am writing a custom exporter in binary
> >   format and I need to write the number of exported metrics in a packet
> >   beforehand.
> >   - There is no separation on public and internal metrics, when public
> >   metrics preserve their name and semantics, and internal metrics may 
> > change.
> >   I remember we discussed this, but it's not reflected in the APIs in any 
> > way.
> >   - Will we allow users to register their own metrics? Again I remember we
> >   discussed a possibility for this. If so, why the registry is called
> >   'ReadyOnly'?
> >   - It's still not clear how a user will map old interfaces and methods to
> >   the new metric names.
> >
> > As you can see in the original message, I am not pushing for the new APIs
> > in the nearest release, I just want to remove the deprecations on the
> > classes for which there is no a well-defined replacement.
> >
> > пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov :
> >
> >> Folks,
> >>
> >>
> >> I'm sorry for not being too attentive to the whole thread discussion
> >> and maybe missing some details.
> >>
> >> But... who will perform the review of [1] issue?
> >> Will we merge it to 2.8? (hope so)
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> >> [IEP-35] public Java metric API
> >>
> >> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков  wrote:
> >>>
> >>> Andrey.
> >>>
> >>> With this API we are trying to fill the GAP Alexey pointed out at the
> >> start of this discussion.
> >>> I think it worth to be reviewed and merged.
> >>>
> >>> Can we, please, come back to the discussion of the changes itself?
> >>> I think API changes should be discussed in the other thread.
> >>>
>  Why do you think this is a wrong usage pattern? From the top of my
> >> head, here is a few cases of direct metric API usage that I know are
> >> currently being used in production:
>  * A custom task execution scheduling service with load balancing based
> >> on utilization metrics readings from Java code
>  * Cleanup task trigger based on metrics readings
>  * A custom health-check endpoint for an application with an embedded
> >> Ignite node for Kubernetes/Spring Application/etc
> >>>
> >>> [1] https://github.com/apache/ignite/pull/7283
> >>>
>  24 янв. 2020 г., в 18:08, Andrey Gura  написал(а):
> 
> > My point - that your contribution that took a long time, already,
> >> can’t be an argument to postpone creation of the API in the current 
> >> release.
> 
>  Argument is not about time. But about API which is known will be
> >> changed.
>  Second argument: why we should add this experimental API to the
>  already existing experimental API? Just to making API more
>  experimental? As I told already it is commit for commit and doesn't
>  bring any value but brings some inconvenience to me (e.g. merge
>  problems).
> 
>  BTW, does it exist issue about marking IEP-35 API's as 

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Andrey Gura]

Igniters,

I want to add one more issue to the Apache Ignite 2.8 release scope [1].

The problem is impossibility of using communication metrics gathered
for nodes in the cluster because node ID will changed in case of
restart. Obvious solution is using consistent ID instead of node ID.

PR is already implemented and ready for review.

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

On Fri, Jan 24, 2020 at 4:06 PM Maxim Muzafarov  wrote:
>
> Folks,
>
>
> I've cherry-picked these issues [1] [2] to the 2.8 release branch.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12540
> Update versions of vulnerable dependencies
>
> [2] https://issues.apache.org/jira/browse/IGNITE-12486
> Truncation of archived WAL segments doesn't work
>
> On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  wrote:
> >
> > Hi igniters,
> >
> > there's a potential data corruption fix that I'd like you to include in the
> > next release:
> > https://issues.apache.org/jira/browse/IGNITE-12486https://issues.apache.org/jira/browse/IGNITE-12486
> > 
> >
> > Can you please cherry-pick it? Thank you!
> >
> > ср, 22 янв. 2020 г. в 17:45, Pavel Tupitsyn :
> >
> > > Good idea about pre-release build of ignite-2.8 branch.
> > > However, I would not name it `rc`, since it is not really a release
> > > candidate. Make it `pre0` or something like that.
> > >
> > > For Ignite.NET I've uploaded pre-release NuGet packages built from current
> > > ignite-2.8 branch:
> > > https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20200122
> > >
> > >
> > > On Wed, Jan 22, 2020 at 3:09 PM Ilya Kasnacheev  > > >
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > I have committed the bumping of essential dependencies' versions:
> > > > https://issues.apache.org/jira/browse/IGNITE-12540
> > > >
> > > > Would you mind including this change into the scope of 2.8? No point of
> > > > shipping known problematic JARs in our deliverable.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 22 янв. 2020 г. в 14:00, Maxim Muzafarov :
> > > >
> > > > > Alexey,
> > > > >
> > > > > Sure, I've just thought about it too a few days ago.
> > > > >
> > > > > On Wed, 22 Jan 2020 at 12:09, Anton Vinogradov  
> > > > > wrote:
> > > > > >
> > > > > > Good Idea, this will also check that the release process is alive.
> > > > > >
> > > > > > On Wed, Jan 22, 2020 at 12:04 PM Alexey Goncharuk <
> > > > > > alexey.goncha...@gmail.com> wrote:
> > > > > >
> > > > > > > Folks, Maxim,
> > > > > > >
> > > > > > > Do you mind if I build the current state of ignite-2.8 branch and
> > > > > upload a
> > > > > > > maven staging as rc0 (step 4.3.2 of the release process)? I want
> > > run
> > > > > some
> > > > > > > tests for the fixes that are already included to the branch.
> > > > > > >
> > > > > > > вт, 21 янв. 2020 г. в 14:28, Maxim Muzafarov :
> > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > >
> > > > > > > > I think both of these issues [1] [2] are critical to 2.8 release
> > > > and
> > > > > > > > we must include them.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12547
> > > > > > > > Excessive AtomicLong instantiations lead to GC pressure.
> > > > > > > >
> > > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-12530
> > > > > > > > Pages list caching can cause IgniteOOME when the checkpoint is
> > > > > > > > triggered by "too many dirty pages" reason.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 20 Jan 2020 at 19:00, Alex Plehanov <
> > > > plehanov.a...@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Guys,
> > > > > > > > >
> > > > > > > > > There is an issue [1] caused by page list caching [2], which
> > > also
> > > > > > > affects
> > > > > > > > > 2.8 release. IgniteOutOfMemoryException can be thrown in some
> > > > cases
> > > > > > > (data
> > > > > > > > > region is small, a checkpoint is triggered by "too many dirty
> > > > > pages"
> > > > > > > > reason
> > > > > > > > > and pages list cache is rather big).
> > > > > > > > > The fix is ready and merged to master, I suggest to include
> > > this
> > > > > fix to
> > > > > > > > 2.8
> > > > > > > > > release. What do you think?
> > > > > > > > >
> > > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-12530
> > > > > > > > > [2]: https://issues.apache.org/jira/browse/IGNITE-6930
> > > > > > > > >
> > > > > > > > > пн, 20 янв. 2020 г. в 12:57, Alexey Goncharuk <
> > > > > > > > alexey.goncha...@gmail.com>:
> > > > > > > > >
> > > > > > > > > > Maxim,
> > > > > > > > > >
> > > > > > > > > > I took a quick look at IGNITE-12456 and I am not sure it's
> > > > about
> > > > > data
> > > > > > > > > > corruption. In the attached logs blocked system threads are
> > > > > reported,
> > > > > > > > > > however, there is no enough information to investigate the
> > > > issue
> > > > > (the
> > > > > > > > full
> > > > > > > > 

Re: [DISCUSS] Merge PR via GitHub web UI

[Pavel Tupitsyn]

INFRA ticket filed:
https://issues.apache.org/jira/browse/INFRA-19778

On Mon, Jan 27, 2020 at 4:38 PM Alexey Zinoviev 
wrote:

> I used squash for last two years, no problemo with that. Of course we
> should have 1 commit to 1 PR relationship, don't put all your commits to
> the table:)
>
> пн, 27 янв. 2020 г. в 15:50, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> >:
>
> > Petr Ivanov
> >
> > The script works great for me under windows.
> >
> > пн, 27 янв. 2020 г. в 15:33, Petr Ivanov :
> >
> > > Unfortunately, I have no power at Apache's GitHub repositories.
> > > Ticket for INFRA maybe the best way to solve the issue.
> > >
> > >
> > > > On 27 Jan 2020, at 15:23, Ivan Pavlukhin 
> wrote:
> > > >
> > > > But there is still the question how to configure it. Petr, can you
> > > > help here? Or somebody else? Or INFRA ticket should be created?
> > > >
> > > > пн, 27 янв. 2020 г. в 15:05, Dmitriy Pavlov :
> > > >>
> > > >> I always merge PRs from GitHub when possible. By doing it I can keep
> > my
> > > >> Git's local state unmodified.
> > > >>
> > > >> So I suggest using squash and merge.
> > > >>
> > > >> пн, 27 янв. 2020 г. в 14:59, Maxim Muzafarov :
> > > >>
> > > >>> +1 to keep only "squash" merge option
> > > >>>
> > > >>> On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn  >
> > > wrote:
> > > 
> > >  Merging from GitHub is very convenient indeed, much faster and
> safer
> > > than
> > >  anything else.
> > > 
> > >  And yes, GitHub provides a way to disable Merge and Rebase,
> leaving
> > > only
> > >  Squash option:
> > > 
> > > >>>
> > >
> >
> https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
> > > 
> > > 
> > >  However, I don't have access to the settings.
> > >  Peter, can you please change this setting for us?
> > > 
> > >  On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov 
> > > wrote:
> > > 
> > > > Iliya,
> > > >
> > > > How well does this script work under non-linux operations
> systems?
> > > >
> > > >
> > > >> On 27 Jan 2020, at 14:24, Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > 
> > > > wrote:
> > > >>
> > > >> Hello!
> > > >>
> > > >> I implore everybody to use scripts/apply-pull-request.sh, I
> never
> > > >>> had any
> > > >> problems with it. The only downside is that cherry-peek needs to
> > be
> > > > clean.
> > > >>
> > > >> Regards,
> > > >> --
> > > >> Ilya Kasnacheev
> > > >>
> > > >>
> > > >> пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin <
> vololo...@gmail.com
> > >:
> > > >>
> > > >>> Today I opened for myself a possibility to merge PR via GitHub.
> > And
> > > >>> GitHub allows 3 usual options to do a merge (merge commit,
> > rebase,
> > > >>> squash). And "merge commit" is a default option but an illegal
> > one
> > > >>> according to Apache Ignite usual practices.
> > > >>>
> > > >>> So, I wonder is it somehow possible to configure it to keep
> only
> > > >>> "squash" merge option?
> > > >>>
> > > >>> --
> > > >>> Best regards,
> > > >>> Ivan Pavlukhin
> > > >>>
> > > >
> > > >
> > > >>>
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > >
> > >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
> >
>

Re: Launched Ignite meetups and redesigned events pages

[Alexey Zinoviev]

Count me in!

пн, 27 янв. 2020 г. в 15:12, Dmitriy Pavlov :

> Hi Denis,
>
> yes, sorry for late reply, I just did double check that I can access
> answers. Additionally, Ksenia R. have access to proposals.
>
> Anyone from PMC who would like to volunteer and being PMC Representative
> for Apache Ignite Local meetups are always welcomed (according
> https://www.apache.org/foundation/marks/events  - The ASF events branding
> policy).
>
> Moreover, not-yet-PMC volunteers, who would help with talks preparation are
> also welcomed. I strongly believe we should not be too formal here.
>
> Sincerely,
> Dmitriy Pavlov
>
>
>
> чт, 9 янв. 2020 г. в 23:47, Denis Magda :
>
> > Dmitry,
> >
> > We've also added the reference to the form on the event's webpage. Btw,
> > could you remind me who will be receiving the proposals - you, I and some
> > other folks or all @dev list?
> >
> > -
> > Denis
> >
> >
> > On Thu, Jan 9, 2020 at 1:53 AM Dmitriy Pavlov 
> wrote:
> >
> >> Hi Igniters, Mauricio, Ignacio, and Denis,
> >>
> >> Thank you all for updating these pages.
> >>
> >> I would like to stress just one thing:
> >> should you have in mind some topic you can run talk about, please feel
> >> absolutely free to fill submission proposal.
> >>
> >> To submit proposal you need to fill in this form
> >>
> >>
> https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform
> >> .
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
> >>
> >> вт, 7 янв. 2020 г. в 02:48, Denis Magda :
> >>
> >> > Igniters,
> >> >
> >> > I've just merged changes contributed by Mauricio and Ignacio, who
> helped
> >> > us to prepare professional webpages for Ignite meetup groups around
> the
> >> > world [1] and for Ignite events [2]. Now you can easily enroll in a
> >> meetup
> >> > group nearby or sign up for an upcoming event to be hosted one of our
> >> > experts.
> >> >
> >> > Please check them out and share your feedback. In the meantime, three
> of
> >> > us are going to carry on with optimizations and changes making the
> >> website
> >> > more useful for developers as well as more searchable/discoverable
> from
> >> > various search engines.
> >> >
> >> > [1] https://ignite.apache.org/meetup-groups.html
> >> > [2] https://ignite.apache.org/events.html
> >> >
> >> > -
> >> > Denis
> >> >
> >>
> >
>

Re: Apache Ignite contribution

[Alexey Zinoviev]

Of course, telegram/slack and etc are indexed by google and results
couldn't be found there, but we should provide more options for onboarding
for newcomers and share knowledge and help for them.
I suggest to use official ASF slack for simple questions about development
and asking help.
The current telegram channel works as a fast user-list or stack-overflow.
This is developer-user communication, not the right place to discuss
developer deals.

I'll suggest to add this links with explanation for newcomers (not only
"how to contribute" but and "where to ask" and "who could help me with this
task")





пн, 27 янв. 2020 г. в 15:17, Ivan Pavlukhin :

> I beleive that dev list should be the only mean of (technical)
> decision making for the project.
>
> But other resources can show better productivity and especially for
> newcomers. And I am little bit worried that means of communication
> seems a little bit scattered. I will try telegram =)
>
> пн, 27 янв. 2020 г. в 14:57, Dmitriy Pavlov :
> >
> > Hi Igniters,
> >
> > I would name dev list as the only one official channel. Other options are
> > supplementary channels just for convenience (Slack for voice calls &
> chats,
> > Russian local resources for easier communication without foreign language
> > barrier). But still, I hope we're on the same page that
> > _If it didn't happen on the list, it didn't happen._
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 27 янв. 2020 г. в 12:24, Alexey Zinoviev :
> >
> > > And dont forget asf slack with a few channel about Apache ignite
> > >
> > > пн, 27 янв. 2020 г., 12:20 Ivan Pavlukhin :
> > >
> > > > Maksim, folks,
> > > >
> > > > Actually I am curious what kind of communication channel is mentioned
> > > > telegram channel? Should we add a link to it on official "community
> > > > resources" page?
> > > >
> > > > пн, 27 янв. 2020 г. в 11:40, Maksim Stepachev <
> > > maksim.stepac...@gmail.com
> > > > >:
> > > > >
> > > > > Hello!
> > > > >
> > > > > If you have the telegram, join to Russian channel:
> > > > https://t.me/RU_Ignite
> > > > >
> > > > > чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > > >:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I have added you to Contributors of our project, you can now
> assign
> > > > issues
> > > > > > to yourself.
> > > > > >
> > > > > > Please read
> > > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > чт, 23 янв. 2020 г. в 15:31, Лев Киселев <
> lev.kiselev.1...@gmail.com
> > > >:
> > > > > >
> > > > > > > Hello,
> > > > > > > I want to take part in the development of Apache Ignite.
> > > > > > > Primary skills: Java SE, Java 8, Spring framework, SQL.
> > > > > > > Also: Multithreading (incl. FJP), Design Patterns, Algorithms
> and
> > > > Data
> > > > > > > Structures.
> > > > > > >
> > > > > > > My JIRA ID: l4ndsc4pe
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: Internal classes are exposed in public API

[Nikolay Izhikov]

> it's better to remove deprecation for the old APIs in AI 2.8

Are you suggest to have 2 concurrent metrics implementations(both not 
deprecated)?

> Let's say I am writing a custom exporter in binary format and I need to write 
> the number of exported metrics in a packet beforehand.

This an `MetricExporterSPI` implementation task.
Exporter has the listeners that can be used to track all registry events - 
creation, removal

> There is no separation on public and internal metrics

I think we should write in the documentation that ANY metric can be changed.
We will try to keep them, but if we found that some metric doesn’t required any 
more or implemented in the wrong way - we can remove it.

> Will we allow users to register their own metrics?

No. Why we should considering this feature?

> It's still not clear how a user will map old interfaces and methods to the 
> new metric names.

With the documentation.
We can write separate deprecation comment for each metric providing method.

> I just want to remove the deprecations on the classes for which there is no a 
> well-defined replacement.

Well-defined replacement for these classes exists.

> 27 янв. 2020 г., в 16:21, Alexey Goncharuk  
> написал(а):
> 
> Nikolay,
> 
> I've reviewed your changes and I tend to agree with Andrey, it's better to
> remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
> facade (IGNITE-12553) in a more calm and structured way. My observations on
> the changes:
> 
>   - I am not sure if Iterable would suffice both for the exporter and
>   public APIs. Should we provide a way to know the number of metrics and
>   registries in advance? Let's say I am writing a custom exporter in binary
>   format and I need to write the number of exported metrics in a packet
>   beforehand.
>   - There is no separation on public and internal metrics, when public
>   metrics preserve their name and semantics, and internal metrics may change.
>   I remember we discussed this, but it's not reflected in the APIs in any way.
>   - Will we allow users to register their own metrics? Again I remember we
>   discussed a possibility for this. If so, why the registry is called
>   'ReadyOnly'?
>   - It's still not clear how a user will map old interfaces and methods to
>   the new metric names.
> 
> As you can see in the original message, I am not pushing for the new APIs
> in the nearest release, I just want to remove the deprecations on the
> classes for which there is no a well-defined replacement.
> 
> пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov :
> 
>> Folks,
>> 
>> 
>> I'm sorry for not being too attentive to the whole thread discussion
>> and maybe missing some details.
>> 
>> But... who will perform the review of [1] issue?
>> Will we merge it to 2.8? (hope so)
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-12553
>> [IEP-35] public Java metric API
>> 
>> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков  wrote:
>>> 
>>> Andrey.
>>> 
>>> With this API we are trying to fill the GAP Alexey pointed out at the
>> start of this discussion.
>>> I think it worth to be reviewed and merged.
>>> 
>>> Can we, please, come back to the discussion of the changes itself?
>>> I think API changes should be discussed in the other thread.
>>> 
 Why do you think this is a wrong usage pattern? From the top of my
>> head, here is a few cases of direct metric API usage that I know are
>> currently being used in production:
 * A custom task execution scheduling service with load balancing based
>> on utilization metrics readings from Java code
 * Cleanup task trigger based on metrics readings
 * A custom health-check endpoint for an application with an embedded
>> Ignite node for Kubernetes/Spring Application/etc
>>> 
>>> [1] https://github.com/apache/ignite/pull/7283
>>> 
 24 янв. 2020 г., в 18:08, Andrey Gura  написал(а):
 
> My point - that your contribution that took a long time, already,
>> can’t be an argument to postpone creation of the API in the current release.
 
 Argument is not about time. But about API which is known will be
>> changed.
 Second argument: why we should add this experimental API to the
 already existing experimental API? Just to making API more
 experimental? As I told already it is commit for commit and doesn't
 bring any value but brings some inconvenience to me (e.g. merge
 problems).
 
 BTW, does it exist issue about marking IEP-35 API's as experimental?
 
 On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков 
>> wrote:
> 
>> You want say didn't discuss?
> 
> Yes.
> 
>> Secondly, yes it took a lot of time due to a lot of changes. Is it
>> problem?
> 
> No, of course.
> My point - that your contribution that took a long time, already,
>> can’t be an argument to postpone creation of the API in the current release.
> 
> 
>> 23 янв. 2020 г., в 18:11, Andrey Gura  написал(а):
>> 
>>> We 

Re: [DISCUSS] Merge PR via GitHub web UI

[Alexey Zinoviev]

I used squash for last two years, no problemo with that. Of course we
should have 1 commit to 1 PR relationship, don't put all your commits to
the table:)

пн, 27 янв. 2020 г. в 15:50, Alexei Scherbakov :

> Petr Ivanov
>
> The script works great for me under windows.
>
> пн, 27 янв. 2020 г. в 15:33, Petr Ivanov :
>
> > Unfortunately, I have no power at Apache's GitHub repositories.
> > Ticket for INFRA maybe the best way to solve the issue.
> >
> >
> > > On 27 Jan 2020, at 15:23, Ivan Pavlukhin  wrote:
> > >
> > > But there is still the question how to configure it. Petr, can you
> > > help here? Or somebody else? Or INFRA ticket should be created?
> > >
> > > пн, 27 янв. 2020 г. в 15:05, Dmitriy Pavlov :
> > >>
> > >> I always merge PRs from GitHub when possible. By doing it I can keep
> my
> > >> Git's local state unmodified.
> > >>
> > >> So I suggest using squash and merge.
> > >>
> > >> пн, 27 янв. 2020 г. в 14:59, Maxim Muzafarov :
> > >>
> > >>> +1 to keep only "squash" merge option
> > >>>
> > >>> On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn 
> > wrote:
> > 
> >  Merging from GitHub is very convenient indeed, much faster and safer
> > than
> >  anything else.
> > 
> >  And yes, GitHub provides a way to disable Merge and Rebase, leaving
> > only
> >  Squash option:
> > 
> > >>>
> >
> https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
> > 
> > 
> >  However, I don't have access to the settings.
> >  Peter, can you please change this setting for us?
> > 
> >  On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov 
> > wrote:
> > 
> > > Iliya,
> > >
> > > How well does this script work under non-linux operations systems?
> > >
> > >
> > >> On 27 Jan 2020, at 14:24, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > 
> > > wrote:
> > >>
> > >> Hello!
> > >>
> > >> I implore everybody to use scripts/apply-pull-request.sh, I never
> > >>> had any
> > >> problems with it. The only downside is that cherry-peek needs to
> be
> > > clean.
> > >>
> > >> Regards,
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >>
> > >> пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin  >:
> > >>
> > >>> Today I opened for myself a possibility to merge PR via GitHub.
> And
> > >>> GitHub allows 3 usual options to do a merge (merge commit,
> rebase,
> > >>> squash). And "merge commit" is a default option but an illegal
> one
> > >>> according to Apache Ignite usual practices.
> > >>>
> > >>> So, I wonder is it somehow possible to configure it to keep only
> > >>> "squash" merge option?
> > >>>
> > >>> --
> > >>> Best regards,
> > >>> Ivan Pavlukhin
> > >>>
> > >
> > >
> > >>>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> >
> >
>
> --
>
> Best regards,
> Alexei Scherbakov
>

Re: Internal classes are exposed in public API

[Alexey Goncharuk]

Nikolay,

I've reviewed your changes and I tend to agree with Andrey, it's better to
remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
facade (IGNITE-12553) in a more calm and structured way. My observations on
the changes:

   - I am not sure if Iterable would suffice both for the exporter and
   public APIs. Should we provide a way to know the number of metrics and
   registries in advance? Let's say I am writing a custom exporter in binary
   format and I need to write the number of exported metrics in a packet
   beforehand.
   - There is no separation on public and internal metrics, when public
   metrics preserve their name and semantics, and internal metrics may change.
   I remember we discussed this, but it's not reflected in the APIs in any way.
   - Will we allow users to register their own metrics? Again I remember we
   discussed a possibility for this. If so, why the registry is called
   'ReadyOnly'?
   - It's still not clear how a user will map old interfaces and methods to
   the new metric names.

As you can see in the original message, I am not pushing for the new APIs
in the nearest release, I just want to remove the deprecations on the
classes for which there is no a well-defined replacement.

пн, 27 янв. 2020 г. в 15:56, Maxim Muzafarov :

> Folks,
>
>
> I'm sorry for not being too attentive to the whole thread discussion
> and maybe missing some details.
>
> But... who will perform the review of [1] issue?
> Will we merge it to 2.8? (hope so)
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12553
> [IEP-35] public Java metric API
>
> On Sat, 25 Jan 2020 at 11:43, Николай Ижиков  wrote:
> >
> > Andrey.
> >
> > With this API we are trying to fill the GAP Alexey pointed out at the
> start of this discussion.
> > I think it worth to be reviewed and merged.
> >
> > Can we, please, come back to the discussion of the changes itself?
> > I think API changes should be discussed in the other thread.
> >
> > > Why do you think this is a wrong usage pattern? From the top of my
> head, here is a few cases of direct metric API usage that I know are
> currently being used in production:
> > > * A custom task execution scheduling service with load balancing based
> on utilization metrics readings from Java code
> > > * Cleanup task trigger based on metrics readings
> > > * A custom health-check endpoint for an application with an embedded
> Ignite node for Kubernetes/Spring Application/etc
> >
> > [1] https://github.com/apache/ignite/pull/7283
> >
> > > 24 янв. 2020 г., в 18:08, Andrey Gura  написал(а):
> > >
> > >> My point - that your contribution that took a long time, already,
> can’t be an argument to postpone creation of the API in the current release.
> > >
> > > Argument is not about time. But about API which is known will be
> changed.
> > > Second argument: why we should add this experimental API to the
> > > already existing experimental API? Just to making API more
> > > experimental? As I told already it is commit for commit and doesn't
> > > bring any value but brings some inconvenience to me (e.g. merge
> > > problems).
> > >
> > > BTW, does it exist issue about marking IEP-35 API's as experimental?
> > >
> > > On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков 
> wrote:
> > >>
> > >>> You want say didn't discuss?
> > >>
> > >> Yes.
> > >>
> > >>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> problem?
> > >>
> > >> No, of course.
> > >> My point - that your contribution that took a long time, already,
> can’t be an argument to postpone creation of the API in the current release.
> > >>
> > >>
> > >>> 23 янв. 2020 г., в 18:11, Andrey Gura  написал(а):
> > >>>
> >  We don’t discuss your changes and your proposals for the Metric API.
> > >>>
> > >>> You want say didn't discuss? Actually we did it [1] but you told ok
> > >>> let's see code :)
> > >>>
> >  So I don’t think we can make the existence of some PR is an
> argument to introduce(or not introduce) this facade.
> > >>>
> > >>> You definitely right in case of competition development. But I think
> > >>> that collaborative development is more effective. Isn't it?
> > >>>
> >  Moreover, As far as I know, you developing changes for the Metric
> API for 5 months without public discussion, for now. Let's start it.
> > >>>
> > >>> Firsty, with discussion. See above.
> > >>> Secondly, yes it took a lot of time due to a lot of changes. Is it
> problem?
> > >>>
> >  Let’s do the following:
> >  1. Review `IgniteMetric` facade and introduce it to the users as an
> experimental API.
> > >>>
> > >>> It just doesn't make sense. Just commit for commit.
> > >>>
> >  2. Discuss your proposal to the Metric API in the separate thread
> you are referencing.
> > >>>
> > >>> You a re welcome to thread [1] again. But please, take into account.
> > >>> because discussion is postponed by you it's late enough to discuss
> > >>> proposed solution. But of course I'll answer on your 

Re: Internal classes are exposed in public API

[Maxim Muzafarov]

Folks,


I'm sorry for not being too attentive to the whole thread discussion
and maybe missing some details.

But... who will perform the review of [1] issue?
Will we merge it to 2.8? (hope so)


[1] https://issues.apache.org/jira/browse/IGNITE-12553
[IEP-35] public Java metric API

On Sat, 25 Jan 2020 at 11:43, Николай Ижиков  wrote:
>
> Andrey.
>
> With this API we are trying to fill the GAP Alexey pointed out at the start 
> of this discussion.
> I think it worth to be reviewed and merged.
>
> Can we, please, come back to the discussion of the changes itself?
> I think API changes should be discussed in the other thread.
>
> > Why do you think this is a wrong usage pattern? From the top of my head, 
> > here is a few cases of direct metric API usage that I know are currently 
> > being used in production:
> > * A custom task execution scheduling service with load balancing based on 
> > utilization metrics readings from Java code
> > * Cleanup task trigger based on metrics readings
> > * A custom health-check endpoint for an application with an embedded Ignite 
> > node for Kubernetes/Spring Application/etc
>
> [1] https://github.com/apache/ignite/pull/7283
>
> > 24 янв. 2020 г., в 18:08, Andrey Gura  написал(а):
> >
> >> My point - that your contribution that took a long time, already, can’t be 
> >> an argument to postpone creation of the API in the current release.
> >
> > Argument is not about time. But about API which is known will be changed.
> > Second argument: why we should add this experimental API to the
> > already existing experimental API? Just to making API more
> > experimental? As I told already it is commit for commit and doesn't
> > bring any value but brings some inconvenience to me (e.g. merge
> > problems).
> >
> > BTW, does it exist issue about marking IEP-35 API's as experimental?
> >
> > On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков  wrote:
> >>
> >>> You want say didn't discuss?
> >>
> >> Yes.
> >>
> >>> Secondly, yes it took a lot of time due to a lot of changes. Is it 
> >>> problem?
> >>
> >> No, of course.
> >> My point - that your contribution that took a long time, already, can’t be 
> >> an argument to postpone creation of the API in the current release.
> >>
> >>
> >>> 23 янв. 2020 г., в 18:11, Andrey Gura  написал(а):
> >>>
>  We don’t discuss your changes and your proposals for the Metric API.
> >>>
> >>> You want say didn't discuss? Actually we did it [1] but you told ok
> >>> let's see code :)
> >>>
>  So I don’t think we can make the existence of some PR is an argument to 
>  introduce(or not introduce) this facade.
> >>>
> >>> You definitely right in case of competition development. But I think
> >>> that collaborative development is more effective. Isn't it?
> >>>
>  Moreover, As far as I know, you developing changes for the Metric API 
>  for 5 months without public discussion, for now. Let's start it.
> >>>
> >>> Firsty, with discussion. See above.
> >>> Secondly, yes it took a lot of time due to a lot of changes. Is it 
> >>> problem?
> >>>
>  Let’s do the following:
>  1. Review `IgniteMetric` facade and introduce it to the users as an 
>  experimental API.
> >>>
> >>> It just doesn't make sense. Just commit for commit.
> >>>
>  2. Discuss your proposal to the Metric API in the separate thread you 
>  are referencing.
> >>>
> >>> You a re welcome to thread [1] again. But please, take into account.
> >>> because discussion is postponed by you it's late enough to discuss
> >>> proposed solution. But of course I'll answer on your questions and
> >>> will be glade to your comments and suggestions.
> >>>
>  I think we should start a discussion from the simplified explanation of:
>  1. API intentions - What we want to gain with it? What is our focus?
>  2. Simple, minimal example of API main interfaces and desired usages.
> >>>
> >>> All this already described at [1]. You also can take a look on PR (see
> >>> MetricSource implementations, there are complex and simple ones).
> >>>
> >>> [1] 
> >>> http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> >>>
> >>> On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков  
> >>> wrote:
> 
>  Andrey.
> 
> > IGNITE-11927 implementation so your changes are incompatible with my 
> > changes
> 
>  We don’t discuss your changes and your proposals for the Metric API.
>  So I don’t think we can make the existence of some PR is an argument to 
>  introduce(or not introduce) this facade.
>  Moreover, As far as I know, you developing changes for the Metric API 
>  for 5 months without public discussion, for now. Let's start it.
> 
>  Let’s do the following:
> 
>  1. Review `IgniteMetric` facade and introduce it to the users as an 
>  experimental API.
> 
>  2. Discuss your proposal to the Metric API in the separate thread you 
>  are referencing.
> 
>  I 

Re: [DISCUSS] Merge PR via GitHub web UI

[Alexei Scherbakov]

Petr Ivanov

The script works great for me under windows.

пн, 27 янв. 2020 г. в 15:33, Petr Ivanov :

> Unfortunately, I have no power at Apache's GitHub repositories.
> Ticket for INFRA maybe the best way to solve the issue.
>
>
> > On 27 Jan 2020, at 15:23, Ivan Pavlukhin  wrote:
> >
> > But there is still the question how to configure it. Petr, can you
> > help here? Or somebody else? Or INFRA ticket should be created?
> >
> > пн, 27 янв. 2020 г. в 15:05, Dmitriy Pavlov :
> >>
> >> I always merge PRs from GitHub when possible. By doing it I can keep my
> >> Git's local state unmodified.
> >>
> >> So I suggest using squash and merge.
> >>
> >> пн, 27 янв. 2020 г. в 14:59, Maxim Muzafarov :
> >>
> >>> +1 to keep only "squash" merge option
> >>>
> >>> On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn 
> wrote:
> 
>  Merging from GitHub is very convenient indeed, much faster and safer
> than
>  anything else.
> 
>  And yes, GitHub provides a way to disable Merge and Rebase, leaving
> only
>  Squash option:
> 
> >>>
> https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
> 
> 
>  However, I don't have access to the settings.
>  Peter, can you please change this setting for us?
> 
>  On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov 
> wrote:
> 
> > Iliya,
> >
> > How well does this script work under non-linux operations systems?
> >
> >
> >> On 27 Jan 2020, at 14:24, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> 
> > wrote:
> >>
> >> Hello!
> >>
> >> I implore everybody to use scripts/apply-pull-request.sh, I never
> >>> had any
> >> problems with it. The only downside is that cherry-peek needs to be
> > clean.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
> >>
> >>> Today I opened for myself a possibility to merge PR via GitHub. And
> >>> GitHub allows 3 usual options to do a merge (merge commit, rebase,
> >>> squash). And "merge commit" is a default option but an illegal one
> >>> according to Apache Ignite usual practices.
> >>>
> >>> So, I wonder is it somehow possible to configure it to keep only
> >>> "squash" merge option?
> >>>
> >>> --
> >>> Best regards,
> >>> Ivan Pavlukhin
> >>>
> >
> >
> >>>
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>

-- 

Best regards,
Alexei Scherbakov

Re: [DISCUSS] Merge PR via GitHub web UI

[Petr Ivanov]

Unfortunately, I have no power at Apache's GitHub repositories.
Ticket for INFRA maybe the best way to solve the issue.


> On 27 Jan 2020, at 15:23, Ivan Pavlukhin  wrote:
> 
> But there is still the question how to configure it. Petr, can you
> help here? Or somebody else? Or INFRA ticket should be created?
> 
> пн, 27 янв. 2020 г. в 15:05, Dmitriy Pavlov :
>> 
>> I always merge PRs from GitHub when possible. By doing it I can keep my
>> Git's local state unmodified.
>> 
>> So I suggest using squash and merge.
>> 
>> пн, 27 янв. 2020 г. в 14:59, Maxim Muzafarov :
>> 
>>> +1 to keep only "squash" merge option
>>> 
>>> On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn  wrote:
 
 Merging from GitHub is very convenient indeed, much faster and safer than
 anything else.
 
 And yes, GitHub provides a way to disable Merge and Rebase, leaving only
 Squash option:
 
>>> https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
 
 
 However, I don't have access to the settings.
 Peter, can you please change this setting for us?
 
 On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov  wrote:
 
> Iliya,
> 
> How well does this script work under non-linux operations systems?
> 
> 
>> On 27 Jan 2020, at 14:24, Ilya Kasnacheev >>> 
> wrote:
>> 
>> Hello!
>> 
>> I implore everybody to use scripts/apply-pull-request.sh, I never
>>> had any
>> problems with it. The only downside is that cherry-peek needs to be
> clean.
>> 
>> Regards,
>> --
>> Ilya Kasnacheev
>> 
>> 
>> пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
>> 
>>> Today I opened for myself a possibility to merge PR via GitHub. And
>>> GitHub allows 3 usual options to do a merge (merge commit, rebase,
>>> squash). And "merge commit" is a default option but an illegal one
>>> according to Apache Ignite usual practices.
>>> 
>>> So, I wonder is it somehow possible to configure it to keep only
>>> "squash" merge option?
>>> 
>>> --
>>> Best regards,
>>> Ivan Pavlukhin
>>> 
> 
> 
>>> 
> 
> 
> 
> -- 
> Best regards,
> Ivan Pavlukhin

Re: Add user attributes to thin clients

[Dmitrii Ryabov]

Ok, if no one have objections, I will restrict a map by strings only.

чт, 23 янв. 2020 г., 17:20 Pavel Tupitsyn :

> >  Well, my understanding was a binary object with compact footer = false
> is totally standalone entity and can be read without any external metadata
> Not exactly: type name and field names are unknown, you only have typeId,
> field ids and positions.
> There is one more Marshaller "mode": UNREGISTERED_TYPE_ID. In this mode,
> full type name is included in the binary object.
> However, field names are still missing and the class needs to be present to
> deserialize.
> That's why arbitrary objects should not be allowed in the handshake: in
> most cases they can't be decoded.
>
> On Thu, Jan 23, 2020 at 2:27 PM Dmitrii Ryabov 
> wrote:
>
> > Alexei, yes, compactFooter is used only in 1 place.
> >
> > ```
> >
> > BinaryWriterExImpl.marshal0() {
> >
> >   BinaryClassDescriptor desc = ctx.descriptorForClass(cls);
> >
> >   // descriptor transportation fails here
> >
> >   ...
> >
> >   desc.write(obj, this); // compactFooter here
> >
> > }
> >
> > ```
> >
> > чт, 23 янв. 2020 г., 14:15 Pavel Tupitsyn :
> >
> > > > If we support only strings it will be necessary to encode binary
> values
> > > to
> > > > something like BASE64 which is not sounds good from usability side
> > >
> > > There should be no need to put binary values to attributes. What's the
> > use
> > > case?
> > >
> > > On Thu, Jan 23, 2020 at 2:08 PM Alexei Scherbakov <
> > > alexey.scherbak...@gmail.com> wrote:
> > >
> > > > > Footer is checked in postWrite - much later class descriptor check.
> > > >
> > > > Well, my understanding was a binary object with compact footer =
> false
> > is
> > > > totally standalone entity and can be read without any external
> > metadata.
> > > > Dmitrii Ryabov can you double check ?
> > > >
> > > > If we support only strings it will be necessary to encode binary
> values
> > > to
> > > > something like BASE64 which is not sounds good from usability side.
> > > >
> > > >
> > > >
> > > > чт, 23 янв. 2020 г. в 13:26, Nikita Amelchev :
> > > >
> > > > > +1 for the hardcoded String type only
> > > > >
> > > > > чт, 23 янв. 2020 г. в 13:15, Pavel Tupitsyn  >:
> > > > > >
> > > > > > - Cross-platform binary objects are totally possible, all those
> > thin
> > > > > > clients support them.
> > > > > > - User attributes can be useful, no objections here
> > > > > >
> > > > > > However, I don't think we should allow arbitrary objects in user
> > > > > attributes.
> > > > > > Let's make them string only, much less to worry about.
> > > > > >
> > > > > > And using attributes for authentication still seems weird and
> > dirty.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jan 23, 2020 at 12:40 PM Dmitrii Ryabov <
> > > somefire...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > > Even if compact footer is disabled ?
> > > > > > > Footer is checked in postWrite - much later class descriptor
> > check.
> > > > > > >
> > > > > > > чт, 23 янв. 2020 г., 12:23 Alexei Scherbakov <
> > > > > alexey.scherbak...@gmail.com
> > > > > > > >:
> > > > > > >
> > > > > > > > чт, 23 янв. 2020 г. в 12:17, Dmitrii Ryabov <
> > > somefire...@gmail.com
> > > > >:
> > > > > > > >
> > > > > > > > > > The protocol must be language-agnostic. If we add some
> > > features
> > > > > > > there,
> > > > > > > > > let's make sure they are usable from anywhere.
> > > > > > > > >
> > > > > > > > > That's why I want to allow primitives only. Any language
> can
> > > send
> > > > > > > numbers
> > > > > > > > > and strings.
> > > > > > > > >
> > > > > > > >
> > > > > > > > In general it's possible to have cross-platform complex data
> > > > > structures,
> > > > > > > > for example see protobuf.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Binary marshaller, before packing object to byte[], will
> try
> > to
> > > > use
> > > > > > > > > discovery processor and send message containing class
> > > descriptor.
> > > > > But
> > > > > > > > thin
> > > > > > > > > clients don't have discovery. Furthermore, if we write
> binary
> > > > > > > marshaller
> > > > > > > > > without class descriptor synchronization, we can get
> objects
> > > with
> > > > > > > > different
> > > > > > > > > class versions and corresponding exceptions.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Even if compact footer is disabled ?
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > But we can say users to declare their classes in
> > > > > > > > > META-INF/classnames.properties and current binary
> marshaller
> > > will
> > > > > works
> > > > > > > > > good.
> > > > > > > > >
> > > > > > > >
> > > > > > > > This approach doesn't looks like cross-platform.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > чт, 23 янв. 2020 г., 12:13 Alex Plehanov <
> > > > plehanov.a...@gmail.com
> > > > > >:
> > > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > 

Re: [DISCUSS] Merge PR via GitHub web UI

[Ivan Pavlukhin]

But there is still the question how to configure it. Petr, can you
help here? Or somebody else? Or INFRA ticket should be created?

пн, 27 янв. 2020 г. в 15:05, Dmitriy Pavlov :
>
> I always merge PRs from GitHub when possible. By doing it I can keep my
> Git's local state unmodified.
>
> So I suggest using squash and merge.
>
> пн, 27 янв. 2020 г. в 14:59, Maxim Muzafarov :
>
> > +1 to keep only "squash" merge option
> >
> > On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn  wrote:
> > >
> > > Merging from GitHub is very convenient indeed, much faster and safer than
> > > anything else.
> > >
> > > And yes, GitHub provides a way to disable Merge and Rebase, leaving only
> > > Squash option:
> > >
> > https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
> > >
> > >
> > > However, I don't have access to the settings.
> > > Peter, can you please change this setting for us?
> > >
> > > On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov  wrote:
> > >
> > > > Iliya,
> > > >
> > > > How well does this script work under non-linux operations systems?
> > > >
> > > >
> > > > > On 27 Jan 2020, at 14:24, Ilya Kasnacheev  > >
> > > > wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > I implore everybody to use scripts/apply-pull-request.sh, I never
> > had any
> > > > > problems with it. The only downside is that cherry-peek needs to be
> > > > clean.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
> > > > >
> > > > >> Today I opened for myself a possibility to merge PR via GitHub. And
> > > > >> GitHub allows 3 usual options to do a merge (merge commit, rebase,
> > > > >> squash). And "merge commit" is a default option but an illegal one
> > > > >> according to Apache Ignite usual practices.
> > > > >>
> > > > >> So, I wonder is it somehow possible to configure it to keep only
> > > > >> "squash" merge option?
> > > > >>
> > > > >> --
> > > > >> Best regards,
> > > > >> Ivan Pavlukhin
> > > > >>
> > > >
> > > >
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Apache Ignite contribution

[Ivan Pavlukhin]

I beleive that dev list should be the only mean of (technical)
decision making for the project.

But other resources can show better productivity and especially for
newcomers. And I am little bit worried that means of communication
seems a little bit scattered. I will try telegram =)

пн, 27 янв. 2020 г. в 14:57, Dmitriy Pavlov :
>
> Hi Igniters,
>
> I would name dev list as the only one official channel. Other options are
> supplementary channels just for convenience (Slack for voice calls & chats,
> Russian local resources for easier communication without foreign language
> barrier). But still, I hope we're on the same page that
> _If it didn't happen on the list, it didn't happen._
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 27 янв. 2020 г. в 12:24, Alexey Zinoviev :
>
> > And dont forget asf slack with a few channel about Apache ignite
> >
> > пн, 27 янв. 2020 г., 12:20 Ivan Pavlukhin :
> >
> > > Maksim, folks,
> > >
> > > Actually I am curious what kind of communication channel is mentioned
> > > telegram channel? Should we add a link to it on official "community
> > > resources" page?
> > >
> > > пн, 27 янв. 2020 г. в 11:40, Maksim Stepachev <
> > maksim.stepac...@gmail.com
> > > >:
> > > >
> > > > Hello!
> > > >
> > > > If you have the telegram, join to Russian channel:
> > > https://t.me/RU_Ignite
> > > >
> > > > чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >:
> > > >
> > > > > Hello!
> > > > >
> > > > > I have added you to Contributors of our project, you can now assign
> > > issues
> > > > > to yourself.
> > > > >
> > > > > Please read
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > чт, 23 янв. 2020 г. в 15:31, Лев Киселев  > >:
> > > > >
> > > > > > Hello,
> > > > > > I want to take part in the development of Apache Ignite.
> > > > > > Primary skills: Java SE, Java 8, Spring framework, SQL.
> > > > > > Also: Multithreading (incl. FJP), Design Patterns, Algorithms and
> > > Data
> > > > > > Structures.
> > > > > >
> > > > > > My JIRA ID: l4ndsc4pe
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Launched Ignite meetups and redesigned events pages

[Dmitriy Pavlov]

Hi Denis,

yes, sorry for late reply, I just did double check that I can access
answers. Additionally, Ksenia R. have access to proposals.

Anyone from PMC who would like to volunteer and being PMC Representative
for Apache Ignite Local meetups are always welcomed (according
https://www.apache.org/foundation/marks/events  - The ASF events branding
policy).

Moreover, not-yet-PMC volunteers, who would help with talks preparation are
also welcomed. I strongly believe we should not be too formal here.

Sincerely,
Dmitriy Pavlov



чт, 9 янв. 2020 г. в 23:47, Denis Magda :

> Dmitry,
>
> We've also added the reference to the form on the event's webpage. Btw,
> could you remind me who will be receiving the proposals - you, I and some
> other folks or all @dev list?
>
> -
> Denis
>
>
> On Thu, Jan 9, 2020 at 1:53 AM Dmitriy Pavlov  wrote:
>
>> Hi Igniters, Mauricio, Ignacio, and Denis,
>>
>> Thank you all for updating these pages.
>>
>> I would like to stress just one thing:
>> should you have in mind some topic you can run talk about, please feel
>> absolutely free to fill submission proposal.
>>
>> To submit proposal you need to fill in this form
>>
>> https://docs.google.com/forms/d/e/1FAIpQLSdiY7movHKvyWg3gOVedHgukJJnNiaejSO_X838vBseL9VmiQ/viewform
>> .
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> вт, 7 янв. 2020 г. в 02:48, Denis Magda :
>>
>> > Igniters,
>> >
>> > I've just merged changes contributed by Mauricio and Ignacio, who helped
>> > us to prepare professional webpages for Ignite meetup groups around the
>> > world [1] and for Ignite events [2]. Now you can easily enroll in a
>> meetup
>> > group nearby or sign up for an upcoming event to be hosted one of our
>> > experts.
>> >
>> > Please check them out and share your feedback. In the meantime, three of
>> > us are going to carry on with optimizations and changes making the
>> website
>> > more useful for developers as well as more searchable/discoverable from
>> > various search engines.
>> >
>> > [1] https://ignite.apache.org/meetup-groups.html
>> > [2] https://ignite.apache.org/events.html
>> >
>> > -
>> > Denis
>> >
>>
>

Re: [DISCUSS] Merge PR via GitHub web UI

[Dmitriy Pavlov]

I always merge PRs from GitHub when possible. By doing it I can keep my
Git's local state unmodified.

So I suggest using squash and merge.

пн, 27 янв. 2020 г. в 14:59, Maxim Muzafarov :

> +1 to keep only "squash" merge option
>
> On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn  wrote:
> >
> > Merging from GitHub is very convenient indeed, much faster and safer than
> > anything else.
> >
> > And yes, GitHub provides a way to disable Merge and Rebase, leaving only
> > Squash option:
> >
> https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
> >
> >
> > However, I don't have access to the settings.
> > Peter, can you please change this setting for us?
> >
> > On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov  wrote:
> >
> > > Iliya,
> > >
> > > How well does this script work under non-linux operations systems?
> > >
> > >
> > > > On 27 Jan 2020, at 14:24, Ilya Kasnacheev  >
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > I implore everybody to use scripts/apply-pull-request.sh, I never
> had any
> > > > problems with it. The only downside is that cherry-peek needs to be
> > > clean.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
> > > >
> > > >> Today I opened for myself a possibility to merge PR via GitHub. And
> > > >> GitHub allows 3 usual options to do a merge (merge commit, rebase,
> > > >> squash). And "merge commit" is a default option but an illegal one
> > > >> according to Apache Ignite usual practices.
> > > >>
> > > >> So, I wonder is it somehow possible to configure it to keep only
> > > >> "squash" merge option?
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Ivan Pavlukhin
> > > >>
> > >
> > >
>

Re: [DISCUSS] Merge PR via GitHub web UI

[Maxim Muzafarov]

+1 to keep only "squash" merge option

On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn  wrote:
>
> Merging from GitHub is very convenient indeed, much faster and safer than
> anything else.
>
> And yes, GitHub provides a way to disable Merge and Rebase, leaving only
> Squash option:
> https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
>
>
> However, I don't have access to the settings.
> Peter, can you please change this setting for us?
>
> On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov  wrote:
>
> > Iliya,
> >
> > How well does this script work under non-linux operations systems?
> >
> >
> > > On 27 Jan 2020, at 14:24, Ilya Kasnacheev 
> > wrote:
> > >
> > > Hello!
> > >
> > > I implore everybody to use scripts/apply-pull-request.sh, I never had any
> > > problems with it. The only downside is that cherry-peek needs to be
> > clean.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
> > >
> > >> Today I opened for myself a possibility to merge PR via GitHub. And
> > >> GitHub allows 3 usual options to do a merge (merge commit, rebase,
> > >> squash). And "merge commit" is a default option but an illegal one
> > >> according to Apache Ignite usual practices.
> > >>
> > >> So, I wonder is it somehow possible to configure it to keep only
> > >> "squash" merge option?
> > >>
> > >> --
> > >> Best regards,
> > >> Ivan Pavlukhin
> > >>
> >
> >

Re: Apache Ignite contribution

[Dmitriy Pavlov]

Hi Igniters,

I would name dev list as the only one official channel. Other options are
supplementary channels just for convenience (Slack for voice calls & chats,
Russian local resources for easier communication without foreign language
barrier). But still, I hope we're on the same page that
_If it didn't happen on the list, it didn't happen._

Sincerely,
Dmitriy Pavlov

пн, 27 янв. 2020 г. в 12:24, Alexey Zinoviev :

> And dont forget asf slack with a few channel about Apache ignite
>
> пн, 27 янв. 2020 г., 12:20 Ivan Pavlukhin :
>
> > Maksim, folks,
> >
> > Actually I am curious what kind of communication channel is mentioned
> > telegram channel? Should we add a link to it on official "community
> > resources" page?
> >
> > пн, 27 янв. 2020 г. в 11:40, Maksim Stepachev <
> maksim.stepac...@gmail.com
> > >:
> > >
> > > Hello!
> > >
> > > If you have the telegram, join to Russian channel:
> > https://t.me/RU_Ignite
> > >
> > > чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >:
> > >
> > > > Hello!
> > > >
> > > > I have added you to Contributors of our project, you can now assign
> > issues
> > > > to yourself.
> > > >
> > > > Please read
> > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > чт, 23 янв. 2020 г. в 15:31, Лев Киселев  >:
> > > >
> > > > > Hello,
> > > > > I want to take part in the development of Apache Ignite.
> > > > > Primary skills: Java SE, Java 8, Spring framework, SQL.
> > > > > Also: Multithreading (incl. FJP), Design Patterns, Algorithms and
> > Data
> > > > > Structures.
> > > > >
> > > > > My JIRA ID: l4ndsc4pe
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>

Re: [ANNOUNCE] New Apache Ignite PMC member: Igor Sapego

[Dmitriy Pavlov]

Hi Igor,

congrats with new role.

Sincerely,
Dmitriy Pavlov

пн, 27 янв. 2020 г. в 12:51, Petr Ivanov :

> Congratulations, Igor.
>
> Well deserved!
>
>
> > On 27 Jan 2020, at 08:57, Ivan Pavlukhin  wrote:
> >
> > Hello Ignite Community,
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited
> > Igor Sapego to join the PMC as a new member and we are pleased to
> > announce that he has accepted.
> >
> > Igor is an active Community member for a long time. He made a
> > worthless contribution in Ignite C++ development and continues to do
> > it today. Moreover he drives thin clients development for other
> > programming languages. Additionally, always helpful on users mailing
> > list. Wrote blog posts and spoke publicly about Ignite.
> >
> > Being a PMC member enables assistance with the management and to guide
> > the direction of the project.
> >
> > Please join me in congratulating Igor!
> >
> > Best regards,
> > Ivan Pavlukhin
> > on behalf of Apache Ignite PMC
>
>

Re: [DISCUSS] Merge PR via GitHub web UI

[Pavel Tupitsyn]

Merging from GitHub is very convenient indeed, much faster and safer than
anything else.

And yes, GitHub provides a way to disable Merge and Rebase, leaving only
Squash option:
https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests


However, I don't have access to the settings.
Peter, can you please change this setting for us?

On Mon, Jan 27, 2020 at 2:38 PM Petr Ivanov  wrote:

> Iliya,
>
> How well does this script work under non-linux operations systems?
>
>
> > On 27 Jan 2020, at 14:24, Ilya Kasnacheev 
> wrote:
> >
> > Hello!
> >
> > I implore everybody to use scripts/apply-pull-request.sh, I never had any
> > problems with it. The only downside is that cherry-peek needs to be
> clean.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
> >
> >> Today I opened for myself a possibility to merge PR via GitHub. And
> >> GitHub allows 3 usual options to do a merge (merge commit, rebase,
> >> squash). And "merge commit" is a default option but an illegal one
> >> according to Apache Ignite usual practices.
> >>
> >> So, I wonder is it somehow possible to configure it to keep only
> >> "squash" merge option?
> >>
> >> --
> >> Best regards,
> >> Ivan Pavlukhin
> >>
>
>

Re: [DISCUSS] Merge PR via GitHub web UI

[Petr Ivanov]

Iliya,

How well does this script work under non-linux operations systems?


> On 27 Jan 2020, at 14:24, Ilya Kasnacheev  wrote:
> 
> Hello!
> 
> I implore everybody to use scripts/apply-pull-request.sh, I never had any
> problems with it. The only downside is that cherry-peek needs to be clean.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
> 
>> Today I opened for myself a possibility to merge PR via GitHub. And
>> GitHub allows 3 usual options to do a merge (merge commit, rebase,
>> squash). And "merge commit" is a default option but an illegal one
>> according to Apache Ignite usual practices.
>> 
>> So, I wonder is it somehow possible to configure it to keep only
>> "squash" merge option?
>> 
>> --
>> Best regards,
>> Ivan Pavlukhin
>> 

Re: [DISCUSS] Merge PR via GitHub web UI

[Ilya Kasnacheev]

Hello!

I implore everybody to use scripts/apply-pull-request.sh, I never had any
problems with it. The only downside is that cherry-peek needs to be clean.

Regards,
-- 
Ilya Kasnacheev


пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :

> Today I opened for myself a possibility to merge PR via GitHub. And
> GitHub allows 3 usual options to do a merge (merge commit, rebase,
> squash). And "merge commit" is a default option but an illegal one
> according to Apache Ignite usual practices.
>
> So, I wonder is it somehow possible to configure it to keep only
> "squash" merge option?
>
> --
> Best regards,
> Ivan Pavlukhin
>

[DISCUSS] Merge PR via GitHub web UI

[Ivan Pavlukhin]

Today I opened for myself a possibility to merge PR via GitHub. And
GitHub allows 3 usual options to do a merge (merge commit, rebase,
squash). And "merge commit" is a default option but an illegal one
according to Apache Ignite usual practices.

So, I wonder is it somehow possible to configure it to keep only
"squash" merge option?

-- 
Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-12584) Query execution is too long issue!

[Aditya (Jira)]

Aditya created IGNITE-12584:
---

 Summary: Query execution is too long issue!
 Key: IGNITE-12584
 URL: https://issues.apache.org/jira/browse/IGNITE-12584
 Project: Ignite
  Issue Type: Bug
Reporter: Aditya
 Attachments: uploadthis.txt

When querying via some java application and if the topology is in such a way 
that two clients connect to one server node, then some times we are getting an 
exception saying query execution is too long.

 

This is the SQL schema for table

 

stmt.executeUpdate("CREATE TABLE DOCIDS (" +
 " id LONG PRIMARY KEY, url VARCHAR, score LONG, appname VARCHAR) " +
 " WITH \"template=replicated\"");

 

stmt.executeUpdate("CREATE INDEX idx_doc_name_url ON DOCIDS (appname, url)");

 

Query -> 

SqlFieldsQuery query = new SqlFieldsQuery("SELECT count(id) FROM DOCIDS");

FieldsQueryCursor> cursor = cache.query(query);

For warning prints, please check the attachment.



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

[jira] [Created] (IGNITE-12583) Parametrization of JdbcThinBulkLoadAbstractSelfTest

[Vladimir Steshin (Jira)]

Vladimir Steshin created IGNITE-12583:
-

 Summary: Parametrization of JdbcThinBulkLoadAbstractSelfTest
 Key: IGNITE-12583
 URL: https://issues.apache.org/jira/browse/IGNITE-12583
 Project: Ignite
  Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin


org.apache.ignite.jdbc.thin.JdbcThinBulkLoadAbstractSelfTest is extended 
several times using just parameter-assigning-getters like 

{code:java}
protected CacheMode cacheMode() { return CacheMode.REPLICATED; }
protected CacheAtomicityMode atomicityMode() { return 
CacheAtomicityMode.TRANSACTIONAL;}
protected boolean nearCache() { return false; }
{code}

Should go with params instead.
 



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

Re: Task to implement: IGNITE-12581

[Vladimir Steshin]

Ok. Forgot to explain the ticket. I'm going to bring some refactoring to
the test, replace inheritance with parametrization. Many tests use
extending to handle params like

public class JdbcThinBulkLoadAtomicReplicatedSelfTest extends
JdbcThinBulkLoadAbstractSelfTest {
/** {@inheritDoc} */
@Override protected CacheMode cacheMode() {
return CacheMode.REPLICATED;
}

/** {@inheritDoc} */
@Override protected CacheAtomicityMode atomicityMode() {
return CacheAtomicityMode.ATOMIC;
}

/** {@inheritDoc} */
@Override protected boolean nearCache() {
return false;
}
}


We might involve JUnit's params reducing code amount.




We might involve


пн, 27 янв. 2020 г. в 11:38, Maksim Stepachev :

> Hi,
>
> I suppose you can.
> Nikolay possibly may help with it.
> If you have the telegram, join to Russian channel: https://t.me/RU_Ignite
>
> вс, 26 янв. 2020 г. в 19:21, Vladimir Steshin :
>
> > Hi everyone.
> >
> > How do you think, can I start this task:
> > https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-12581 ?
> >
> > It looks useful and seems good for a newbie to begin researching the
> > code and test techniques.
> >
> >
>

Re: Ignite-spring-boot-autoconfigurer

[Nikolay Izhikov]

Hello, Alexey Kuznetsov.

I have two approvals from Saikat Maitra and Maxim Stepachov.
I have plans to merge spring-boot autoconfigure modules to
ignite-extensions. [1]
Do you want to perform additional review?

[1] https://github.com/apache/ignite-extensions/pull/6

пт, 24 янв. 2020 г. в 07:41, Saikat Maitra :

> Hi Nikolay,
>
> Thank you for updating the PR, the changes looks good.
>
> Regards,
> Saikat
>
> On Wed, Jan 22, 2020 at 1:33 PM Николай Ижиков 
> wrote:
>
> > Hello, Saikat.
> >
> > Thank you so much for the review.
> >
> > I answered your questions and resolve all the comments.
> > Please, take a look, one more time.
> >
> > > 22 янв. 2020 г., в 07:58, Saikat Maitra 
> > написал(а):
> > >
> > > Hi Nikolay,
> > >
> > > I have reviewed the PR and shared comments.
> > >
> > > Please let me know if you have any feedback.
> > >
> > > Regards,
> > > Saikat
> > >
> > > On Mon, Jan 20, 2020 at 2:42 PM Николай Ижиков 
> > wrote:
> > >
> > >> Hello, Saikat.
> > >>
> > >> Thanks, for feedback.
> > >>
> > >> I raised a PR [1] to `ignite-extensions`.
> > >>
> > >> You can find description of the new module below(examples can be found
> > at
> > >> [2]):
> > >>
> > >> Module provides the ability to integrate `Ignite` into you spring-boot
> > >> application with zero(or minimal) configuration.
> > >>
> > >> After you add this module as a dependency to your spring-boot
> > application
> > >> `Ignite` node will be configured and injected into `BeanFactory`.
> > >>
> > >> Algorithm to configure `Ignite` is the following:
> > >>  1. If `IgniteConfiguration` bean exists in the `BeanFactory` it will
> be
> > >> used.
> > >>  2. If `IgniteConfiguration` bean doesn't exist following rules are
> > >> applied:
> > >>2.1. Default `Ignite` configuration created.
> > >>2.2. If `IgniteConfigurer` bean exists in `BeanFactory` it will be
> > >> used to customize `IgniteConfiguration`.
> > >> If a user wants to set custom SPI instances or similar
> hardcoded
> > >> values
> > >> one should do it with `IgniteConfigurer` implementation.
> > >>2.3  Application properties applied to `IgniteConfiguration`.
> Prefix
> > >> for the properties is `ignite`.
> > >>
> > >>
> > >> [1] https://github.com/apache/ignite-extensions/pull/6
> > >> [2]
> > https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example
> > >>
> > >>
> > >>> 18 янв. 2020 г., в 06:44, Saikat Maitra 
> > >> написал(а):
> > >>>
> > >>> Hi Nikolay,
> > >>>
> > >>> Thank you for your email. As part of Ignite Extensions migration we
> are
> > >> migrating Ignite Extensions to following repo.
> > >>>
> > >>> https://github.com/apache/ignite-extensions
> > >>>
> > >>> We have added flink and pub-sub modules and few additional modules
> are
> > >> open in PR.
> > >>>
> > >>> You can refer to this PR to see how we are migrating the modules
> > >> https://github.com/apache/ignite-extensions/pull/5
> > >>>
> > >>> I wanted to connect and discuss the changes to understand the spring
> > >> boot auto configure feature. We currently have an ignite spring module
> > that
> > >> allows resource injection capabilities and provides a parser for
> Spring
> > >> based xml configuration files. Can you please review and share if the
> > >> changes you are proposing can be added as part of Ignite spring module
> > or
> > >> it make sense to make it a separate spring boot auto configure module.
> > >>>
> > >>> https://github.com/apache/ignite/tree/master/modules/spring
> > >>>
> > >>> Regards,
> > >>> Saikat
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Jan 17, 2020 at 3:12 AM Николай Ижиков 
> > >> wrote:
> > >>> Tests added.
> > >>> Please, review.
> > >>>
> > >>> Saikat, can you help with this PR [1]?
> > >>>
> > >>> I think it should be added as a separate module as we do with the
> flink
> > >> integration.
> > >>> Can you help me with it?
> > >>> Do we have some how-to for it?
> > >>>
> > >>> [1] https://github.com/apache/ignite/pull/7237
> > >>>
> >  16 янв. 2020 г., в 16:51, Николай Ижиков 
> > >> написал(а):
> > 
> >  Hello, Denis.
> > 
> >  Thanks, for the feedback.
> > 
> >  Alexey, it seems, PR is ready to be reviewed, but I need some time(a
> > >> day or two) to write tests.
> >  You can start with the core code review if you wish.
> > 
> >  Here are autoconfigurer requirements:
> > 
> >  1. Start usage of Ignite with minimal(or zero) configuration.
> >  2. Configure Ignite configuration properties with the standard
> spring
> > >> boot application properties.
> >  3. Configure Ignite SPI implementation and so on that can’t be
> > >> configured via #2.
> > 
> >  After some consultation with the Spring experts from the
> > >> community(Maxim Stepachev thanks for the idea)
> >  I updated the PR with the logic described below:
> > 
> >  1. To enable Ignite auto-configuration user should add
> > >> 

Re: [ANNOUNCE] New Apache Ignite PMC member: Igor Sapego

[Petr Ivanov]

Congratulations, Igor.

Well deserved!


> On 27 Jan 2020, at 08:57, Ivan Pavlukhin  wrote:
> 
> Hello Ignite Community,
> 
> The Project Management Committee (PMC) for Apache Ignite has invited
> Igor Sapego to join the PMC as a new member and we are pleased to
> announce that he has accepted.
> 
> Igor is an active Community member for a long time. He made a
> worthless contribution in Ignite C++ development and continues to do
> it today. Moreover he drives thin clients development for other
> programming languages. Additionally, always helpful on users mailing
> list. Wrote blog posts and spoke publicly about Ignite.
> 
> Being a PMC member enables assistance with the management and to guide
> the direction of the project.
> 
> Please join me in congratulating Igor!
> 
> Best regards,
> Ivan Pavlukhin
> on behalf of Apache Ignite PMC

Re: Apache Ignite contribution

[Alexey Zinoviev]

And dont forget asf slack with a few channel about Apache ignite

пн, 27 янв. 2020 г., 12:20 Ivan Pavlukhin :

> Maksim, folks,
>
> Actually I am curious what kind of communication channel is mentioned
> telegram channel? Should we add a link to it on official "community
> resources" page?
>
> пн, 27 янв. 2020 г. в 11:40, Maksim Stepachev  >:
> >
> > Hello!
> >
> > If you have the telegram, join to Russian channel:
> https://t.me/RU_Ignite
> >
> > чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev  >:
> >
> > > Hello!
> > >
> > > I have added you to Contributors of our project, you can now assign
> issues
> > > to yourself.
> > >
> > > Please read
> > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 23 янв. 2020 г. в 15:31, Лев Киселев :
> > >
> > > > Hello,
> > > > I want to take part in the development of Apache Ignite.
> > > > Primary skills: Java SE, Java 8, Spring framework, SQL.
> > > > Also: Multithreading (incl. FJP), Design Patterns, Algorithms and
> Data
> > > > Structures.
> > > >
> > > > My JIRA ID: l4ndsc4pe
> > > >
> > > > Thanks.
> > > >
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: Apache Ignite contribution

[Ivan Pavlukhin]

Maksim, folks,

Actually I am curious what kind of communication channel is mentioned
telegram channel? Should we add a link to it on official "community
resources" page?

пн, 27 янв. 2020 г. в 11:40, Maksim Stepachev :
>
> Hello!
>
> If you have the telegram, join to Russian channel: https://t.me/RU_Ignite
>
> чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev :
>
> > Hello!
> >
> > I have added you to Contributors of our project, you can now assign issues
> > to yourself.
> >
> > Please read
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 23 янв. 2020 г. в 15:31, Лев Киселев :
> >
> > > Hello,
> > > I want to take part in the development of Apache Ignite.
> > > Primary skills: Java SE, Java 8, Spring framework, SQL.
> > > Also: Multithreading (incl. FJP), Design Patterns, Algorithms and Data
> > > Structures.
> > >
> > > My JIRA ID: l4ndsc4pe
> > >
> > > Thanks.
> > >
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Apache Ignite contribution

[Maksim Stepachev]

Hello!

If you have the telegram, join to Russian channel: https://t.me/RU_Ignite

чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev :

> Hello!
>
> I have added you to Contributors of our project, you can now assign issues
> to yourself.
>
> Please read
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 23 янв. 2020 г. в 15:31, Лев Киселев :
>
> > Hello,
> > I want to take part in the development of Apache Ignite.
> > Primary skills: Java SE, Java 8, Spring framework, SQL.
> > Also: Multithreading (incl. FJP), Design Patterns, Algorithms and Data
> > Structures.
> >
> > My JIRA ID: l4ndsc4pe
> >
> > Thanks.
> >
>

Re: Task to implement: IGNITE-12581

[Maksim Stepachev]

Hi,

I suppose you can.
Nikolay possibly may help with it.
If you have the telegram, join to Russian channel: https://t.me/RU_Ignite

вс, 26 янв. 2020 г. в 19:21, Vladimir Steshin :

> Hi everyone.
>
> How do you think, can I start this task:
> https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-12581 ?
>
> It looks useful and seems good for a newbie to begin researching the
> code and test techniques.
>
>

Re: Slim binary release and docker image for Apache Ignite

[Alexey Goncharuk]

Got it, sounds good!
Should we consider the list of modules included in the slim package
finalized?

чт, 16 янв. 2020 г. в 13:13, Igor Sapego :

> Alexey, if I understand correctly, Ilya does not suggest to pre-built
> binaries, just to ship it with configure script pre-generated, which
> is a common practice for autotools packages. Building will be still
> required for the user, but there will be less requirements and
> possible errors during build.
>
> I like the idea. Let's do this.
>
> Best Regards,
> Igor
>
>
> On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > To me it doesn't really matter if it will be 'slim' or 'lite' :) I would
> > not name it 'core' because indeed it would be confusing with the core
> > module name.
> >
> > Agree that platforms support is useful, so I would keep them as Ilya
> > suggested. As for the C++ packages pre-build - let's hear out Igor's
> > opinion on this. Pre-built binaries certainly add usability, but I am not
> > sure how those binaries should be tested afterwards.
> >
> > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov :
> >
> > > I'm +1 for "SLIM" it is a common name in Docker world.
> > >
> > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov 
> wrote:
> > >
> > > > +1 for slim binary
> > > > Plus docker-slim
> > > > Plus RPM / DEB packages modularisation like PHP distribution — with
> > core
> > > > and lots of integrations / modules.
> > > >
> > > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > I think we should name it "core" since we already have ignite-core
> > and
> > > it
> > > > > will be confusing. Maybe we should go full 00s and call it "lite"?
> > > > >
> > > > > I also think we should keep both .Net and C++. .Net is runnable out
> > of
> > > > box
> > > > > which is awesome, and C++ needs building but it is rather small in
> > > source
> > > > > form.
> > > > >
> > > > > I also suggest a different change to build process. Let's ship C++
> > with
> > > > > automake, etc, already run, for all binary packaging options?
> WDYT? I
> > > can
> > > > > assist in build process tuning.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> > > > >
> > > > >> Alex,
> > > > >>
> > > > >> I'm on your end and support the proposal. Could you also clarify
> if
> > > you
> > > > >> suggest we keeping or removing C++ and .NET thick clients?
> > > > >>
> > > > >> Speaking of the naming, how about titling such packages as 'core'
> > > > instead
> > > > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > > > >>
> > > > >>
> > > > >> -
> > > > >> Denis
> > > > >>
> > > > >>
> > > > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com
> > > > >>>
> > > > >> wrote:
> > > > >>
> > > > >>> Hello!
> > > > >>>
> > > > >>> Pavel, I believe these JARs are fully covered by the list of
> > modules
> > > > >>> specified above.
> > > > >>>
> > > > >>> Regards,
> > > > >>> --
> > > > >>> Ilya Kasnacheev
> > > > >>>
> > > > >>>
> > > > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn <
> ptupit...@apache.org
> > >:
> > > > >>>
> > > >  I like the idea, current distribution is certainly too big.
> > > > 
> > > >  Here is a list of jar files we include in NuGet package:
> > > > 
> > > >  cache-api-1.0.0.jar
> > > >  commons-codec-1.11.jar
> > > >  commons-logging-1.1.1.jar
> > > >  h2-1.4.197.jar
> > > >  ignite-core-2.9.0-SNAPSHOT.jar
> > > >  ignite-indexing-2.9.0-SNAPSHOT.jar
> > > >  ignite-shmem-1.0.0.jar
> > > >  ignite-spring-2.9.0-SNAPSHOT.jar
> > > >  lucene-analyzers-common-7.4.0.jar
> > > >  lucene-core-7.4.0.jar
> > > >  lucene-queryparser-7.4.0.jar
> > > >  spring-aop-4.3.18.RELEASE.jar
> > > >  spring-beans-4.3.18.RELEASE.jar
> > > >  spring-context-4.3.18.RELEASE.jar
> > > >  spring-core-4.3.18.RELEASE.jar
> > > >  spring-expression-4.3.18.RELEASE.jar
> > > >  spring-jdbc-4.3.18.RELEASE.jar
> > > >  spring-tx-4.3.18.RELEASE.jar
> > > > 
> > > >  Those are required for SQL and Spring configs to work properly,
> > > >  maybe we want to include them into the slim distro as well.
> > > > 
> > > >  On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > > > >>> ilya.kasnach...@gmail.com
> > > > >
> > > >  wrote:
> > > > 
> > > > > Hello!
> > > > >
> > > > > This is a reasonable idea.
> > > > >
> > > > > I think we should also drop benchmarks/ directory from that
> > build,
> > > > >> it's
> > > >  60M
> > > > > of (potentially vulnerable) JARs that are not needed by an
> > average
> > > > > developer's use cases.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > ср, 15 янв. 2020 г. в 13:10, Alexey 

[jira] [Created] (IGNITE-12582) It is needed to set used cache for Spring Data by property

[Sergey Chernolyas (Jira)]

Sergey Chernolyas created IGNITE-12582:
--

 Summary: It is needed to set used cache  for Spring Data  by 
property
 Key: IGNITE-12582
 URL: https://issues.apache.org/jira/browse/IGNITE-12582
 Project: Ignite
  Issue Type: Improvement
  Components: spring
Affects Versions: 2.7.6
Reporter: Sergey Chernolyas
Assignee: Sergey Chernolyas


Hi!

My project needs to configure  used  cache by property, like 
""[spring.data|http://spring.data/].mongodb.uri: 
mongodb://:@:/" from Spring Data for MongoDB. 
Now, I can set cache for particular repository by annotation "RepositoryConfig" 
only.



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