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

[Maxim Muzafarov]

Ilya,


+1 to disable auto-adjustment by default
It seems the same approach can be used as implemented for disabling
pme-free [1].

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

On Wed, 29 Jan 2020 at 20:16, Ilya Kasnacheev 
wrote:

> Hello!
>
> Actually, it seems to me that such scenario "Joining persistence node to
> in-memory cluster" is not really supported in either 2.7.6 or 2.8.
>
> I suggest disabling it for good. What do you think? Nobody ever told us
> that it is broken, we can assume noone ever wanted that. We have no test
> coverage for it.
>
> Still, I think that baseline auto-adjust should not be enabled by default,
> since it is not configurable via IgniteConfiguration.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 29 янв. 2020 г. в 16:14, Ilya Kasnacheev :
>
> > Hello!
> >
> > I have just promoted https://issues.apache.org/jira/browse/IGNITE-12504
> > to Blocker.
> >
> > The reasoning for this, you can't seem to configure baseline auto-adjust
> > until your node is up (there is no configuration for this), and it will
> > refuse nodes joining outright with default configuration, making it
> > impossible to assemble some clusters. I will file a separate ticket about
> > that.
> >
> > "Caused by: class org.apache.ignite.spi.IgniteSpiException: Joining
> > persistence node to in-memory cluster couldn't be allowed due to baseline
> > auto-adjust is enabled and timeout equal to 0"
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 29 янв. 2020 г. в 14:33, Andrey Gura :
> >
> >> Hi,
> >>
> >> one more issue which should be fixed in 2.8 release [1]
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12598
> >>
> >> On Tue, Jan 28, 2020 at 7:29 PM Maxim Muzafarov 
> >> wrote:
> >> >
> >> > Igniters,
> >> >
> >> >
> >> > Here is the list of actual release BLOCKER issues:
> >> >
> >> > [1] Keep in mind unfinished discussion about internal classes
> >> > IGNITE-12456 [2] Cluster Data Store grid gets Corrupted for Load test
> >> > *[Unassigned]* OPEN
> >> > IGNITE-12398 Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes
> >> getting
> >> > down [Emmanouil Gkatziouras] IN PROGRESS
> >> > IGNITE-12580 NPE in GridMetricManager [Nikolay Izhikov] PATCH
> AVAILABLE
> >> > IGNITE-12489 Error during purges by expiration: Unknown page type
> [Anton
> >> > Kalashnikov] OPEN
> >> >
> >> > [1]
> >> >
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html
> >> > [2] https://issues.apache.org/jira/browse/IGNITE-12456
> >> > [3] https://issues.apache.org/jira/browse/IGNITE-12398
> >> > [4] https://issues.apache.org/jira/browse/IGNITE-12580
> >> > [5] https://issues.apache.org/jira/browse/IGNITE-12489
> >> >
> >> >
> >> > On Tue, 28 Jan 2020 at 19:25, Maxim Muzafarov 
> >> wrote:
> >> >
> >> > > Andrey,
> >> > >
> >> > > I've looked through those changes [1] and now they look good to me.
> >> > > Let's do the following:
> >> > >
> >> > > 1. Get a fresh TC.Bot visa
> >> > > 2. Merge these changes to the master branch.
> >> > > 3. After that and 3-day stabilization cherry-pick to 2.8
> >> > >
> >> > > Should we wait for benchmarks? I think at this release stage any
> >> > > additional benchmarks can eliminate our risks with extending scope.
> >> > > We've already had one - [2] (2.7.6 compared to 2.8).
> >> > >
> >> > >
> >> > > [1] https://issues.apache.org/jira/browse/IGNITE-12576
> >> > > [2]
> >> > >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Benchmarks
> >> > >
> >> > > On Mon, 27 Jan 2020 at 23:58, Nikolay Izhikov 
> >> wrote:
> >> > > >
> >> > > > 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 

Re: Ignite Extension - TC link

[Nikolay Izhikov]

I don’t have permissions for this project.

Please, give me admin access for it.
I want to setup tests for the new spring auto configure modules.

> 30 янв. 2020 г., в 05:11, Saikat Maitra  написал(а):
> 
> Hi Nikolay,
> 
> Please find the TC link below 
> 
> https://ci.ignite.apache.org/project.html?projectId=IgniteExtensions&tab=projectOverview
> 
> Regards,
> Saikat
> 
> On Wed, Jan 29, 2020 at 5:26 AM Nikolay Izhikov  wrote:
> Hello, Igniters.
> 
> Can you, please, give me a link to the «Ignite Extension» project on the TC?

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Alexey Goncharuk]

Nikolay,

Inactive state deallocates all possible resources by design, including the
data regions. If data region is not backed by a persistent storage, the
data is lost, this is an expected behavior.

ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov :

> Hello, Igniters.
>
> I found really confusing results of the simple test.
> Data from the in-memory cache are vanished after change cluster state to
> INACTIVE/ACTIVE.
>
> Is this a bug or expected behavior?
>
>
> ```
> public class ClusterDeactivateTest extends GridCommonAbstractTest {
> String name = "my-cache";
>
> /** */
> @Test
> public void testDataPresent() throws Exception {
> IgniteEx i = startGrid(0);
>
> i.createCache(name).put(1L, 1L);
>
> assertEquals(1L, i.cache(name).get(1L));
>
> i.cluster().state(ClusterState.INACTIVE);
> i.cluster().state(ClusterState.ACTIVE);
>
> assertEquals(1L, i.cache(name).get(1L)); //Assertion error here!
> }
> }
> ```

Re: Internal classes are exposed in public API

[Alexey Goncharuk]

Folks,

I tried to re-read the whole thread and honestly got lost at the end :) Do
we have a consensus (if yes, what are the steps?) or should we have a call
as Maxim suggested?

I think it is in our best interest to get this agreed upon fast to release
AI 2.8 soon.

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

[Alexey Goncharuk]

Maxim,

I received no updates from the IGNITE-12456 reporter and from the ticket
description it does not look like a corruption, so I'm moving this ticket
to 2.9 (or 2.8.1 if it will be required).

Anton,

Do you have any updates on IGNITE-12489?

вт, 28 янв. 2020 г. в 19:29, Maxim Muzafarov :

> Igniters,
>
>
> Here is the list of actual release BLOCKER issues:
>
> [1] Keep in mind unfinished discussion about internal classes
> IGNITE-12456 [2] Cluster Data Store grid gets Corrupted for Load test
> *[Unassigned]* OPEN
> IGNITE-12398 Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting
> down [Emmanouil Gkatziouras] IN PROGRESS
> IGNITE-12580 NPE in GridMetricManager [Nikolay Izhikov] PATCH AVAILABLE
> IGNITE-12489 Error during purges by expiration: Unknown page type [Anton
> Kalashnikov] OPEN
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html
> [2] https://issues.apache.org/jira/browse/IGNITE-12456
> [3] https://issues.apache.org/jira/browse/IGNITE-12398
> [4] https://issues.apache.org/jira/browse/IGNITE-12580
> [5] https://issues.apache.org/jira/browse/IGNITE-12489
>
>
> On Tue, 28 Jan 2020 at 19:25, Maxim Muzafarov  wrote:
>
> > Andrey,
> >
> > I've looked through those changes [1] and now they look good to me.
> > Let's do the following:
> >
> > 1. Get a fresh TC.Bot visa
> > 2. Merge these changes to the master branch.
> > 3. After that and 3-day stabilization cherry-pick to 2.8
> >
> > Should we wait for benchmarks? I think at this release stage any
> > additional benchmarks can eliminate our risks with extending scope.
> > We've already had one - [2] (2.7.6 compared to 2.8).
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12576
> > [2]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Benchmarks
> >
> > On Mon, 27 Jan 2020 at 23:58, Nikolay Izhikov 
> wrote:
> > >
> > > 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 <
> nizhi...@apache.org>
> > 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 <
> nizhi...@apache.org>
> > wrote:
> > > 

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Nikolay Izhikov]

Hello, Alexey.

Thanks for the feedback.
It seems for me as a very unexpected behavior from the users point of view.

I propose to do the following:

* Update Ignite documentation and write down the fact that in-memory cache 
cleared on deactivation.
* Disallow, by default, deactivation of the cluster that has in-memory cache 
with proper error message
«Your cluster has in-memory cache configured. During deactivation all 
data from these caches will be cleared!»
* Add «—force» flag to deactivate command so administrator can force 
deactivation for cluster that has both - persistent and in-memory caches 
configured.

