[MTCGA]: new failures in builds [6145726] 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.

 *Test with high flaky rate in master 
GridCommandHandlerTest.testSnapshotRestoreCancelAndStatus 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4389213602152674112=%3Cdefault%3E=testDetails
 No changes in the build

 - 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 06:48:34 24-08-2021 

Re: [ANNOUNCE] Apache Ignite spring-data-all-ext extensions 1.0.0 released

[Nikita Safonov]

Hi folks,

I've updated the docs. Please see the ticket and PR below:

[1] https://issues.apache.org/jira/browse/IGNITE-15363
[2] https://github.com/apache/ignite/pull/9350

Please merge it to master and port it to 2.10 and 2.11.

Thank you!

Regards,
Nikita

чт, 29 июл. 2021 г. в 12:15, Nikita Safonov :

> Hi guys,
>
> I can help with documenting this.
>
> Is there a ticket for updating the Apache Ignite with Spring Data
> 
> docs ticket?
>
> Regards,
> Nikita
>
> вт, 27 июл. 2021 г. в 17:01, Denis Magda :
>
>> Nikita, thanks for releasing the artifacts.
>>
>> Could you please update the following documentation section as well?
>>
>> https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#maven-configuration
>>
>> This is what worked for me:
>>
>> 1. Ignite Spring Data dependency
>>
>> 
>>org.apache.ignite
>>ignite-spring-data-2.2-ext
>>1.0.0
>> 
>>
>> 2. Also, I had to provide this dependency to solve various runtime-related
>> issues (didn't need to do this with previous version of the integration):
>>
>> 
>> org.springframework.data
>> spring-data-commons
>>* 2.2.3.RELEASE (this is hardcoded, needs to be
>> generic in the docs)*
>> 
>>
>> --
>> Denis
>>
>>
>> -
>> Denis
>>
>> On Sat, Jul 24, 2021 at 7:46 PM Nikita Amelchev 
>> wrote:
>>
>> > Hi,
>> >
>> > Artifacts were uploaded to the maven repo [1, 2, 3, 4].
>> >
>> > The spring-tx module was migrated in the 2.11 that was not released yet.
>> > The extension release is independent of the Ignite release.
>> >
>> > [1]
>> >
>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-ext
>> > [2]
>> >
>> >
>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-2.0-ext
>> > [3]
>> >
>> >
>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-2.2-ext
>> > [4]
>> >
>> >
>> https://mvnrepository.com/artifact/org.apache.ignite/ignite-spring-data-commons
>> >
>> >
>> > сб, 24 июл. 2021 г., 04:48 18624049226 <18624049...@163.com>:
>> >
>> > > Igniters,
>> > >
>> > > It seems that these artifact have not been uploaded to Maven Repo?
>> Will
>> > > it be uploaded with ignite 2.11?
>> > >
>> > > This release does not include spring-tx-ext, but the documentation of
>> > > this artifact has been merged into the ignite-2.11 branch, What's
>> wrong?
>> > >
>> > > 在 2021/7/7 下午1:49, Nikita Amelchev 写道:
>> > > > The Apache Ignite Community is pleased to announce the release of
>> > > > Apache Ignite Spring Data extensions 1.0.0.
>> > > >
>> > > > The following integrations were migrated to the Apache Ignite
>> > > > Extensions repository:
>> > > >
>> > > > - Spring Data 2.2 extension.
>> > > > - Spring Data 2.0 extension.
>> > > > - Spring Data extension.
>> > > >
>> > > > Release notes:
>> > > >
>> > >
>> >
>> https://ignite.apache.org/releases/ext/spring-data-all-1.0.0/release_notes.html
>> > > >
>> > > > The sources package is available here:
>> > > >
>> > >
>> >
>> https://downloads.apache.org/ignite/ignite-extensions/ignite-spring-data-all-ext/1.0.0/
>> > > >
>> > > > Please let us know if you have any problems
>> > > > https://ignite.apache.org/community/resources.html#ask
>> > > >
>> > >
>> >
>>
>

Re: Re[2]: Google Guava in Ignite 3

[Andrey Gura]

Igniters,

What I actually didn't understand from this thread: Is Guava allowed
in production code of Ignite 3 modules (not dependencies like
Calcite)?

While we agree with using shading I don't see any arguments about
using Guava library in our code base except for the fact that we have
some copy-paste of Guava code in the project.

Guava is rich enough library and it has both advantages and
disadvantages. Ignite code base always strived to be not overloaded
and minimalistic. For example we usually use immutability very rare,
we try to avoid complex and overloaded APIs on hot path, we try reduce
GC pressure, etc. In turn, Guava is some sense forces using of
immutable collections, has a lot of utility methods which produces
temp object (yes, I don't trust to escap analysys), etc. Rich set of
collections and utility functions will also lead to different
programming styles during Ignite development. I can't predict it, but
it is usual enough when some developers force immutablity while others
remove static type declaration and replace it by var :)

This is a common pratice to reduce language possibilies subset and
limiting using of some libraries in order to provide more or less
unified approach to coding. So I propose to disallow using Guava in
our code base.

WDYT?


On Fri, Aug 20, 2021 at 7:37 PM Alexander Polovtcev
 wrote:
>
> Guys,
>
> Thanks again for your responses. I've created a ticket about using the
> Shade plugin in order to understand if it is possible to shade and minimize
> Guava, I will start working on it shortly:
> https://issues.apache.org/jira/browse/IGNITE-15354
>
> On Tue, Aug 10, 2021 at 1:51 PM Courtney Robinson 
> wrote:
>
> > I think since Calcite brings it in already then your arguments make sense.
> > Would it be pinned to the same version as Calcite? Risk NoSuchMethodError
> > at runtime if not.
> > +1
> >
> > On Mon, Aug 9, 2021 at 9:56 AM Alexander Polovtcev <
> > alexpolovt...@gmail.com>
> > wrote:
> >
> > > Zhenya, Courtney, Andrey,
> > >
> > > What do you think about my arguments, was I able to convince you? I would
> > > like to reach some consensus here. At the moment, my original points
> > still
> > > stand, I'm also ok with shading Guava if needed, though I think it is not
> > > necessary at this point.
> > >
> > > On Fri, Aug 6, 2021 at 12:45 PM Alexander Polovtcev <
> > > alexpolovt...@gmail.com>
> > > wrote:
> > >
> > > > Zhenya,
> > > >
> > > > > But there is no restrictions from running ignite server nodes from
> > some
> > > > other code with it`s own guava version seems we obtain fast path to jar
> > > > hell here?
> > > >
> > > > I'm not sure if I fully understand your question, but it looks like we
> > > are
> > > > in this situation already, because we have some dependencies that use
> > > > Guava. That's why I propose to add Guava explicitly to at least have a
> > > > deterministic runtime configuration (see this link
> > > > <
> > >
> > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
> > > >
> > > > for an explanation).
> > > >
> > > > On Fri, Aug 6, 2021 at 12:25 PM Zhenya Stanilovsky
> > > >  wrote:
> > > >
> > > >>
> > > >> Alexander, first of all looks like Ivan Daschinsky approach about thin
> > > >> client use only and shadow plugin are cover all Andrey Mashenkov
> > listing
> > > >> problems.
> > > >> But there is no restrictions from running ignite server nodes from
> > some
> > > >> other code with it`s own guava version seems we obtain fast path to
> > jar
> > > >> hell here?
> > > >>
> > > >>
> > > >> >Zhenya,
> > > >> >
> > > >> >My intentions are the following:
> > > >> >
> > > >> >1. Remove some copy-pasted code (like the "bytecode" module or some
> > > >> utility
> > > >> >methods). Please see my original message for the links to the code.
> > > >> >2. Explicitly pin the Guava version to avoid conflicts in the
> > runtime.
> > > >> >
> > > >> >About allowing to use Guava in the codebase, my thoughts are the
> > > >> following:
> > > >> >
> > > >> >1. We *already* use some code from Guava either directly (like in the
> > > >> >"calcite" module) or by copy-pasting it into a utility class.
> > > >> >2. I understand that some Guava methods are obsolete as of Java 11,
> > but
> > > >> >some of them still don't have any standard library counterparts, in
> > > which
> > > >> >case I think using Guava is justified (which is supported by point
> > 1).
> > > >> >
> > > >> >Can you please explain why you would disapprove of my proposal?
> > > >> >
> > > >> >On Thu, Aug 5, 2021 at 7:56 PM Zhenya Stanilovsky
> > > >> >< arzamas...@mail.ru.invalid > wrote:
> > > >> >
> > > >> >>
> > > >> >> alexpolovtcev please clarify what do you mean under : «possibility
> > of
> > > >> >> using Guava in Ignite 3», using how necessary dependency of calcite
> > > or
> > > >> >> using like «using in our code» ? If using in code, i -1 here.
> > > >> >> thanks.
> > > >> >>
> > > >> >>
> > > >> >> >Hello, dear 

Re: IGNITE-13364: Improve index inline defaults

[Maksim Timonin]

Hi!

JFYI, it was merged to master today, then this patch will be part of 2.12
only.


On Thu, Jun 10, 2021 at 5:00 PM Maksim Timonin 
wrote:

> Hi,
>
> I've prepared a patch for this feature. Can anybody have a look at it?
>
> https://github.com/apache/ignite/pull/9167
> https://issues.apache.org/jira/browse/IGNITE-13364
>
> On Mon, Jun 7, 2021 at 12:14 PM Maksim Timonin 
> wrote:
>
>> Hi, I've left a comment in your PR, could you please have a look?
>>
>> On Sat, Jun 5, 2021 at 6:09 AM 18624049226 <18624049...@163.com> wrote:
>>
>>> Hello team,
>>>
>>> I think this is a very valuable optimization. This patch has been
>>> developed for a long time, I don't think there is any reason to continue
>>> to delay the release of this patch to version 2.12.
>>> Is anyone willing to push this forward and merge this patch into the
>>> master?
>>>
>>> 2021/1/27 下午4:52, Maxim Muzafarov 写道:
>>> > Stanislav,
>>> >
>>> >> I think the most compatibility impact will be on the in-memory caches
>>> with SQL and without explicitly specified inline sizes.
>>> > I don't think that this is `true` compatibility issue. But I think we
>>> > should at least mentioned it on our documentation pages and in the
>>> > release notes. So, I'm +1 to proceed with the merge.
>>> >
>>> > Should we include the issue into 2.10 release?
>>> >
>>> > On Fri, 8 Jan 2021 at 16:50, Stanislav Lukyanov <
>>> stanlukya...@gmail.com> wrote:
>>> >> Hi Igniters,
>>> >>
>>> >> I'd like to discuss the change implemented by Evgeniy Rudenko in the
>>> ticket https://issues.apache.org/jira/browse/IGNITE-13364.
>>> >> I see that the fix is ready for review and merging, and I'm
>>> interested in it so I'd like to pick it up on the last mile.
>>> >> I also wanted to bring community's attention to it before the merge
>>> as it changes the default behavior.
>>> >>
>>> >> The patch changes how SQL index inline size is calculated.
>>> >>
>>> >> Specifically:
>>> >>
>>> >> 1. When inline size is calculated for a variable-sized field, a
>>> constant 10 (configurable via IGNITE_VARIABLE_TYPE_DEFAULT_INDEX_SIZE) is
>>> added to the calculated size instead of setting the entire calculation
>>> result to 10.
>>> >> For example, consider the following cases
>>> >>
>>> >> Index (int, int, string)
>>> >> Before the change: inline size = 10
>>> >> After the change: inline size = 5 + 5 + 10 = 20
>>> >>
>>> >> Index (long, long, long, long,  string)
>>> >> Before the change: inline size = 10
>>> >> After the change: inline size = 9 + 9 + 9 + 9 + 10 = 46
>>> >>
>>> >> 2. If there is a VARCHAR_FIXED, e.g. VARCHAR(5), then instead of the
>>> default IGNITE_VARIABLE_TYPE_DEFAULT_INDEX_SIZE Ignite will use the value
>>> provided in the calculation
>>> >>
>>> >> 3. If the calculated size exceeds
>>> IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT=64, it will be truncated to 64.
>>> >>
>>> >> All of this only affects calculated inline sizes of new indexes.
>>> >> Existing indexes should not be affected.
>>> >> Indexes with explicitly specified inline size should not be affected.
>>> >>
>>> >> I think the most compatibility impact will be on the in-memory caches
>>> with SQL and without explicitly specified inline sizes.
>>> >> After the upgrade these caches may slightly increase in size (because
>>> the inline is likely to become bigger) while SQL is also likely to become
>>> faster.
>>> >>
>>> >> Please comment.
>>> >> If there are no concerns, I'll proceed with finding a committer to
>>> review and merge the fix at the end of the next week.
>>> >>
>>> >> Thanks,
>>> >> Stan
>>>
>>