What do you think?


> 30 янв. 2020 г., в 12:32, Alexey Goncharuk  
> написал(а):
> 
> Nikolay,
> 
> Inactive state deallocates all possible resources by design, including the
> data regions. If data region is not backed by a persistent storage, the
> data is lost, this is an expected behavior.
> 
> ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov :
> 
>> Hello, Igniters.
>> 
>> I found really confusing results of the simple test.
>> Data from the in-memory cache are vanished after change cluster state to
>> INACTIVE/ACTIVE.
>> 
>> Is this a bug or expected behavior?
>> 
>> 
>> ```
>> public class ClusterDeactivateTest extends GridCommonAbstractTest {
>>String name = "my-cache";
>> 
>>/** */
>>@Test
>>public void testDataPresent() throws Exception {
>>IgniteEx i = startGrid(0);
>> 
>>i.createCache(name).put(1L, 1L);
>> 
>>assertEquals(1L, i.cache(name).get(1L));
>> 
>>i.cluster().state(ClusterState.INACTIVE);
>>i.cluster().state(ClusterState.ACTIVE);
>> 
>>assertEquals(1L, i.cache(name).get(1L)); //Assertion error here!
>>}
>> }
>> ```

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Alexey Goncharuk]

Nikolay,

This change will affect only the command-line utility, correct? No changes
for the public API are planned?

чт, 30 янв. 2020 г. в 12:46, Nikolay Izhikov :

> Hello, Alexey.
>
> Thanks for the feedback.
> It seems for me as a very unexpected behavior from the users point of view.
>
> I propose to do the following:
>
> * Update Ignite documentation and write down the fact that in-memory cache
> cleared on deactivation.
> * Disallow, by default, deactivation of the cluster that has in-memory
> cache with proper error message
> «Your cluster has in-memory cache configured. During deactivation
> all data from these caches will be cleared!»
> * Add «—force» flag to deactivate command so administrator can force
> deactivation for cluster that has both - persistent and in-memory caches
> configured.
>
> What do you think?
>
>
> > 30 янв. 2020 г., в 12:32, Alexey Goncharuk 
> написал(а):
> >
> > Nikolay,
> >
> > Inactive state deallocates all possible resources by design, including
> the
> > data regions. If data region is not backed by a persistent storage, the
> > data is lost, this is an expected behavior.
> >
> > ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov :
> >
> >> Hello, Igniters.
> >>
> >> I found really confusing results of the simple test.
> >> Data from the in-memory cache are vanished after change cluster state to
> >> INACTIVE/ACTIVE.
> >>
> >> Is this a bug or expected behavior?
> >>
> >>
> >> ```
> >> public class ClusterDeactivateTest extends GridCommonAbstractTest {
> >>String name = "my-cache";
> >>
> >>/** */
> >>@Test
> >>public void testDataPresent() throws Exception {
> >>IgniteEx i = startGrid(0);
> >>
> >>i.createCache(name).put(1L, 1L);
> >>
> >>assertEquals(1L, i.cache(name).get(1L));
> >>
> >>i.cluster().state(ClusterState.INACTIVE);
> >>i.cluster().state(ClusterState.ACTIVE);
> >>
> >>assertEquals(1L, i.cache(name).get(1L)); //Assertion error here!
> >>}
> >> }
> >> ```
>
>

[IGNITE-12582] Configuration by property

[Sergey Chernolyas]

Hi igniters!

I would ask you to estimate the proposed solution and say how correct is.
It is proposed to set repository name by Spring Expression Language.
But ... it leads one question for discussion.
Where do we need to write the expression?
I see two options:
1) at field "cacheName". The code will analyse type of content (clear
string or expression)
2) at new field.
I mean annotation
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/springdata20/repository/config/RepositoryConfig.html


-- 
-

With best regards, Sergey Chernolyas

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Nikolay Izhikov]

As far as I know we have several places to manage cluster state:

1. Java API - Ignite#cluster#state
2. CLI utility - control.sh
3. JMX beans(can we manage cluster state from JMX?)

I think we should add new parameter to the all management APIs.

What do you think?

> 30 янв. 2020 г., в 12:51, Alexey Goncharuk  
> написал(а):
> 
> Nikolay,
> 
> This change will affect only the command-line utility, correct? No changes
> for the public API are planned?
> 
> чт, 30 янв. 2020 г. в 12:46, Nikolay Izhikov :
> 
>> Hello, Alexey.
>> 
>> Thanks for the feedback.
>> It seems for me as a very unexpected behavior from the users point of view.
>> 
>> I propose to do the following:
>> 
>> * Update Ignite documentation and write down the fact that in-memory cache
>> cleared on deactivation.
>> * Disallow, by default, deactivation of the cluster that has in-memory
>> cache with proper error message
>>«Your cluster has in-memory cache configured. During deactivation
>> all data from these caches will be cleared!»
>> * Add «—force» flag to deactivate command so administrator can force
>> deactivation for cluster that has both - persistent and in-memory caches
>> configured.
>> 
>> What do you think?
>> 
>> 
>>> 30 янв. 2020 г., в 12:32, Alexey Goncharuk 
>> написал(а):
>>> 
>>> Nikolay,
>>> 
>>> Inactive state deallocates all possible resources by design, including
>> the
>>> data regions. If data region is not backed by a persistent storage, the
>>> data is lost, this is an expected behavior.
>>> 
>>> ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov :
>>> 
 Hello, Igniters.
 
 I found really confusing results of the simple test.
 Data from the in-memory cache are vanished after change cluster state to
 INACTIVE/ACTIVE.
 
 Is this a bug or expected behavior?
 
 
 ```
 public class ClusterDeactivateTest extends GridCommonAbstractTest {
   String name = "my-cache";
 
   /** */
   @Test
   public void testDataPresent() throws Exception {
   IgniteEx i = startGrid(0);
 
   i.createCache(name).put(1L, 1L);
 
   assertEquals(1L, i.cache(name).get(1L));
 
   i.cluster().state(ClusterState.INACTIVE);
   i.cluster().state(ClusterState.ACTIVE);
 
   assertEquals(1L, i.cache(name).get(1L)); //Assertion error here!
   }
 }
 ```
>> 
>> 

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Alexey Goncharuk]

I agree on CLI and JMX because those interfaces can be used by a system
administrator and can be invoked by mistake.

As for the Java API, personally, I find it strange to add 'force' or
'confirm' flags to it because it is very unlikely that such an invocation
is done by mistake. Such mistakes are caught during the testing phase and
developers will end up hard-coding 'true' as a flag anyways.

[IGNITE-12582] Configuration by property

[Sergey Chernolyas]

Hi igniters!

Presently, Spring Data for Ignite can't be configured dynamically. I mean ,
than I defines repository by the code:

@Repository
@RepositoryConfig(cacheName = "Calendar")
public interface CalendarRepository extends IgniteRepository {
List findByName(String name);
}

But I need to configure used cache dynamically ( at runtime). To solve
this problem is proposed to use Spring Expression Language. By the
way, I will have possibility to use the code:

@Repository
@RepositoryConfig(cacheName = "${cache.calendar.name}")
public interface CalendarRepository extends IgniteRepository {
List findByName(String name);
}

And property "cache.calendar.name" can be configured as usual property
at Spring Framework.

But way brakes current configuration way and I would ask about how we
can set cache name by  expression or constant string.

I see options:

1) field "cacheName" will be able to process expression and constant
string. The code of repository factory will analyse the field.

2) create new field for expressions


What is best way?


-- 
-

With best regards, Sergey Chernolyas

Contribution

[Лев Киселев]

Hello everyone, I have question about following task:
[https://issues.apache.org/jira/browse/IGNITE-10698]
Solution proposed in task description is seem to be logical.
So, I need to every replace @MXBeanParametersNames and
@MXBeanParametersDescriptions (everywhere, for uniformity) with something
like:
void methodName(@MXBeanParameterInformation(name = "name", description =
"description") firstParameter, ...) {}.
And, of course, need to change processing logic at
getParameterName/getDescription methods from IgniteStandardMXBean.
Do I understand correctly what needs to be done?

Re: [DISCUSS] Merge PR via GitHub web UI

[Pavel Tupitsyn]

It's done, only Squash mode is enabled in GitHub UI.

On Mon, Jan 27, 2020 at 5:05 PM Pavel Tupitsyn  wrote:

> 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 <
>> ptupit...@apache.org>
>> > > 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: [DISCUSS] Merge PR via GitHub web UI

[Ivan Pavlukhin]

Great news! Thank you Pavel!

чт, 30 янв. 2020 г. в 14:14, Pavel Tupitsyn :
>
> It's done, only Squash mode is enabled in GitHub UI.
>
> On Mon, Jan 27, 2020 at 5:05 PM Pavel Tupitsyn  wrote:
>
> > 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 <
> >> ptupit...@apache.org>
> >> > > 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
> >> >
> >>
> >



-- 
Best regards,
Ivan Pavlukhin

Re: Internal classes are exposed in public API

[Andrey Gura]

>From my point of view we still don't have consensus.

I think we should do at least the following:

1. Remove @Deprecated from old API (because it strange to have one
deprecated API and second experimental API)
2. Add @IgniteExperimetnal to new API (because... see item. 1)
3. Do not merge IGNITE-12553 (because it adds new public interface
that 100% will be changed)

ideally we should also:

4. Add metrics that available only via new API to the old API (because
otherwise we force user interact with both API's)

On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
 wrote:
>
> Folks,
>
> I tried to re-read the whole thread and honestly got lost at the end :) Do
> we have a consensus (if yes, what are the steps?) or should we have a call
> as Maxim suggested?
>
> I think it is in our best interest to get this agreed upon fast to release
> AI 2.8 soon.

[jira] [Created] (IGNITE-12607) PartitionsExchangeAwareTest is flaky

[Ivan Rakov (Jira)]

Ivan Rakov created IGNITE-12607:
---

 Summary: PartitionsExchangeAwareTest is flaky
 Key: IGNITE-12607
 URL: https://issues.apache.org/jira/browse/IGNITE-12607
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.9


Proof: 
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6/4972239
Seems like cache update sometimes is not possible even before topologies are 
locked.



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

Re: Internal classes are exposed in public API

[Nikolay Izhikov]

Hello.

> 2. Add @IgniteExperimetnal to new API (because... see item. 1

+1

> 1. Remove @Deprecated from old API (because it strange to have one deprecated 
> API and second experimental API)

-1

I propose to update deprecation message and provide metric name for each 
deprecated method.

> @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the metric 
> «io.dataregion.pageCount»

Andrey.

We doesn’t come to an agreement that API should be changed.
We should discuss the design of the Metric API and your proposals for it in 
another thread.

Please, avoid arguments like «this API will be 100% changed» in this discussion.

> 30 янв. 2020 г., в 14:21, Andrey Gura  написал(а):
> 
> From my point of view we still don't have consensus.
> 
> I think we should do at least the following:
> 
> 1. Remove @Deprecated from old API (because it strange to have one
> deprecated API and second experimental API)
> 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> 3. Do not merge IGNITE-12553 (because it adds new public interface
> that 100% will be changed)
> 
> ideally we should also:
> 
> 4. Add metrics that available only via new API to the old API (because
> otherwise we force user interact with both API's)
> 
> On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
>  wrote:
>> 
>> Folks,
>> 
>> I tried to re-read the whole thread and honestly got lost at the end :) Do
>> we have a consensus (if yes, what are the steps?) or should we have a call
>> as Maxim suggested?
>> 
>> I think it is in our best interest to get this agreed upon fast to release
>> AI 2.8 soon.

[jira] [Created] (IGNITE-12608) [ignite-extensions] Setup tests for ignite-client-spring-boot-autoconfigure, ignite-spring-boot-autoconfigure on TC

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12608:


 Summary: [ignite-extensions] Setup tests for 
ignite-client-spring-boot-autoconfigure, ignite-spring-boot-autoconfigure on TC
 Key: IGNITE-12608
 URL: https://issues.apache.org/jira/browse/IGNITE-12608
 Project: Ignite
  Issue Type: Improvement
Reporter: Nikolay Izhikov


It seems we should update JUnit version to run spring tests on TC



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

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

[Alexey Goncharuk]

Anton, thanks, the changes and suggestion look good to me.

Maxim, folks, do you mind if I cherry-pick the changes to ignite-2.8 and
move the original ticket to 2.9?

чт, 30 янв. 2020 г. в 13:16, Anton Kalashnikov :

> Hello,
>
> I spent some time investigating IGNITE-12489
> , but unfortunately,
> there are not enough details on the ticket. Also, all reproducers, which I
> have now, able to reproduce a couple of other problems(IGNITE-12593
> , IGNITE-12594
> ) but not a source
> one.
>
> I offer the following actions:
> 1) Moving IGNITE-12489 to 2.9 due to we still don't have the reproducer,
> also we don't have details enough of this corruption and there is a
> high possibility that it has already fixed by other tickets(we have several
> tickets with corruption fix in 2.8)
> 2) Adding above mention tickets(IGNITE-12593, IGNITE-12594) to 2.8. They
> have been already finished and if the review is ok we can merge it today.
> This fixes also possible can fix  IGNITE-12489 due to they were reproduced
> by the reproducer of this ticket.
>
> Alexey Goncharuk, can you take a look at IGNITE-12593 and IGNITE-12594,
> please.
>
>
> --
> Best regards,
> Anton Kalashnikov
>
>
>
> 30.01.2020, 12:40, "Alexey Goncharuk" :
>
> Maxim,
>
> I received no updates from the IGNITE-12456 reporter and from the ticket
> description it does not look like a corruption, so I'm moving this ticket
> to 2.9 (or 2.8.1 if it will be required).
>
> Anton,
>
> Do you have any updates on IGNITE-12489?
>
> вт, 28 янв. 2020 г. в 19:29, Maxim Muzafarov :
>
> Igniters,
>
>
> Here is the list of actual release BLOCKER issues:
>
> [1] Keep in mind unfinished discussion about internal classes
> IGNITE-12456 [2] Cluster Data Store grid gets Corrupted for Load test
> *[Unassigned]* OPEN
> IGNITE-12398 Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting
> down [Emmanouil Gkatziouras] IN PROGRESS
> IGNITE-12580 NPE in GridMetricManager [Nikolay Izhikov] PATCH AVAILABLE
> IGNITE-12489 Error during purges by expiration: Unknown page type [Anton
> Kalashnikov] OPEN
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html
> [2] https://issues.apache.org/jira/browse/IGNITE-12456
> [3] https://issues.apache.org/jira/browse/IGNITE-12398
> [4] https://issues.apache.org/jira/browse/IGNITE-12580
> [5] https://issues.apache.org/jira/browse/IGNITE-12489
>
>
> On Tue, 28 Jan 2020 at 19:25, Maxim Muzafarov  wrote:
>
> > Andrey,
> >
> > I've looked through those changes [1] and now they look good to me.
> > Let's do the following:
> >
> > 1. Get a fresh TC.Bot visa
> > 2. Merge these changes to the master branch.
> > 3. After that and 3-day stabilization cherry-pick to 2.8
> >
> > Should we wait for benchmarks? I think at this release stage any
> > additional benchmarks can eliminate our risks with extending scope.
> > We've already had one - [2] (2.7.6 compared to 2.8).
> >
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12576
> > [2]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Benchmarks
> >
> > On Mon, 27 Jan 2020 at 23:58, Nikolay Izhikov 
> wrote:
> > >
> > > 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, 

Re: Internal classes are exposed in public API

[Maxim Muzafarov]

Igniters,


How about to start a vote (formal) over the whole community to choose
between these two options we have? With one caveat that veto votes are not
applicable to this discussion. Let the whole community decide what
direction we should move on.

On Thu, 30 Jan 2020 at 14:34, Nikolay Izhikov  wrote:

> Hello.
>
> > 2. Add @IgniteExperimetnal to new API (because... see item. 1
>
> +1
>
> > 1. Remove @Deprecated from old API (because it strange to have one
> deprecated API and second experimental API)
>
> -1
>
> I propose to update deprecation message and provide metric name for each
> deprecated method.
>
> > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the metric
> «io.dataregion.pageCount»
>
> Andrey.
>
> We doesn’t come to an agreement that API should be changed.
> We should discuss the design of the Metric API and your proposals for it
> in another thread.
>
> Please, avoid arguments like «this API will be 100% changed» in this
> discussion.
>
> > 30 янв. 2020 г., в 14:21, Andrey Gura  написал(а):
> >
> > From my point of view we still don't have consensus.
> >
> > I think we should do at least the following:
> >
> > 1. Remove @Deprecated from old API (because it strange to have one
> > deprecated API and second experimental API)
> > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > that 100% will be changed)
> >
> > ideally we should also:
> >
> > 4. Add metrics that available only via new API to the old API (because
> > otherwise we force user interact with both API's)
> >
> > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> >  wrote:
> >>
> >> Folks,
> >>
> >> I tried to re-read the whole thread and honestly got lost at the end :)
> Do
> >> we have a consensus (if yes, what are the steps?) or should we have a
> call
> >> as Maxim suggested?
> >>
> >> I think it is in our best interest to get this agreed upon fast to
> release
> >> AI 2.8 soon.
>
>

Re: [MTCGA]: new failures in builds [4939116] needs to be handled

[Maxim Muzafarov]

Igniters,


It seems that the issue will be solved under [1] JIRA ticket.


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


On Fri, 24 Jan 2020 at 15:06, Maxim Muzafarov  wrote:
>
> Folks,
>
>
> This test began to constantly fail in the master branch [2] and the
> 2.8 [1] also. It seems it's related to the [3] issue (IGNITE-12531:
> Cluster is unable to change BLT on 2.8 if storage was initially
> created on 2.7 or less) which have been recently fixed and
> cherry-picked to 2.8.
>
> Can you please double-check you commit?
>
>
> [1] 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5923369202582779855&branch=%3Cdefault%3E&tab=testDetails&branch_IgniteTests24Java8=ignite-2.8
> [2] 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5923369202582779855&branch=%3Cdefault%3E&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E
> [3] https://issues.apache.org/jira/browse/IGNITE-12531
>
> On Sat, 18 Jan 2020 at 14:41,  wrote:
> >
> > Hi Igniters,
> >
> >  I've detected some new issue on TeamCity to be handled. You are more than 
> > welcomed to help.
> >
> >  If your changes can lead to this failure(s): We're grateful that you were 
> > a volunteer to make the contribution to this project, but things change and 
> > you may no longer be able to finalize your contribution.
> >  Could you respond to this email and indicate if you wish to continue and 
> > fix test failures or step down and some committer may revert you commit.
> >
> >  *New test failure in master-nightly 
> > DistributedMetaStoragePersistentTest.testUnstableTopology 
> > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5923369202582779855&branch=%3Cdefault%3E&tab=testDetails
> >  Changes may lead to failure were done by
> >  - maxim muzafarov  
> > https://ci.ignite.apache.org/viewModification.html?modId=895676
> >  - aleksei scherbakov  
> > https://ci.ignite.apache.org/viewModification.html?modId=895694
> >  - denis garus  
> > https://ci.ignite.apache.org/viewModification.html?modId=895630
> >  - slava koptilin  
> > https://ci.ignite.apache.org/viewModification.html?modId=895689
> >  - slava koptilin  
> > https://ci.ignite.apache.org/viewModification.html?modId=895688
> >  - evgeny stanilovskiy  
> > https://ci.ignite.apache.org/viewModification.html?modId=895672
> >  - andrew v. mashenkov  
> > https://ci.ignite.apache.org/viewModification.html?modId=895683
> >
> >  - Here's a reminder of what contributors were agreed to do 
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> >  - Should you have any questions please contact 
> > dev@ignite.apache.org
> >
> > Best Regards,
> > Apache Ignite TeamCity Bot
> > https://github.com/apache/ignite-teamcity-bot
> > Notification generated at 14:41:19 18-01-2020

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

[Maxim Muzafarov]

Alexey,


Let's merge these issues [1] [2] to the master branch first and wait
for a couple of days to collect test statistics.

My fears based on the fact not getting new regression flaky failures
for the release branch as we've got here [3] [4].


[1] https://issues.apache.org/jira/browse/IGNITE-12593
[2] https://issues.apache.org/jira/browse/IGNITE-12594
[3] https://issues.apache.org/jira/browse/IGNITE-12227
[4] 
http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-4939116-needs-to-be-handled-td45199.html



On Thu, 30 Jan 2020 at 14:45, Alexey Goncharuk
 wrote:
>
> Anton, thanks, the changes and suggestion look good to me.
>
> Maxim, folks, do you mind if I cherry-pick the changes to ignite-2.8 and
> move the original ticket to 2.9?
>
> чт, 30 янв. 2020 г. в 13:16, Anton Kalashnikov :
>
> > Hello,
> >
> > I spent some time investigating IGNITE-12489
> > , but unfortunately,
> > there are not enough details on the ticket. Also, all reproducers, which I
> > have now, able to reproduce a couple of other problems(IGNITE-12593
> > , IGNITE-12594
> > ) but not a source
> > one.
> >
> > I offer the following actions:
> > 1) Moving IGNITE-12489 to 2.9 due to we still don't have the reproducer,
> > also we don't have details enough of this corruption and there is a
> > high possibility that it has already fixed by other tickets(we have several
> > tickets with corruption fix in 2.8)
> > 2) Adding above mention tickets(IGNITE-12593, IGNITE-12594) to 2.8. They
> > have been already finished and if the review is ok we can merge it today.
> > This fixes also possible can fix  IGNITE-12489 due to they were reproduced
> > by the reproducer of this ticket.
> >
> > Alexey Goncharuk, can you take a look at IGNITE-12593 and IGNITE-12594,
> > please.
> >
> >
> > --
> > Best regards,
> > Anton Kalashnikov
> >
> >
> >
> > 30.01.2020, 12:40, "Alexey Goncharuk" :
> >
> > Maxim,
> >
> > I received no updates from the IGNITE-12456 reporter and from the ticket
> > description it does not look like a corruption, so I'm moving this ticket
> > to 2.9 (or 2.8.1 if it will be required).
> >
> > Anton,
> >
> > Do you have any updates on IGNITE-12489?
> >
> > вт, 28 янв. 2020 г. в 19:29, Maxim Muzafarov :
> >
> > Igniters,
> >
> >
> > Here is the list of actual release BLOCKER issues:
> >
> > [1] Keep in mind unfinished discussion about internal classes
> > IGNITE-12456 [2] Cluster Data Store grid gets Corrupted for Load test
> > *[Unassigned]* OPEN
> > IGNITE-12398 Apache Ignite Cluster(Amazon S3 Based Discovery) Nodes getting
> > down [Emmanouil Gkatziouras] IN PROGRESS
> > IGNITE-12580 NPE in GridMetricManager [Nikolay Izhikov] PATCH AVAILABLE
> > IGNITE-12489 Error during purges by expiration: Unknown page type [Anton
> > Kalashnikov] OPEN
> >
> > [1]
> >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html
> > [2] https://issues.apache.org/jira/browse/IGNITE-12456
> > [3] https://issues.apache.org/jira/browse/IGNITE-12398
> > [4] https://issues.apache.org/jira/browse/IGNITE-12580
> > [5] https://issues.apache.org/jira/browse/IGNITE-12489
> >
> >
> > On Tue, 28 Jan 2020 at 19:25, Maxim Muzafarov  wrote:
> >
> > > Andrey,
> > >
> > > I've looked through those changes [1] and now they look good to me.
> > > Let's do the following:
> > >
> > > 1. Get a fresh TC.Bot visa
> > > 2. Merge these changes to the master branch.
> > > 3. After that and 3-day stabilization cherry-pick to 2.8
> > >
> > > Should we wait for benchmarks? I think at this release stage any
> > > additional benchmarks can eliminate our risks with extending scope.
> > > We've already had one - [2] (2.7.6 compared to 2.8).
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12576
> > > [2]
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Benchmarks
> > >
> > > On Mon, 27 Jan 2020 at 23:58, Nikolay Izhikov 
> > wrote:
> > > >
> > > > 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 t

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

[Alexey Goncharuk]

Sounds good, will do!

Re: Internal classes are exposed in public API

[Anton Vinogradov]

>> . Remove @Deprecated from old API (because it strange to have one
>> deprecated API and second experimental API)
>> 2. Add @IgniteExperimetnal to new API (because... see item. 1)
-1

We should have all the options.

Deprecated -> will be removed at major release (because this way is slow or
overcomplicated) but still be used now,
Annotation is absent -> just a stable (proper) API,
Experimental -> not stable yet or partially implemented or in fact an
experimental

On Thu, Jan 30, 2020 at 2:47 PM Maxim Muzafarov  wrote:

> Igniters,
>
>
> How about to start a vote (formal) over the whole community to choose
> between these two options we have? With one caveat that veto votes are not
> applicable to this discussion. Let the whole community decide what
> direction we should move on.
>
> On Thu, 30 Jan 2020 at 14:34, Nikolay Izhikov  wrote:
>
> > Hello.
> >
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1
> >
> > +1
> >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > deprecated API and second experimental API)
> >
> > -1
> >
> > I propose to update deprecation message and provide metric name for each
> > deprecated method.
> >
> > > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the
> metric
> > «io.dataregion.pageCount»
> >
> > Andrey.
> >
> > We doesn’t come to an agreement that API should be changed.
> > We should discuss the design of the Metric API and your proposals for it
> > in another thread.
> >
> > Please, avoid arguments like «this API will be 100% changed» in this
> > discussion.
> >
> > > 30 янв. 2020 г., в 14:21, Andrey Gura  написал(а):
> > >
> > > From my point of view we still don't have consensus.
> > >
> > > I think we should do at least the following:
> > >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > > deprecated API and second experimental API)
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > > that 100% will be changed)
> > >
> > > ideally we should also:
> > >
> > > 4. Add metrics that available only via new API to the old API (because
> > > otherwise we force user interact with both API's)
> > >
> > > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> > >  wrote:
> > >>
> > >> Folks,
> > >>
> > >> I tried to re-read the whole thread and honestly got lost at the end
> :)
> > Do
> > >> we have a consensus (if yes, what are the steps?) or should we have a
> > call
> > >> as Maxim suggested?
> > >>
> > >> I think it is in our best interest to get this agreed upon fast to
> > release
> > >> AI 2.8 soon.
> >
> >
>

Re: Internal classes are exposed in public API

[Alexey Goncharuk]

чт, 30 янв. 2020 г. в 15:18, Anton Vinogradov :

> We should have all the options.
>
> Deprecated -> will be removed at major release (because this way is slow or
> overcomplicated) but still be used now,
>

Not only does it mean that the API should be removed in a major release,
but there is a stable counterpart that can be used instead.


> Annotation is absent -> just a stable (proper) API,
> Experimental -> not stable yet or partially implemented or in fact an
> experimental
>

Looks like the formal vote is the only way to go now.

Re: Internal classes are exposed in public API

[Andrey Mashenkov]

Hi Igniters,

Let me share some thoughts. Abstractly.

1. @Experimental API. When user see API marked as experimental usually it
is a red flag for using such API in prod
and also he can't count the API stability:
- API itself if not stable and one can have compilation issues with next
versions at least
- API semantic can be changed that can cause full API usage revision and
even rewrite code that use this API.
So, user expects API (and its implementation) is offered to user e.g. to
check if some user issues can be resolved with new API
or e.g. for review to developers can get some feedback.

2. @Deprecated API. From my point of view: Deprecation is not about "we
mark code to inform user\dev about legacy".
When user see deprecation he interpret this as a strict directive to use a
new API.
He expects the API is still workable (unless there is no notes that API is
totaly broken of course), but definitely expects a new stable API must
exist.
It is ok if old API have less capabilities or even have huge limitations.


Concrete.
1. Let's mark new metrics API as Experimental. This allow us to add any
changes in future minor releases to resolve known issues.

2. AFAIR, we have strong commitment to not change\delete old API between
minor releases.
We can't mark old metrics as deprecated regarding user expectations
described before.

Let's make old API as deprecated in *one of future minor* release, once a
new one will be considered as *stable*.
I'm not sure we even can forbid anyone to contribute to old API for now and
then until (in 3.0) it will be decided old API for removal via Voting.



On Thu, Jan 30, 2020 at 2:47 PM Maxim Muzafarov  wrote:

> Igniters,
>
>
> How about to start a vote (formal) over the whole community to choose
> between these two options we have? With one caveat that veto votes are not
> applicable to this discussion. Let the whole community decide what
> direction we should move on.
>
> On Thu, 30 Jan 2020 at 14:34, Nikolay Izhikov  wrote:
>
> > Hello.
> >
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1
> >
> > +1
> >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > deprecated API and second experimental API)
> >
> > -1
> >
> > I propose to update deprecation message and provide metric name for each
> > deprecated method.
> >
> > > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the
> metric
> > «io.dataregion.pageCount»
> >
> > Andrey.
> >
> > We doesn’t come to an agreement that API should be changed.
> > We should discuss the design of the Metric API and your proposals for it
> > in another thread.
> >
> > Please, avoid arguments like «this API will be 100% changed» in this
> > discussion.
> >
> > > 30 янв. 2020 г., в 14:21, Andrey Gura  написал(а):
> > >
> > > From my point of view we still don't have consensus.
> > >
> > > I think we should do at least the following:
> > >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > > deprecated API and second experimental API)
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > > that 100% will be changed)
> > >
> > > ideally we should also:
> > >
> > > 4. Add metrics that available only via new API to the old API (because
> > > otherwise we force user interact with both API's)
> > >
> > > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> > >  wrote:
> > >>
> > >> Folks,
> > >>
> > >> I tried to re-read the whole thread and honestly got lost at the end
> :)
> > Do
> > >> we have a consensus (if yes, what are the steps?) or should we have a
> > call
> > >> as Maxim suggested?
> > >>
> > >> I think it is in our best interest to get this agreed upon fast to
> > release
> > >> AI 2.8 soon.
> >
> >
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Internal classes are exposed in public API

[Andrey Gura]

> We doesn’t come to an agreement that API should be changed.
> We should discuss the design of the Metric API and your proposals for it in 
> another thread.
> Please, avoid arguments like «this API will be 100% changed» in this 
> discussion.

I just explain why this item is acceptable to me. I don't discuss how
exactly something will changed, etc.

On Thu, Jan 30, 2020 at 2:34 PM Nikolay Izhikov  wrote:
>
> Hello.
>
> > 2. Add @IgniteExperimetnal to new API (because... see item. 1
>
> +1
>
> > 1. Remove @Deprecated from old API (because it strange to have one 
> > deprecated API and second experimental API)
>
> -1
>
> I propose to update deprecation message and provide metric name for each 
> deprecated method.
>
> > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the metric 
> > «io.dataregion.pageCount»
>
> Andrey.
>
> We doesn’t come to an agreement that API should be changed.
> We should discuss the design of the Metric API and your proposals for it in 
> another thread.
>
> Please, avoid arguments like «this API will be 100% changed» in this 
> discussion.
>
> > 30 янв. 2020 г., в 14:21, Andrey Gura  написал(а):
> >
> > From my point of view we still don't have consensus.
> >
> > I think we should do at least the following:
> >
> > 1. Remove @Deprecated from old API (because it strange to have one
> > deprecated API and second experimental API)
> > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > that 100% will be changed)
> >
> > ideally we should also:
> >
> > 4. Add metrics that available only via new API to the old API (because
> > otherwise we force user interact with both API's)
> >
> > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> >  wrote:
> >>
> >> Folks,
> >>
> >> I tried to re-read the whole thread and honestly got lost at the end :) Do
> >> we have a consensus (if yes, what are the steps?) or should we have a call
> >> as Maxim suggested?
> >>
> >> I think it is in our best interest to get this agreed upon fast to release
> >> AI 2.8 soon.
>

Re: Apache Ignite contribution

[Ivan Pavlukhin]

> 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")

"who could help me with this task" sounds very important to attract
new contributors. Regardless having channels for all kind of
communications I would consider exploring other channels (e.g.
aforementioned telegram) if it could help with new contributors
onboarding.

пн, 27 янв. 2020 г. в 21:22, 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
> > >
> >



-- 
Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-12609) SQL: GridReduceQueryExecutor refactoring.

[Andrey Mashenkov (Jira)]

Andrey Mashenkov created IGNITE-12609:
-

 Summary: SQL: GridReduceQueryExecutor refactoring.
 Key: IGNITE-12609
 URL: https://issues.apache.org/jira/browse/IGNITE-12609
 Project: Ignite
  Issue Type: Task
Reporter: Andrey Mashenkov


For now we have few issues that can be resolved.

1. We create fake H2 tables\indices for reduce stage even if there is no need 
to do so (skipMergeTable=true.
Let's decouple reduce logic from H2Index adapter code.

2. Partition mapping code look to complicated and non-optimal.
Let's use cached affinity mapping and avoid collections copying when possible.

3. Also there is no sense to pass RequestID to mapping code just for logging.
We'll never be able to match any request as no query really exists at a time 
when error with RequestID is logged.

4. Replicated only flag value semantic (calculation and usage) is not clear.

5. GridReduceQueryExecutor.reduce() method is too long (over 400 lines).



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

Re: Internal classes are exposed in public API

[Nikita Amelchev]

Folks,

I have some experience using the new metrics API. The new format is
easy to use from the user point and approved by the community. It
provides a single metric format and one entry point. I believe that
they are able to replace existing ones. I don't see any issues with
the new metrics. The MetricExporterSpi provides the ability to easily
migrate to the new format.

So, I suggest:
1. Do NOT mark the new metric API as IgniteExperimental.
2. Mark existing metrics with Deprecated annotation with reference on
how to use and migrate to the new metrics (without reference to
internal classes).

чт, 30 янв. 2020 г. в 16:02, Andrey Gura :
>
> > We doesn’t come to an agreement that API should be changed.
> > We should discuss the design of the Metric API and your proposals for it in 
> > another thread.
> > Please, avoid arguments like «this API will be 100% changed» in this 
> > discussion.
>
> I just explain why this item is acceptable to me. I don't discuss how
> exactly something will changed, etc.
>
> On Thu, Jan 30, 2020 at 2:34 PM Nikolay Izhikov  wrote:
> >
> > Hello.
> >
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1
> >
> > +1
> >
> > > 1. Remove @Deprecated from old API (because it strange to have one 
> > > deprecated API and second experimental API)
> >
> > -1
> >
> > I propose to update deprecation message and provide metric name for each 
> > deprecated method.
> >
> > > @deprecated Use {@link JmxMetricExporterSPI} instead. Name of the metric 
> > > «io.dataregion.pageCount»
> >
> > Andrey.
> >
> > We doesn’t come to an agreement that API should be changed.
> > We should discuss the design of the Metric API and your proposals for it in 
> > another thread.
> >
> > Please, avoid arguments like «this API will be 100% changed» in this 
> > discussion.
> >
> > > 30 янв. 2020 г., в 14:21, Andrey Gura  написал(а):
> > >
> > > From my point of view we still don't have consensus.
> > >
> > > I think we should do at least the following:
> > >
> > > 1. Remove @Deprecated from old API (because it strange to have one
> > > deprecated API and second experimental API)
> > > 2. Add @IgniteExperimetnal to new API (because... see item. 1)
> > > 3. Do not merge IGNITE-12553 (because it adds new public interface
> > > that 100% will be changed)
> > >
> > > ideally we should also:
> > >
> > > 4. Add metrics that available only via new API to the old API (because
> > > otherwise we force user interact with both API's)
> > >
> > > On Thu, Jan 30, 2020 at 12:35 PM Alexey Goncharuk
> > >  wrote:
> > >>
> > >> Folks,
> > >>
> > >> I tried to re-read the whole thread and honestly got lost at the end :) 
> > >> Do
> > >> we have a consensus (if yes, what are the steps?) or should we have a 
> > >> call
> > >> as Maxim suggested?
> > >>
> > >> I think it is in our best interest to get this agreed upon fast to 
> > >> release
> > >> AI 2.8 soon.
> >



-- 
Best wishes,
Amelchev Nikita

Re: Cache 6 suite is broken

[Ivan Pavlukhin]

Zhenya,

Good news! Could you please tell what is the root cause and how did you fix it?

вт, 28 янв. 2020 г. в 18:58, Zhenya Stanilovsky :
>
>
>
> Looks like i found problem root cause, first run completed on TC, hope it 
> would be ok with other builds.
>
> >
> >
> >--- Forwarded message ---
> >From: "Ivan Pavlukhin" < vololo...@gmail.com >
> >To: dev < dev@ignite.apache.org >
> >Cc:
> >Subject: Re: Cache 6 suite is broken
> >Date: Fri, 20 Dec 2019 10:04:07 +0300
> >
> >FYI
> >
> >I applied the patch.
> >
> >ср, 18 дек. 2019 г. в 14:46, Ivan Pavlukhin < vololo...@gmail.com >:
> >>
> >> So, if nobody objects, I will merge PR [1] on Friday.
> >>
> >> [1]  https://github.com/apache/ignite/pull/7142
> >>
> >> ср, 18 дек. 2019 г. в 13:13, Dmitriy Pavlov < dpav...@apache.org >:
> >> >
> >> > Hi Ivan, Igniters,
> >> >
> >> > My proposal is to apply PR and take a look to wider statistics in the
> >> > master branch. WDYT?
> >> >
> >> > Sincerely,
> >> > Dmitriy Pavlov
> >> >
> >> > ср, 18 дек. 2019 г. в 09:36, Ivan Pavlukhin < vololo...@gmail.com >:
> >> >
> >> > > Igniters,
> >> > >
> >> > > I run tests several times for my PR [1] and results [2] looks somehow
> >> > > better than in master [3]. But the problematic test seems too flaky.
> >> > > So, I cannot decide between 2 options:
> >> > > 1. Apply PR [1].
> >> > > 2. Ignore the problematic test.
> >> > > (Unfortunately do not have a chance to investigate and fix)
> >> > >
> >> > > Someone's opinion would be helpful here.
> >> > >
> >> > > [1]  https://github.com/apache/ignite/pull/7142
> >> > > [2]
> >> > >
> >>  
> >> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=pull%2F7142%2Fhead&buildTypeTab=overview
> >> > > [3]
> >> > >
> >>  
> >> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&buildTypeTab=overview
> >> > >
> >> > > пн, 16 дек. 2019 г. в 13:38, Ivan Pavlukhin < vololo...@gmail.com >:
> >> > > >
> >> > > > An update. After increasing NetworkTimeout [1] the test passes
> >> rarely
> >> > > [2].
> >> > > >
> >> > > > [1]  https://github.com/apache/ignite/pull/7142/files
> >> > > > [2]
> >> > >
> >>  
> >> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=pull%2F7142%2Fhead&buildTypeTab=overview
> >> > > >
> >> > > > пн, 16 дек. 2019 г. в 09:07, Ivan Pavlukhin < vololo...@gmail.com >:
> >> > > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > I noticied that Cache 6 suite finishes badly (exit code 137)
> >> almost
> >> > > > > everytime [1] on master. It started recently. A problematic test
> >> > > > > inside is IgniteCache150ClientsTest. I made some attempts to fix
> >> the
> >> > > > > test (including reverting recent commits), but had no luck. And
> >> a hard
> >> > > > > part here is that I do not know whether the issue was caused by
> >> code
> >> > > > > changes or it is infrastructural one. My best attempt was
> >> increasing
> >> > > > > NetworkTimeout in test IgniteConfiguration [2]. After that the
> >> suite
> >> > > > > was able to finish, but IgniteCache150ClientsTest failed. Also,
> >> the
> >> > > > > problematic test seems so flaky, there are many failures in
> >> history.
> >> > > > >
> >> > > > > Do not have any really good solution in my mind. I see following
> >> > > options:
> >> > > > > 1. Use workaround in PR [2].
> >> > > > > 2. Ignore test and dig deeper in scope of a separate ticket.
> >> > > > >
> >> > > > > What do you think?
> >> > > > >
> >> > > > > [1]
> >> > >
> >>  
> >> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&buildTypeTab=overview
> >> > > > > [2]  https://github.com/apache/ignite/pull/7142/files
> >> > > > > --
> >> > > > > Best regards,
> >> > > > > Ivan Pavlukhin
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Best regards,
> >> > > > Ivan Pavlukhin
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Best regards,
> >> > > Ivan Pavlukhin
> >> > >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Ivan Pavlukhin
>
>
>
>



-- 
Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-12610) Disable H2 object cache reliably

[Ivan Pavlukhin (Jira)]

Ivan Pavlukhin created IGNITE-12610:
---

 Summary: Disable H2 object cache reliably
 Key: IGNITE-12610
 URL: https://issues.apache.org/jira/browse/IGNITE-12610
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8
Reporter: Ivan Pavlukhin
 Fix For: 2.9


Internally H2 maintains a cache of {{org.h2.value.Value}} objects. It can be 
disabled by using "h2.objectCache" system property. There is a clear intent to 
disable this cache because the system property is set to "false" in 
{{org.apache.ignite.internal.processors.query.h2.ConnectionManager}}. But 
apparently it is too late, because the property is read by H2 internals before 
it. Consequently the object cache is enabled by default.

We need to set this property earlier.



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

Re: [IGNITE-12582] Configuration by property

[Seliverstov Igor]

Isn't a better way just to add a new annotation?

Like RepositoryConfig but from v2 package for example.

This case whose who already use it won't suffer.

Also it's would be great to provide a way to escape constants which are
similar to spel expressions.

Regards,
Igor

чт, 30 янв. 2020 г., 13:18 Sergey Chernolyas :

> Hi igniters!
>
> Presently, Spring Data for Ignite can't be configured dynamically. I mean ,
> than I defines repository by the code:
>
> @Repository
> @RepositoryConfig(cacheName = "Calendar")
> public interface CalendarRepository extends IgniteRepository String> {
> List findByName(String name);
> }
>
> But I need to configure used cache dynamically ( at runtime). To solve
> this problem is proposed to use Spring Expression Language. By the
> way, I will have possibility to use the code:
>
> @Repository
> @RepositoryConfig(cacheName = "${cache.calendar.name}")
> public interface CalendarRepository extends IgniteRepository String> {
> List findByName(String name);
> }
>
> And property "cache.calendar.name" can be configured as usual property
> at Spring Framework.
>
> But way brakes current configuration way and I would ask about how we
> can set cache name by  expression or constant string.
>
> I see options:
>
> 1) field "cacheName" will be able to process expression and constant
> string. The code of repository factory will analyse the field.
>
> 2) create new field for expressions
>
>
> What is best way?
>
>
> --
> -
>
> With best regards, Sergey Chernolyas
>

Re: Internal classes are exposed in public API

[Alexey Goncharuk]

Nikita,

Disagree here. I already gave an example in this thread of how you need to
peek into configuration in order to obtain an instance of exporter SPI
which may not necessarily be the type you need. That's why IGNITE-12553 was
created in the first place.

Re: Internal classes are exposed in public API

[Denis Magda]

Folks, seriously, we should deprecate an existing API only after the new
one is no longer considered experimental. There might be API and
configuration changes in the experimental API before it's announced as GA.
I would encourage us to do this properly - let's release the new APIs
labeling them as experimental for now and not label the existing as
deprecated until the new is announced as GA.

-
Denis


On Thu, Jan 30, 2020 at 9:27 AM Alexey Goncharuk 
wrote:

> Nikita,
>
> Disagree here. I already gave an example in this thread of how you need to
> peek into configuration in order to obtain an instance of exporter SPI
> which may not necessarily be the type you need. That's why IGNITE-12553 was
> created in the first place.
>

Re: Contribution

[Denis Magda]

Nikolay, Andrey,

Would you be the best committers to help out here? You are already deeply
involved in metrics development and can quickly suggest Lev how to proceed
with this task.

-
Denis


On Thu, Jan 30, 2020 at 2:46 AM Лев Киселев 
wrote:

> Hello everyone, I have question about following task:
> [https://issues.apache.org/jira/browse/IGNITE-10698]
> Solution proposed in task description is seem to be logical.
> So, I need to every replace @MXBeanParametersNames and
> @MXBeanParametersDescriptions (everywhere, for uniformity) with something
> like:
> void methodName(@MXBeanParameterInformation(name = "name", description =
> "description") firstParameter, ...) {}.
> And, of course, need to change processing logic at
> getParameterName/getDescription methods from IgniteStandardMXBean.
> Do I understand correctly what needs to be done?
>

Re: Internal classes are exposed in public API

[Nikolay Izhikov]

Alexey.

I answered to your examples and issues you provide.
But, it seems the discussion of the API and the Java code itself is not the 
goal of this thread anymore.

> Should we provide a way to know the number of metrics and registries in 
> advance? 

No. 
If you think this is the real use-as let’s add `size` methods.
It will be the simple API *extension*.

> There is no separation on public and internal metrics

Any metric can be changed(removed) in any time.
But we will try not to do it unless we have a strong reason.

> Will we allow users to register their own metrics? 

No.

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

We should write this information in the deprecation message.

> 30 янв. 2020 г., в 20:27, Alexey Goncharuk  
> написал(а):
> 
> Nikita,
> 
> Disagree here. I already gave an example in this thread of how you need to
> peek into configuration in order to obtain an instance of exporter SPI
> which may not necessarily be the type you need. That's why IGNITE-12553 was
> created in the first place.

[MTCGA]: new failures in builds [4973730] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New test failure in master EntryProcessorPermissionCheckTest.test 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-59427578418496601&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - denis garus  
https://ci.ignite.apache.org/viewModification.html?modId=897244

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 20:56:38 30-01-2020 

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Denis Magda]

Such a revelation for me that data is purged from RAM if someone
deactivates the cluster. Alex, do you remember why we decided to implement
it this way initially?

-
Denis


On Thu, Jan 30, 2020 at 2:09 AM Alexey Goncharuk 
wrote:

> I agree on CLI and JMX because those interfaces can be used by a system
> administrator and can be invoked by mistake.
>
> As for the Java API, personally, I find it strange to add 'force' or
> 'confirm' flags to it because it is very unlikely that such an invocation
> is done by mistake. Such mistakes are caught during the testing phase and
> developers will end up hard-coding 'true' as a flag anyways.
>

Re: Native Persistence & JDBC

[Denis Magda]

Forwarding this thread to the dev list.

Ignite SQL experts, could you check this thread and create a proper ticket
for this minor usability improvement? Probably, the ticket is not even
needed.

Basically, our driver reports this error - *SQLException: Client is
invalid. Probably cache name is wrong - *if the cluster with persistence is
deactivated while the error message needs to advise to activate the
cluster instead.

-
Denis


On Tue, Jan 21, 2020 at 4:54 PM narges saleh  wrote:

> Hello Ilya,
> It seems the issue was that I had not enabled the cluster. I'd have
> expected a different type of error.
> Now that I enabled the cluster, the code works with native persistence.
> thanks.
>
> On Tue, Jan 21, 2020 at 5:36 AM Ilya Kasnacheev 
> wrote:
>
>> Hello!
>>
>> Can you please provide complete error message, with stack traces if
>> present?
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 20 янв. 2020 г. в 21:03, narges saleh :
>>
>>> Hello Ilya
>>>
>>> I do have the PERSON2 cache. Here is the snippet for the cache
>>> configuration. I don't have any issue with this configuration if I don't
>>> enable native persistence.
>>>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> 
>>> 
>>> 
>>> >>
>>> On Mon, Jan 20, 2020 at 10:40 AM Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com> wrote:
>>>
 Hello!

 Maybe you don't have PERSON2 cache? :)

 Regards,
 --
 Ilya Kasnacheev


 пн, 20 янв. 2020 г. в 02:47, narges saleh :

> Hi All
>
> I am using JDBC connection for inserting data into caches specified in
> my config file (via query entities). If I don't enable native persistence,
> everything works fine and I can insert the data into cache/table and query
> the cache/table. But if I enable native persistence, the client dies as
> soon it attempts to create the JDBC connection, using the configuration
> file, with this error:
>
> SQLException: Client is invalid. Probably cache name is wrong.
>
> The connection command is this:
>
> Connection conn = DriverManager.getConnection(
> "jdbc:ignite:cfg://cache=PERSON2:streaming=true:streamingFlushFrequency=
> 2000@file:///opt/ignite/config/query-entity-store.xml");
>
> Any idea what could I be doing wrong?
>
> thanks.
>

Re: Internal classes are exposed in public API

[Andrey Gura]

I'll just repeat one thought with some changes.

There are at least two groups of people in this discussion. One group
sure that new API is complete and production ready while other group
disagree with it. Obviously we can't reach consensus about it right
now. But we can do it in the future.
At present we just can't deprecate existing API and mark new API as
experimental at the same time. So we must remove deprecation until the
consensus is reached.

Also there is the third group of people. This people aren't related
with the API, they may be don't need the API and they wait for bug
fixes and other features. It is very easy to satisfy third group: just
cut off what caused the release blocking. But it is much easier to
remove @deprecated annotations.

On Thu, Jan 30, 2020 at 8:54 PM Nikolay Izhikov  wrote:
>
> Alexey.
>
> I answered to your examples and issues you provide.
> But, it seems the discussion of the API and the Java code itself is not the 
> goal of this thread anymore.
>
> > Should we provide a way to know the number of metrics and registries in 
> > advance?
>
> No.
> If you think this is the real use-as let’s add `size` methods.
> It will be the simple API *extension*.
>
> > There is no separation on public and internal metrics
>
> Any metric can be changed(removed) in any time.
> But we will try not to do it unless we have a strong reason.
>
> > Will we allow users to register their own metrics?
>
> No.
>
> > It's still not clear how a user will map old interfaces and methods to the 
> > new metric names.
>
> We should write this information in the deprecation message.
>
> > 30 янв. 2020 г., в 20:27, Alexey Goncharuk  
> > написал(а):
> >
> > Nikita,
> >
> > Disagree here. I already gave an example in this thread of how you need to
> > peek into configuration in order to obtain an instance of exporter SPI
> > which may not necessarily be the type you need. That's why IGNITE-12553 was
> > created in the first place.
>

Re: Data vanished from cluster after INACTIVE/ACTIVE switch

[Alexey Goncharuk]

Because originally the sole purpose of deactivation was resource
deallocation.

чт, 30 янв. 2020 г. в 22:13, Denis Magda :

> Such a revelation for me that data is purged from RAM if someone
> deactivates the cluster. Alex, do you remember why we decided to implement
> it this way initially?
>
> -
> Denis
>
>
> On Thu, Jan 30, 2020 at 2:09 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> wrote:
>
> > I agree on CLI and JMX because those interfaces can be used by a system
> > administrator and can be invoked by mistake.
> >
> > As for the Java API, personally, I find it strange to add 'force' or
> > 'confirm' flags to it because it is very unlikely that such an invocation
> > is done by mistake. Such mistakes are caught during the testing phase and
> > developers will end up hard-coding 'true' as a flag anyways.
> >
>

Re: CompactFooter for ClientBinaryMarshaller

[tschauenberg]

Igor, can you have a look at
https://issues.apache.org/jira/browse/IGNITE-12003 and link it to
https://issues.apache.org/jira/browse/IGNITE-10960?

Using Java 2.7.0 thin client, Java 2.7.0 thick client and Java 2.7.0 Ignite
servers I first hit IGNITE-10960 and then reading your comments and the
proposed fix and this mailing list I tried to set the compact header in the
thin client to true to match the thick client but then hit the bug from
IGNITE-12003.

We hope to upgrade to 2.7.6 as soon but until we do I can't confirm the
behaviour is still a problem in 2.7.6.  I suspect it still is given
IGNITE-12003 reports the bug in 2.7.5.  



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

[MTCGA]: new failures in builds [4972383] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New test failure in master 
IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=1153260173537232526&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - denis-chudov  
https://ci.ignite.apache.org/viewModification.html?modId=897213
 - kirill tkalenko  
https://ci.ignite.apache.org/viewModification.html?modId=897214
 - denis-chudov  
https://ci.ignite.apache.org/viewModification.html?modId=897177
 - nikolay  
https://ci.ignite.apache.org/viewModification.html?modId=897179
 - pavel tupitsyn  
https://ci.ignite.apache.org/viewModification.html?modId=897221
 - aleksei scherbakov  
https://ci.ignite.apache.org/viewModification.html?modId=897174
 - vasiliy sisko  
https://ci.ignite.apache.org/viewModification.html?modId=897184
 - vladsz83  
https://ci.ignite.apache.org/viewModification.html?modId=897186

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 02:11:38 31-01-2020 

[MTCGA]: new failures in builds [4972431] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New test failure in master-nightly 
IgnitePdsDestroyCacheWithoutCheckpointsTest.testDestroyCachesAbruptlyWithoutCheckpoints
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5180582589037958306&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master-nightly 
IgnitePdsDestroyCacheWithoutCheckpointsTest.testDestroyGroupCachesAbruptlyWithoutCheckpoints
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7041034747489803654&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master-nightly 
IgnitePdsDestroyCacheTest.testDestroyCaches 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4123476680328041986&branch=%3Cdefault%3E&tab=testDetails

 *Recently contributed test failed in master-nightly 
IgnitePdsDestroyCacheTest.testDestroyCacheOperationNotBlockingCheckpointTest_LocalCache
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4694926032189571442&branch=%3Cdefault%3E&tab=testDetails

 *New test failure in master-nightly 
IgnitePdsDestroyCacheTest.testDestroyGroupCaches 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8849476549546512721&branch=%3Cdefault%3E&tab=testDetails

 *Recently contributed test failed in master-nightly 
IgnitePdsDestroyCacheTest.testDestroyCacheOperationNotBlockingCheckpointTest 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=14320991462186048&branch=%3Cdefault%3E&tab=testDetails
 Changes may lead to failure were done by 
 - denis-chudov  
https://ci.ignite.apache.org/viewModification.html?modId=897213
 - kirill tkalenko  
https://ci.ignite.apache.org/viewModification.html?modId=897214
 - denis-chudov  
https://ci.ignite.apache.org/viewModification.html?modId=897177
 - nikolay  
https://ci.ignite.apache.org/viewModification.html?modId=897179
 - pavel tupitsyn  
https://ci.ignite.apache.org/viewModification.html?modId=897221
 - aleksei scherbakov  
https://ci.ignite.apache.org/viewModification.html?modId=897174
 - vasiliy sisko  
https://ci.ignite.apache.org/viewModification.html?modId=897184
 - vladsz83  
https://ci.ignite.apache.org/viewModification.html?modId=897186

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 02:56:36 31-01-2020 

[jira] [Created] (IGNITE-12611) EntryProcessorPermissionCheckTest.test: Test looks flaky

[Denis Garus (Jira)]

Denis Garus created IGNITE-12611:


 Summary: EntryProcessorPermissionCheckTest.test: Test looks flaky
 Key: IGNITE-12611
 URL: https://issues.apache.org/jira/browse/IGNITE-12611
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Garus
Assignee: Denis Garus


Test looks flaky.Test status change in build without changes: from failed to 
successful



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

Re: Internal classes are exposed in public API

[Pavel Tupitsyn]

Agree with Andrey, let's remove deprecation for now and unblock the release.

On Thu, Jan 30, 2020 at 10:23 PM Andrey Gura  wrote:

> I'll just repeat one thought with some changes.
>
> There are at least two groups of people in this discussion. One group
> sure that new API is complete and production ready while other group
> disagree with it. Obviously we can't reach consensus about it right
> now. But we can do it in the future.
> At present we just can't deprecate existing API and mark new API as
> experimental at the same time. So we must remove deprecation until the
> consensus is reached.
>
> Also there is the third group of people. This people aren't related
> with the API, they may be don't need the API and they wait for bug
> fixes and other features. It is very easy to satisfy third group: just
> cut off what caused the release blocking. But it is much easier to
> remove @deprecated annotations.
>
> On Thu, Jan 30, 2020 at 8:54 PM Nikolay Izhikov 
> wrote:
> >
> > Alexey.
> >
> > I answered to your examples and issues you provide.
> > But, it seems the discussion of the API and the Java code itself is not
> the goal of this thread anymore.
> >
> > > Should we provide a way to know the number of metrics and registries
> in advance?
> >
> > No.
> > If you think this is the real use-as let’s add `size` methods.
> > It will be the simple API *extension*.
> >
> > > There is no separation on public and internal metrics
> >
> > Any metric can be changed(removed) in any time.
> > But we will try not to do it unless we have a strong reason.
> >
> > > Will we allow users to register their own metrics?
> >
> > No.
> >
> > > It's still not clear how a user will map old interfaces and methods to
> the new metric names.
> >
> > We should write this information in the deprecation message.
> >
> > > 30 янв. 2020 г., в 20:27, Alexey Goncharuk 
> написал(а):
> > >
> > > Nikita,
> > >
> > > Disagree here. I already gave an example in this thread of how you
> need to
> > > peek into configuration in order to obtain an instance of exporter SPI
> > > which may not necessarily be the type you need. That's why
> IGNITE-12553 was
> > > created in the first place.
> >
>

Re: [MTCGA]: new failures in builds [4973730] needs to be handled

[Denis Garus]

Hello!
I've created the task [1].

1. https://issues.apache.org/jira/browse/IGNITE-12611

чт, 30 янв. 2020 г. в 20:56, :

> Hi Igniters,
>
>  I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
>  If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution to this project, but things change and
> you may no longer be able to finalize your contribution.
>  Could you respond to this email and indicate if you wish to continue and
> fix test failures or step down and some committer may revert you commit.
>
>  *New test failure in master EntryProcessorPermissionCheckTest.test
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-59427578418496601&branch=%3Cdefault%3E&tab=testDetails
>  Changes may lead to failure were done by
>  - denis garus 
> https://ci.ignite.apache.org/viewModification.html?modId=897244
>
>  - Here's a reminder of what contributors were agreed to do
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>  - Should you have any questions please contact
> dev@ignite.apache.org
>
> Best Regards,
> Apache Ignite TeamCity Bot
> https://github.com/apache/ignite-teamcity-bot
> Notification generated at 20:56:38 30-01-2020
>