date:20211220

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

2021-12-20 Thread Ivan Pavlukhin

Val,

> Therefore, it's crucial to bring the attention of the API's user to such 
> parameters. (@Nullable)

This sounds wrong for me. If a method parameter is marked as
@Nullable, then a user can put anything there without much thinking.
Opposite happens with @NotNull parameters, with them a user should
think whether his variable can be null or not.

As for me using nullable variables should be avoided as much as
possible, but not all developers share this point of view. And
especially in Ignite codebase it was quite common to use nullable
variables, for the first time it was very unusual for me.

2021-12-20 22:06 GMT+03:00, Valentin Kulichenko :
> Neither solution is completely bulletproof, and I don't think that's what
> we are looking for. We need something that provides a reasonable value, but
> also does not clutter the code with too many annotations.
>
> I would also keep in mind that annotations are used not only for static
> analysis, but by developers as well. And from this standpoint, I feel
> that @Nullable is much more important, because 'null' is a special value
> which is treated differently in different circumstances. Therefore, it's
> crucial to bring the attention of the API's user to such parameters. On the
> other hand, non-nullable parameters are inherently safer, so there is less
> need to annotate them.
>
> -Val
>
> On Mon, Dec 20, 2021 at 7:42 AM Alexander Polovtcev
> 
> wrote:
>
>> Hi, Ivan.
>>
>> > it seems not bulletproof
>>
>> I completely agree with you. As I wrote in the original message, this
>> becomes even worse in case of 3-rd party dependencies, because they may
>> not
>> be annotated, which can lead to confusions. But looks like this is not a
>> big deal, because these annotations are not intended to cover 100% of
>> cases
>> and should not be treated as a guarantee against NPEs. Maybe covering
>> *some* cases is enough.
>>
>> > Perhaps we can insist on not using nulls as much as possible.
>>
>> Same here, I agree with you and it correlates with clear API design in
>> general. However, sometimes nullable parameters and return values are
>> justified, so how can we formalize that?
>>
>> On Sat, Dec 18, 2021 at 10:52 AM Ivan Pavlukhin 
>> wrote:
>>
>> > Hi,
>> >
>> > While option #2 looks very appealing it seems not bulletproof
>> > reliable, someone can occasionally miss @Nullable annotation. Option
>> > #3 seems more practical too me, as missed @NotNull annotations cannot
>> > do much harm.
>> >
>> > Also I am thinking about using nullable parameters in general. Perhaps
>> > we can insist on not using nulls as much as possible. With such
>> > requirement in guidelines option #2 becomes practical.
>> >
>> > 2021-12-17 14:47 GMT+03:00, Alexander Polovtcev
>> > > >:
>> > > Maksim, thank you for the suggestion.
>> > >
>> > > I've never used NullAway, but after having a quick look I think it
>> might
>> > be
>> > > an overkill, since it is a plugin for the ErrorProne, which is a
>> separate
>> > > tool. I recall some efforts of introducing ErrorProne to Ignite 3 and
>> > they
>> > > were not successful. But again, I don't have much experience in that
>> > > regard. I wonder if IDEA inspections would be enough, since they are
>> easy
>> > > to use during development and AFAIK are already run during the TC
>> builds.
>> > >
>> > > Regarding Ignite 2, I don't know if it would be viable to add these
>> > > annotations to the existing code (in order to have meaningful
>> > > checks),
>> > > since the codebase is so large. But nevertheless we can try to adopt
>> the
>> > > same approach there as well.
>> > >
>> > > On Fri, Dec 17, 2021 at 12:10 PM Maksim Timonin <
>> timoninma...@apache.org
>> > >
>> > > wrote:
>> > >
>> > >> Hi!
>> > >>
>> > >> There is a pretty popular project NullAway [1] that checks code of a
>> > >> project in compile-time for possible NPE. AFAIK, it works only with
>> the
>> > >> "@Nullable" annotation. I think we can try to add this check to
>> Ignite2
>> > >> and
>> > >> 3.
>> > >>
>> > >> But I wonder, whether smbd already tried to introduce this check? If
>> > not,
>> > >> I
>> > >> can try, WDYT?
>> > >>
>> > >> [1] https://github.com/uber/NullAway
>> > >>
>> > >> On Fri, Dec 17, 2021 at 9:04 AM ткаленко кирилл
>> > >> > >
>> > >> wrote:
>> > >>
>> > >> > I'm for the second option.
>> > >> >
>> > >>
>> > >
>> > >
>> > > --
>> > > With regards,
>> > > Aleksandr Polovtcev
>> > >
>> >
>> >
>> > --
>> >
>> > Best regards,
>> > Ivan Pavlukhin
>> >
>>
>>
>> --
>> With regards,
>> Aleksandr Polovtcev
>>
>


-- 

Best regards,
Ivan Pavlukhin

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

2021-12-20 Thread Valentin Kulichenko

Neither solution is completely bulletproof, and I don't think that's what
we are looking for. We need something that provides a reasonable value, but
also does not clutter the code with too many annotations.

I would also keep in mind that annotations are used not only for static
analysis, but by developers as well. And from this standpoint, I feel
that @Nullable is much more important, because 'null' is a special value
which is treated differently in different circumstances. Therefore, it's
crucial to bring the attention of the API's user to such parameters. On the
other hand, non-nullable parameters are inherently safer, so there is less
need to annotate them.

-Val

On Mon, Dec 20, 2021 at 7:42 AM Alexander Polovtcev 
wrote:

> Hi, Ivan.
>
> > it seems not bulletproof
>
> I completely agree with you. As I wrote in the original message, this
> becomes even worse in case of 3-rd party dependencies, because they may not
> be annotated, which can lead to confusions. But looks like this is not a
> big deal, because these annotations are not intended to cover 100% of cases
> and should not be treated as a guarantee against NPEs. Maybe covering
> *some* cases is enough.
>
> > Perhaps we can insist on not using nulls as much as possible.
>
> Same here, I agree with you and it correlates with clear API design in
> general. However, sometimes nullable parameters and return values are
> justified, so how can we formalize that?
>
> On Sat, Dec 18, 2021 at 10:52 AM Ivan Pavlukhin 
> wrote:
>
> > Hi,
> >
> > While option #2 looks very appealing it seems not bulletproof
> > reliable, someone can occasionally miss @Nullable annotation. Option
> > #3 seems more practical too me, as missed @NotNull annotations cannot
> > do much harm.
> >
> > Also I am thinking about using nullable parameters in general. Perhaps
> > we can insist on not using nulls as much as possible. With such
> > requirement in guidelines option #2 becomes practical.
> >
> > 2021-12-17 14:47 GMT+03:00, Alexander Polovtcev  >:
> > > Maksim, thank you for the suggestion.
> > >
> > > I've never used NullAway, but after having a quick look I think it
> might
> > be
> > > an overkill, since it is a plugin for the ErrorProne, which is a
> separate
> > > tool. I recall some efforts of introducing ErrorProne to Ignite 3 and
> > they
> > > were not successful. But again, I don't have much experience in that
> > > regard. I wonder if IDEA inspections would be enough, since they are
> easy
> > > to use during development and AFAIK are already run during the TC
> builds.
> > >
> > > Regarding Ignite 2, I don't know if it would be viable to add these
> > > annotations to the existing code (in order to have meaningful checks),
> > > since the codebase is so large. But nevertheless we can try to adopt
> the
> > > same approach there as well.
> > >
> > > On Fri, Dec 17, 2021 at 12:10 PM Maksim Timonin <
> timoninma...@apache.org
> > >
> > > wrote:
> > >
> > >> Hi!
> > >>
> > >> There is a pretty popular project NullAway [1] that checks code of a
> > >> project in compile-time for possible NPE. AFAIK, it works only with
> the
> > >> "@Nullable" annotation. I think we can try to add this check to
> Ignite2
> > >> and
> > >> 3.
> > >>
> > >> But I wonder, whether smbd already tried to introduce this check? If
> > not,
> > >> I
> > >> can try, WDYT?
> > >>
> > >> [1] https://github.com/uber/NullAway
> > >>
> > >> On Fri, Dec 17, 2021 at 9:04 AM ткаленко кирилл  >
> > >> wrote:
> > >>
> > >> > I'm for the second option.
> > >> >
> > >>
> > >
> > >
> > > --
> > > With regards,
> > > Aleksandr Polovtcev
> > >
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>
>
> --
> With regards,
> Aleksandr Polovtcev
>

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Valentin Kulichenko

+1

On Mon, Dec 20, 2021 at 5:39 AM Alex Plehanov 
wrote:

> +1
>
> Checked build from the source, cluster startup with 2 nodes.
>
> пн, 20 дек. 2021 г. в 16:27, Nikolay Izhikov :
>
> > +1 (binding)
> >
> > > 20 дек. 2021 г., в 16:20, Ivan Daschinsky 
> > написал(а):
> > >
> > > +1 from me
> > > Checked ODBC drivers (32-bit and 64-bit) installers on Windows with
> > running
> > > locally Ignite with
> > > pyodbc and python 3.9 using this script [1]
> > >
> > >
> > > [1] --
> > https://gist.github.com/ivandasch/6cc0b56e055b826e5840b5c04fa3b2fa
> > >
> > > пн, 20 дек. 2021 г. в 15:45, Pavel Tupitsyn :
> > >
> > >> +1
> > >>
> > >> Checked .NET binaries, nugets, and examples.
> > >>
> > >> On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > >>>
> > >> wrote:
> > >>
> > >>> Hello!
> > >>>
> > >>> +1
> > >>>
> > >>> There seems to be a correct version of log4j2 now.
> > >>>
> > >>> Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This
> is
> > >>> quite bad.
> > >>>
> > >>> Regards,
> > >>> --
> > >>> Ilya Kasnacheev
> > >>>
> > >>>
> > >>> пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :
> > >>>
> >  The second release candidate for the 2.11.1 version is ready.
> > 
> >  Since this is an emergency release the vote will remain open for as
> >  short an amount as time as required to vet the release. All votes
> are
> >  welcome and we encourage everyone to test the release, but only PMC
> >  votes are “officially” counted. As always, at least 3 +1 votes and
> >  more positive than negative votes are required. See voting
> guidelines:
> >  https://www.apache.org/foundation/voting.html
> > 
> >  +1 - to accept Apache Ignite 2.11.1-rc2
> >  0 - don't care either way
> >  -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)
> > 
> > 
> >  * RELEASE CANDADATE *
> > 
> >  Check the release difference between 2.11 and 2.11.1:
> > 
> https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
> > 
> >  I have uploaded a release candidate to:
> >  https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
> >  https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/
> > 
> >  The following staging can be used for testing:
> > 
> > >>
> > https://repository.apache.org/content/repositories/orgapacheignite-1535/
> > 
> > 
> > >>>
> > >>
> >
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> > 
> >  The tag name is 2.11.1-rc2:
> > 
> > 
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc
> > 
> >  RELEASE_NOTES:
> > 
> > 
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
> > 
> >  Complete list of resolved issues:
> > 
> > 
> > 
> > >>>
> > >>
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))
> > 
> > 
> >  * CHECKS *
> > 
> >  Additional checks have been performed (available for users included
> > >> into
> >  the release group on TeamCity).
> > 
> >  TC [Check RC: Licenses, compile, chksum]
> > 
> > 
> > >>>
> > >>
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> > 
> >  See notes on how to verify release here
> >  https://www.apache.org/info/verification.html
> >  and
> > 
> > 
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > 
> > >>>
> > >>
> > >
> > >
> > > --
> > > Sincerely yours, Ivan Daschinskiy
> >
> >
>

Re: [DISCUSSION] Reject join of nodes with different character encodings

2021-12-20 Thread Ivan Daschinsky

We copy values unchanged as is in bytes representation. Could you please
specify what could be done wrong?
I see only one possibility:
1. Start cluster with default encoding (This is only the windows case :)).
Set some metastorage values with non ASCII chars.
2. Stop it and restart with specifying encoding to different one.

I suppose that this is very rare case. And all that user should do -- just
erase metastore.

Another variant -- make all users to erase metastore in order to use UTF-8.


пн, 20 дек. 2021 г. в 17:59, Andrey Mashenkov :

> Ivan,
>
> I'm still not sure it is a good idea to upgrade metastorage automatically.
> Because we can't detect the correct charset the metastorage was created
> with, and
> at the same time we can't be sure the current charset is the correct one.
>
> So, is there any guarantee the metastorage is consistent even if it was
> "upgraded" successfully?
>
> As I see, we just copy metastorage keys to a temporary one in key-by-key
> manner... and then do write-back to the original one.
> Seems, if smth goes wrong, the user may get both (original and temporary)
> stores broken.
>
> On Mon, Dec 20, 2021 at 5:27 PM Ivan Daschinsky 
> wrote:
>
> > Andrey,  I believe that we already have all machinery to do migration
> safe.
> > See for
> > example
> >
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage#init
> > and
> >
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.TmpStorage.
> > This machinery was introduced for slightly different task, but we can
> reuse
> > this for the current purpose.
> >
> > пн, 20 дек. 2021 г. в 11:53, Mikhail Petrov :
> >
> > > Thank you all for your replies!
> > > I got the idea and agreed with it. Based on the results of the
> > > discussion, I have filed a ticket [1].
> > > I will try to investigate it.
> > >
> > > [1] - https://issues.apache.org/jira/browse/IGNITE-16157
> > >
> > > On 16.12.2021 20:11, Ivan Daschinsky wrote:
> > > > Andrey, agree with you, good point.
> > > >
> > > > чт, 16 дек. 2021 г., 16:27 Andrey Mashenkov <
> > andrey.mashen...@gmail.com
> > > >:
> > > >
> > > >> Guys,
> > > >>
> > > >> I like the idea with a flag, but for a different purpose.
> > > >> I think it is easy to detect the issue (using the flag) when
> > > >> metastorage was created on a new version with a fixed charset, or on
> > an
> > > >> older version with the user-defined default.
> > > >> Regarding the flag, we can choose a new strategy forcing UTF-8, or
> > > fallback
> > > >> to the old one with defaultCharset and print a warning and
> > > recommendation
> > > >> in log.
> > > >>
> > > >> Adding any compatibility stuff is absolutely error-prone because if
> > you
> > > >> fail in the middle of restoring process, you will get broken
> > metastorage
> > > >> with keys in different charsets.
> > > >> At this point, there is no way to detect broken keys anymore.
> > > >>
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

2021-12-20 Thread Alexander Polovtcev

Hi, Ivan.

> it seems not bulletproof

I completely agree with you. As I wrote in the original message, this
becomes even worse in case of 3-rd party dependencies, because they may not
be annotated, which can lead to confusions. But looks like this is not a
big deal, because these annotations are not intended to cover 100% of cases
and should not be treated as a guarantee against NPEs. Maybe covering
*some* cases is enough.

> Perhaps we can insist on not using nulls as much as possible.

Same here, I agree with you and it correlates with clear API design in
general. However, sometimes nullable parameters and return values are
justified, so how can we formalize that?

On Sat, Dec 18, 2021 at 10:52 AM Ivan Pavlukhin  wrote:

> Hi,
>
> While option #2 looks very appealing it seems not bulletproof
> reliable, someone can occasionally miss @Nullable annotation. Option
> #3 seems more practical too me, as missed @NotNull annotations cannot
> do much harm.
>
> Also I am thinking about using nullable parameters in general. Perhaps
> we can insist on not using nulls as much as possible. With such
> requirement in guidelines option #2 becomes practical.
>
> 2021-12-17 14:47 GMT+03:00, Alexander Polovtcev :
> > Maksim, thank you for the suggestion.
> >
> > I've never used NullAway, but after having a quick look I think it might
> be
> > an overkill, since it is a plugin for the ErrorProne, which is a separate
> > tool. I recall some efforts of introducing ErrorProne to Ignite 3 and
> they
> > were not successful. But again, I don't have much experience in that
> > regard. I wonder if IDEA inspections would be enough, since they are easy
> > to use during development and AFAIK are already run during the TC builds.
> >
> > Regarding Ignite 2, I don't know if it would be viable to add these
> > annotations to the existing code (in order to have meaningful checks),
> > since the codebase is so large. But nevertheless we can try to adopt the
> > same approach there as well.
> >
> > On Fri, Dec 17, 2021 at 12:10 PM Maksim Timonin  >
> > wrote:
> >
> >> Hi!
> >>
> >> There is a pretty popular project NullAway [1] that checks code of a
> >> project in compile-time for possible NPE. AFAIK, it works only with the
> >> "@Nullable" annotation. I think we can try to add this check to Ignite2
> >> and
> >> 3.
> >>
> >> But I wonder, whether smbd already tried to introduce this check? If
> not,
> >> I
> >> can try, WDYT?
> >>
> >> [1] https://github.com/uber/NullAway
> >>
> >> On Fri, Dec 17, 2021 at 9:04 AM ткаленко кирилл 
> >> wrote:
> >>
> >> > I'm for the second option.
> >> >
> >>
> >
> >
> > --
> > With regards,
> > Aleksandr Polovtcev
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>


-- 
With regards,
Aleksandr Polovtcev

Re: [DISCUSSION] Reject join of nodes with different character encodings

2021-12-20 Thread Andrey Mashenkov

Ivan,

I'm still not sure it is a good idea to upgrade metastorage automatically.
Because we can't detect the correct charset the metastorage was created
with, and
at the same time we can't be sure the current charset is the correct one.

So, is there any guarantee the metastorage is consistent even if it was
"upgraded" successfully?

As I see, we just copy metastorage keys to a temporary one in key-by-key
manner... and then do write-back to the original one.
Seems, if smth goes wrong, the user may get both (original and temporary)
stores broken.

On Mon, Dec 20, 2021 at 5:27 PM Ivan Daschinsky  wrote:

> Andrey,  I believe that we already have all machinery to do migration safe.
> See for
> example
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage#init
> and
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.TmpStorage.
> This machinery was introduced for slightly different task, but we can reuse
> this for the current purpose.
>
> пн, 20 дек. 2021 г. в 11:53, Mikhail Petrov :
>
> > Thank you all for your replies!
> > I got the idea and agreed with it. Based on the results of the
> > discussion, I have filed a ticket [1].
> > I will try to investigate it.
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-16157
> >
> > On 16.12.2021 20:11, Ivan Daschinsky wrote:
> > > Andrey, agree with you, good point.
> > >
> > > чт, 16 дек. 2021 г., 16:27 Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > >:
> > >
> > >> Guys,
> > >>
> > >> I like the idea with a flag, but for a different purpose.
> > >> I think it is easy to detect the issue (using the flag) when
> > >> metastorage was created on a new version with a fixed charset, or on
> an
> > >> older version with the user-defined default.
> > >> Regarding the flag, we can choose a new strategy forcing UTF-8, or
> > fallback
> > >> to the old one with defaultCharset and print a warning and
> > recommendation
> > >> in log.
> > >>
> > >> Adding any compatibility stuff is absolutely error-prone because if
> you
> > >> fail in the middle of restoring process, you will get broken
> metastorage
> > >> with keys in different charsets.
> > >> At this point, there is no way to detect broken keys anymore.
> > >>
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>


-- 
Best regards,
Andrey V. Mashenkov

Re: [DISCUSSION] Reject join of nodes with different character encodings

2021-12-20 Thread Ivan Daschinsky

Andrey,  I believe that we already have all machinery to do migration safe.
See for
example  
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage#init
and 
org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.TmpStorage.
This machinery was introduced for slightly different task, but we can reuse
this for the current purpose.

пн, 20 дек. 2021 г. в 11:53, Mikhail Petrov :

> Thank you all for your replies!
> I got the idea and agreed with it. Based on the results of the
> discussion, I have filed a ticket [1].
> I will try to investigate it.
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-16157
>
> On 16.12.2021 20:11, Ivan Daschinsky wrote:
> > Andrey, agree with you, good point.
> >
> > чт, 16 дек. 2021 г., 16:27 Andrey Mashenkov  >:
> >
> >> Guys,
> >>
> >> I like the idea with a flag, but for a different purpose.
> >> I think it is easy to detect the issue (using the flag) when
> >> metastorage was created on a new version with a fixed charset, or on an
> >> older version with the user-defined default.
> >> Regarding the flag, we can choose a new strategy forcing UTF-8, or
> fallback
> >> to the old one with defaultCharset and print a warning and
> recommendation
> >> in log.
> >>
> >> Adding any compatibility stuff is absolutely error-prone because if you
> >> fail in the middle of restoring process, you will get broken metastorage
> >> with keys in different charsets.
> >> At this point, there is no way to detect broken keys anymore.
> >>
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSS] Custom service proxy context

2021-12-20 Thread Alex Plehanov

Pavel,

> I would say it is linear, not geometric.
Without service context, there were 2 serviceProxy methods. The patch with
service contexts adds two more methods. Each next parameter according to
this pattern will add the same amount of methods as there were before.

> I suggest introducing "ServiceProxyConfiguration" class
Seems to be too complicated :)
If we compare two syntaxes with the same final result:
ignite.services().serviceProxy(new
ServiceProxyConfiguration().setContext(...), ...)
vs
ignite.services().withContext(...).serviceProxy(...);
Second looks simpler and nicer to me.

> Can you clarify please, is it going to be a new interface, let's say
IgniteServicesSomething, and "IgniteServices extends
IgniteServicesSomething"?
Yes, ignite.services() returns IgniteServices,
ignite.services().withContext(...) returns IgniteServicesSomething, that
contains only serviceProxy(...) methods.


пн, 20 дек. 2021 г. в 15:32, Pavel Tupitsyn :

> Alex,
>
> > the count of methods will increase in geometric progression
>
> I would say it is linear, not geometric.
> Anyway, a common fix for "too many parameters" issue is Parameter Object
> pattern [1],
> I suggest introducing "ServiceProxyConfiguration" class.
>
>
> > We already using such an approach in transactions for example, where we
> > have withLabel, withTracing modifier
>
> I'm not sure this is a good approach and I'd like to avoid using it in more
> places.
> - it looks like a builder pattern, but it is not
> - there is no "withoutTracing" so I can't go back
> - when I get "IgniteTransactions" instance in some method, I don't know if
> tracing is enabled or not, there is no way to check, no way to disable
>
>
> > I'm voting for option (3).
>
> Can you clarify please, is it going to be a new interface, let's say
> IgniteServicesSomething,
> and "IgniteServices extends IgniteServicesSomething"?
>
>
> [1] https://wiki.c2.com/?ParameterObject
>
> On Mon, Dec 20, 2021 at 12:15 PM Alex Plehanov 
> wrote:
>
> > Pavel,
> >
> > As for option (1): the count of methods will increase in geometric
> > progression with each new parameter. For example, if we decide to add
> > tracing to services, we should keep current methods as-is for backward
> > compatibility and add new methods supporting a tracing parameter.
> >
> > > Also, we don't provide methods like withTimeout, withSticky, so adding
> > withContext will introduce another inconsistency.
> > We already using such an approach in transactions for example, where we
> > have withLabel, withTracing modifier, and the timeout method parameter. I
> > think it's nothing wrong here. We can't get rid of timeout and sticky
> > parameters due to backward compatibility.
> >
> > > (3) seems to be too complicate
> > I see no complication here. From the user's point of view - almost
> nothing
> > changed. The user can use the same IgniteService interface when
> > using services without modifiers. When using modifiers - only interface
> > with methods related to modifiers will be available. In most cases, the
> > user even no need to know about this new interface.
> >
> > I'm voting for option (3).
> >
> > чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn :
> >
> > > Pavel,
> > >
> > > My vote is for option (1). Simple and clear.
> > >
> > > As you noted, with (2) it is not clear which methods are affected.
> > > Also, we don't provide methods like withTimeout, withSticky, so adding
> > > withContext will introduce another inconsistency.
> > >
> > > (3) seems to be too complicated.
> > >
> > > On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin 
> > wrote:
> > >
> > > > Hi folks!
> > > >
> > > > The discussed feature is currently under development and recently
> > > > there was a proposal for an API improvement, which I want to discuss.
> > > >
> > > > It is about how the user can specify a service call context when
> > > > getting a proxy.
> > > >
> > > > I see the following options:
> > > >
> > > > 1. Passing the context as an argument to the proxy getter method.
> > > >
> > > >Ignite.services().serviceProxy(name,..., callCtx)
> > > >
> > > >The disadvantage is that for ease of use, we add several
> > > >overloads of this method with different combinations of
> parameters.
> > > >
> > > > 2. Adding a new method "withCallContext(callCtx)" (returns
> > > > IgniteServices) to the IgniteServices interface.
> > > >
> > > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...)
> > > >
> > > >The disadvantage is that most of the IgniteServices methods
> > > >are not related to the service call context (deploy, cancel
> > > >of the service, etc.).
> > > >
> > > > 3. (extension of the 2nd option) Adding a new
> > > > "withCallContext(callCtx)" method which returns a new interface.
> > > >
> > > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...)
> > > >
> > > >Unlike the 2nd option, the "withCallContext()" method returns a
> new
> > > > interface
> > > >(for example,

Re: [DISCUSS] Custom service proxy context

2021-12-20 Thread Pavel Pereslegin

Pavel,

> Can you clarify please, is it going to be a new interface, let's say
> IgniteServicesSomething, and "IgniteServices extends IgniteServicesSomething"?

Yes, that's what I meant (if we go this way).

пн, 20 дек. 2021 г. в 15:32, Pavel Tupitsyn :
>
> Alex,
>
> > the count of methods will increase in geometric progression
>
> I would say it is linear, not geometric.
> Anyway, a common fix for "too many parameters" issue is Parameter Object
> pattern [1],
> I suggest introducing "ServiceProxyConfiguration" class.
>
>
> > We already using such an approach in transactions for example, where we
> > have withLabel, withTracing modifier
>
> I'm not sure this is a good approach and I'd like to avoid using it in more
> places.
> - it looks like a builder pattern, but it is not
> - there is no "withoutTracing" so I can't go back
> - when I get "IgniteTransactions" instance in some method, I don't know if
> tracing is enabled or not, there is no way to check, no way to disable
>
>
> > I'm voting for option (3).
>
> Can you clarify please, is it going to be a new interface, let's say
> IgniteServicesSomething,
> and "IgniteServices extends IgniteServicesSomething"?
>
>
> [1] https://wiki.c2.com/?ParameterObject
>
> On Mon, Dec 20, 2021 at 12:15 PM Alex Plehanov 
> wrote:
>
> > Pavel,
> >
> > As for option (1): the count of methods will increase in geometric
> > progression with each new parameter. For example, if we decide to add
> > tracing to services, we should keep current methods as-is for backward
> > compatibility and add new methods supporting a tracing parameter.
> >
> > > Also, we don't provide methods like withTimeout, withSticky, so adding
> > withContext will introduce another inconsistency.
> > We already using such an approach in transactions for example, where we
> > have withLabel, withTracing modifier, and the timeout method parameter. I
> > think it's nothing wrong here. We can't get rid of timeout and sticky
> > parameters due to backward compatibility.
> >
> > > (3) seems to be too complicate
> > I see no complication here. From the user's point of view - almost nothing
> > changed. The user can use the same IgniteService interface when
> > using services without modifiers. When using modifiers - only interface
> > with methods related to modifiers will be available. In most cases, the
> > user even no need to know about this new interface.
> >
> > I'm voting for option (3).
> >
> > чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn :
> >
> > > Pavel,
> > >
> > > My vote is for option (1). Simple and clear.
> > >
> > > As you noted, with (2) it is not clear which methods are affected.
> > > Also, we don't provide methods like withTimeout, withSticky, so adding
> > > withContext will introduce another inconsistency.
> > >
> > > (3) seems to be too complicated.
> > >
> > > On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin 
> > wrote:
> > >
> > > > Hi folks!
> > > >
> > > > The discussed feature is currently under development and recently
> > > > there was a proposal for an API improvement, which I want to discuss.
> > > >
> > > > It is about how the user can specify a service call context when
> > > > getting a proxy.
> > > >
> > > > I see the following options:
> > > >
> > > > 1. Passing the context as an argument to the proxy getter method.
> > > >
> > > >Ignite.services().serviceProxy(name,..., callCtx)
> > > >
> > > >The disadvantage is that for ease of use, we add several
> > > >overloads of this method with different combinations of parameters.
> > > >
> > > > 2. Adding a new method "withCallContext(callCtx)" (returns
> > > > IgniteServices) to the IgniteServices interface.
> > > >
> > > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...)
> > > >
> > > >The disadvantage is that most of the IgniteServices methods
> > > >are not related to the service call context (deploy, cancel
> > > >of the service, etc.).
> > > >
> > > > 3. (extension of the 2nd option) Adding a new
> > > > "withCallContext(callCtx)" method which returns a new interface.
> > > >
> > > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...)
> > > >
> > > >Unlike the 2nd option, the "withCallContext()" method returns a new
> > > > interface
> > > >(for example, IgniteServiceProxies or IgniteContextAwareServices),
> > > which
> > > >contains only methods that use the service call context.
> > > >
> > > > WDYT?
> > > >
> > > > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin :
> > > > >
> > > > > > 1. Add init/execute/cancel methods without parameters.
> > > > > > 2. Add default no-op implementations for the new methods (this is
> > > > required
> > > > > > to preserve compatibility).
> > > > > > 3. For old methods that take ServiceContext as a parameter, add
> > > default
> > > > > > implementations that delegate to new methods.
> > > > > > 4. Deprecate the old methods on the API.
> > > > > > 5. On the implementation level, still use the old methods (again -
> >

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Alex Plehanov

+1

Checked build from the source, cluster startup with 2 nodes.

пн, 20 дек. 2021 г. в 16:27, Nikolay Izhikov :

> +1 (binding)
>
> > 20 дек. 2021 г., в 16:20, Ivan Daschinsky 
> написал(а):
> >
> > +1 from me
> > Checked ODBC drivers (32-bit and 64-bit) installers on Windows with
> running
> > locally Ignite with
> > pyodbc and python 3.9 using this script [1]
> >
> >
> > [1] --
> https://gist.github.com/ivandasch/6cc0b56e055b826e5840b5c04fa3b2fa
> >
> > пн, 20 дек. 2021 г. в 15:45, Pavel Tupitsyn :
> >
> >> +1
> >>
> >> Checked .NET binaries, nugets, and examples.
> >>
> >> On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> >>>
> >> wrote:
> >>
> >>> Hello!
> >>>
> >>> +1
> >>>
> >>> There seems to be a correct version of log4j2 now.
> >>>
> >>> Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
> >>> quite bad.
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :
> >>>
>  The second release candidate for the 2.11.1 version is ready.
> 
>  Since this is an emergency release the vote will remain open for as
>  short an amount as time as required to vet the release. All votes are
>  welcome and we encourage everyone to test the release, but only PMC
>  votes are “officially” counted. As always, at least 3 +1 votes and
>  more positive than negative votes are required. See voting guidelines:
>  https://www.apache.org/foundation/voting.html
> 
>  +1 - to accept Apache Ignite 2.11.1-rc2
>  0 - don't care either way
>  -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)
> 
> 
>  * RELEASE CANDADATE *
> 
>  Check the release difference between 2.11 and 2.11.1:
>  https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
> 
>  I have uploaded a release candidate to:
>  https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
>  https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/
> 
>  The following staging can be used for testing:
> 
> >>
> https://repository.apache.org/content/repositories/orgapacheignite-1535/
> 
> 
> >>>
> >>
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> 
>  The tag name is 2.11.1-rc2:
> 
> 
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc
> 
>  RELEASE_NOTES:
> 
> 
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
> 
>  Complete list of resolved issues:
> 
> 
> 
> >>>
> >>
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))
> 
> 
>  * CHECKS *
> 
>  Additional checks have been performed (available for users included
> >> into
>  the release group on TeamCity).
> 
>  TC [Check RC: Licenses, compile, chksum]
> 
> 
> >>>
> >>
> https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> 
>  See notes on how to verify release here
>  https://www.apache.org/info/verification.html
>  and
> 
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> 
> >>>
> >>
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
>
>

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Вячеслав Коптилин

Hello,

+1

Thanks,
S.

пн, 20 дек. 2021 г. в 16:26, Nikolay Izhikov :

> +1 (binding)
>
> > 20 дек. 2021 г., в 16:20, Ivan Daschinsky 
> написал(а):
> >
> > +1 from me
> > Checked ODBC drivers (32-bit and 64-bit) installers on Windows with
> running
> > locally Ignite with
> > pyodbc and python 3.9 using this script [1]
> >
> >
> > [1] --
> https://gist.github.com/ivandasch/6cc0b56e055b826e5840b5c04fa3b2fa
> >
> > пн, 20 дек. 2021 г. в 15:45, Pavel Tupitsyn :
> >
> >> +1
> >>
> >> Checked .NET binaries, nugets, and examples.
> >>
> >> On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> >>>
> >> wrote:
> >>
> >>> Hello!
> >>>
> >>> +1
> >>>
> >>> There seems to be a correct version of log4j2 now.
> >>>
> >>> Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
> >>> quite bad.
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :
> >>>
>  The second release candidate for the 2.11.1 version is ready.
> 
>  Since this is an emergency release the vote will remain open for as
>  short an amount as time as required to vet the release. All votes are
>  welcome and we encourage everyone to test the release, but only PMC
>  votes are “officially” counted. As always, at least 3 +1 votes and
>  more positive than negative votes are required. See voting guidelines:
>  https://www.apache.org/foundation/voting.html
> 
>  +1 - to accept Apache Ignite 2.11.1-rc2
>  0 - don't care either way
>  -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)
> 
> 
>  * RELEASE CANDADATE *
> 
>  Check the release difference between 2.11 and 2.11.1:
>  https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
> 
>  I have uploaded a release candidate to:
>  https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
>  https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/
> 
>  The following staging can be used for testing:
> 
> >>
> https://repository.apache.org/content/repositories/orgapacheignite-1535/
> 
> 
> >>>
> >>
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> 
>  The tag name is 2.11.1-rc2:
> 
> 
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc
> 
>  RELEASE_NOTES:
> 
> 
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
> 
>  Complete list of resolved issues:
> 
> 
> 
> >>>
> >>
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))
> 
> 
>  * CHECKS *
> 
>  Additional checks have been performed (available for users included
> >> into
>  the release group on TeamCity).
> 
>  TC [Check RC: Licenses, compile, chksum]
> 
> 
> >>>
> >>
> https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> 
>  See notes on how to verify release here
>  https://www.apache.org/info/verification.html
>  and
> 
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> 
> >>>
> >>
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
>
>

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Nikolay Izhikov

+1 (binding)

> 20 дек. 2021 г., в 16:20, Ivan Daschinsky  написал(а):
> 
> +1 from me
> Checked ODBC drivers (32-bit and 64-bit) installers on Windows with running
> locally Ignite with
> pyodbc and python 3.9 using this script [1]
> 
> 
> [1] -- https://gist.github.com/ivandasch/6cc0b56e055b826e5840b5c04fa3b2fa
> 
> пн, 20 дек. 2021 г. в 15:45, Pavel Tupitsyn :
> 
>> +1
>> 
>> Checked .NET binaries, nugets, and examples.
>> 
>> On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev >> 
>> wrote:
>> 
>>> Hello!
>>> 
>>> +1
>>> 
>>> There seems to be a correct version of log4j2 now.
>>> 
>>> Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
>>> quite bad.
>>> 
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>> 
>>> 
>>> пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :
>>> 
 The second release candidate for the 2.11.1 version is ready.
 
 Since this is an emergency release the vote will remain open for as
 short an amount as time as required to vet the release. All votes are
 welcome and we encourage everyone to test the release, but only PMC
 votes are “officially” counted. As always, at least 3 +1 votes and
 more positive than negative votes are required. See voting guidelines:
 https://www.apache.org/foundation/voting.html
 
 +1 - to accept Apache Ignite 2.11.1-rc2
 0 - don't care either way
 -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)
 
 
 * RELEASE CANDADATE *
 
 Check the release difference between 2.11 and 2.11.1:
 https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
 
 I have uploaded a release candidate to:
 https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
 https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/
 
 The following staging can be used for testing:
 
>> https://repository.apache.org/content/repositories/orgapacheignite-1535/
 
 
>>> 
>> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
 
 The tag name is 2.11.1-rc2:
 
 
>>> 
>> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc
 
 RELEASE_NOTES:
 
 
>>> 
>> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
 
 Complete list of resolved issues:
 
 
 
>>> 
>> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))
 
 
 * CHECKS *
 
 Additional checks have been performed (available for users included
>> into
 the release group on TeamCity).
 
 TC [Check RC: Licenses, compile, chksum]
 
 
>>> 
>> https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
 
 See notes on how to verify release here
 https://www.apache.org/info/verification.html
 and
 
 
>>> 
>> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
 
>>> 
>> 
> 
> 
> -- 
> Sincerely yours, Ivan Daschinskiy

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Ivan Daschinsky

+1 from me
Checked ODBC drivers (32-bit and 64-bit) installers on Windows with running
locally Ignite with
pyodbc and python 3.9 using this script [1]


[1] -- https://gist.github.com/ivandasch/6cc0b56e055b826e5840b5c04fa3b2fa

пн, 20 дек. 2021 г. в 15:45, Pavel Tupitsyn :

> +1
>
> Checked .NET binaries, nugets, and examples.
>
> On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev  >
> wrote:
>
> > Hello!
> >
> > +1
> >
> > There seems to be a correct version of log4j2 now.
> >
> > Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
> > quite bad.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :
> >
> > > The second release candidate for the 2.11.1 version is ready.
> > >
> > > Since this is an emergency release the vote will remain open for as
> > > short an amount as time as required to vet the release. All votes are
> > > welcome and we encourage everyone to test the release, but only PMC
> > > votes are “officially” counted. As always, at least 3 +1 votes and
> > > more positive than negative votes are required. See voting guidelines:
> > > https://www.apache.org/foundation/voting.html
> > >
> > > +1 - to accept Apache Ignite 2.11.1-rc2
> > > 0 - don't care either way
> > > -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)
> > >
> > >
> > > * RELEASE CANDADATE *
> > >
> > > Check the release difference between 2.11 and 2.11.1:
> > > https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
> > >
> > > I have uploaded a release candidate to:
> > > https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
> > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/
> > >
> > > The following staging can be used for testing:
> > >
> https://repository.apache.org/content/repositories/orgapacheignite-1535/
> > >
> > >
> >
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> > >
> > > The tag name is 2.11.1-rc2:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc
> > >
> > > RELEASE_NOTES:
> > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
> > >
> > > Complete list of resolved issues:
> > >
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))
> > >
> > >
> > > * CHECKS *
> > >
> > > Additional checks have been performed (available for users included
> into
> > > the release group on TeamCity).
> > >
> > > TC [Check RC: Licenses, compile, chksum]
> > >
> > >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> > >
> > > See notes on how to verify release here
> > > https://www.apache.org/info/verification.html
> > > and
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> > >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: 0-day CVE in log4j

2021-12-20 Thread Maxim Muzafarov

Vishwas Bm,


I've found the same for the Zookeeper IP finder module.
It seems to me that it must be fixed also.

[1] https://github.com/apache/ignite/blob/master/modules/zookeeper/pom.xml#L114

On Mon, 20 Dec 2021 at 13:39, Vishwas Bm  wrote:
>
> Correct url to rest-http module
>
> https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/rest-http/pom.xml#L131
>
> On Mon, 20 Dec, 2021, 16:06 Vishwas Bm,  wrote:
>
> > Hi,
> >
> > Why is ignite rest module still using old log4j version dependency?
> >
> >
> > https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/log4j/pom.xml#L46
> >
> > Can this be removed ? There is a critical CVE against this package.
> >
> > Regards,
> > Vishwas
> >
> >
> > On Wed, 15 Dec, 2021, 12:57 Aleksandr Nikolaev, 
> > wrote:
> >
> >> Hi folks,
> >>
> >> Ok i'm update log4j version 2.15 to 2.16
> >>
> >> https://issues.apache.org/jira/browse/IGNITE-16127
> >>
> >>
> >> On 15.12.2021 09:54, Pavel Tupitsyn wrote:
> >> > Igniters,
> >> >
> >> > Looks like we need to update to 2.16, there is an additional attack
> >> vector
> >> > [1]
> >> >
> >> > [1]
> >> >
> >> https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
> >> >
> >> > On Mon, Dec 13, 2021 at 4:06 PM Maxim Muzafarov 
> >> wrote:
> >> >
> >> >> Folks,
> >> >>
> >> >> Should we describe all the WA available for the issue [1]? There is
> >> >> already a lot of information about CVE, and nevertheless, it will not
> >> >> be superfluous.
> >> >>
> >> >> [1] https://issues.apache.org/jira/browse/IGNITE-16101
> >> >>
> >> >> On Mon, 13 Dec 2021 at 15:37, Ivan Daschinsky 
> >> wrote:
> >> >>> Unfortunately, we need patch our Log4j2 adapter in order to work with
> >> >>> log4j-2.15
> >> >>> So there is no choice other than to release 2.11.1
> >> >>>
> >> >>> пн, 13 дек. 2021 г. в 15:21, Anton Vinogradov :
> >> >>>
> >>  Folks,
> >> 
> >>  My 200 rubles here,
> >> > I want to include it to the 2.12 scope.
> >>  Why not 2.11.1 as well?
> >>  We should provide a fixed version for current customers asap.
> >>  2.12 require migration, while 2.11.1 can be applied as-is.
> >> 
> >> 
> >>  On Mon, Dec 13, 2021 at 12:18 PM Stephen Darlington <
> >>  stephen.darling...@gridgain.com> wrote:
> >> 
> >> > Another workaround appears to be using the
> >> > -Dlog4j2.formatMsgNoLookups=true option. Also, “Java versions
> >> greater
> >>  than
> >> > 6u211, 7u201, 8u191, and 11.0.1 are less affected by this attack
> >> >> vector,
> >>  at
> >> > least in theory, because the JNDI can't load remote code using
> >> LDAP.”
> >> >
> >> > (
> >> >
> >> >>
> >> https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
> >> > )
> >> >
> >> >> On 12 Dec 2021, at 10:56, Dmitriy Pavlov 
> >> >> wrote:
> >> >> Hi Igniters,
> >> >>
> >> >> Preliminary: change of the log4j version does not affect any tests
> >> >> (Alexander Nikolaev, correct me if I'm wrong).
> >> >>
> >> >> If you're using embedded Ignite, it's perfectly possible to enforce
> >> > jog4j2
> >> >> dependency to be 2.15.0 in your project final pom.xml or
> >> >> build.gradle
> >>  or
> >> >> any other build system properties.
> >> >>
> >> >> https://issues.apache.org/jira/browse/IGNITE-16101 ticket seems
> >> >> to be
> >> >> a blocker for 2.12. But for now, as a workaround, it's possible to
> >>  select
> >> >> the latest version manually.
> >> >>
> >> >> Sincerely,
> >> >> Dmitriy Pavlov
> >> >>
> >> >> сб, 11 дек. 2021 г. в 09:47, Nikita Amelchev  >> >>> :
> >> >>> Hello.
> >> >>>
> >> >>> The issue to update dependency was created:
> >> >>> https://issues.apache.org/jira/browse/IGNITE-16101
> >> >>>
> >> >>> I want to include it to the 2.12 scope.
> >> >>>
> >> >>> сб, 11 дек. 2021 г., 09:19 Raymond Wilson <
> >> >> raymond_wil...@trimble.com
> >> > :
> >>  All
> >> 
> >>  This blew up today: CVE-2021-44228 (
> >> 
> >> 
> >> >>
> >> https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/
> >>  )
> >> 
> >>  Will there be a risk assessment with respect to Ignite for this
> >> >> CVE?
> >>  Thanks,
> >>  Raymond.
> >> 
> >>  --
> >>  
> >>  Raymond Wilson
> >>  Trimble Distinguished Engineer, Civil Construction Software (CCS)
> >>  11 Birmingham Drive | Christchurch, New Zealand
> >>  raymond_wil...@trimble.com
> >> 
> >>  <
> >> 
> >> >>
> >> https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch
> >> >
> >> >
> >> >>>
> >> >>> --
> >> >>> Sincerely yours,

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Pavel Tupitsyn

+1

Checked .NET binaries, nugets, and examples.

On Mon, Dec 20, 2021 at 3:42 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> +1
>
> There seems to be a correct version of log4j2 now.
>
> Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
> quite bad.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :
>
> > The second release candidate for the 2.11.1 version is ready.
> >
> > Since this is an emergency release the vote will remain open for as
> > short an amount as time as required to vet the release. All votes are
> > welcome and we encourage everyone to test the release, but only PMC
> > votes are “officially” counted. As always, at least 3 +1 votes and
> > more positive than negative votes are required. See voting guidelines:
> > https://www.apache.org/foundation/voting.html
> >
> > +1 - to accept Apache Ignite 2.11.1-rc2
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)
> >
> >
> > * RELEASE CANDADATE *
> >
> > Check the release difference between 2.11 and 2.11.1:
> > https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
> >
> > I have uploaded a release candidate to:
> > https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
> > https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/
> >
> > The following staging can be used for testing:
> > https://repository.apache.org/content/repositories/orgapacheignite-1535/
> >
> >
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
> >
> > The tag name is 2.11.1-rc2:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc
> >
> > RELEASE_NOTES:
> >
> >
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
> >
> > Complete list of resolved issues:
> >
> >
> >
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))
> >
> >
> > * CHECKS *
> >
> > Additional checks have been performed (available for users included into
> > the release group on TeamCity).
> >
> > TC [Check RC: Licenses, compile, chksum]
> >
> >
> https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
> >
> > See notes on how to verify release here
> > https://www.apache.org/info/verification.html
> > and
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
> >
>

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Ilya Kasnacheev

Hello!

+1

There seems to be a correct version of log4j2 now.

Btw, I've noticed that we ship log2j 1.x with ignite-rest-http. This is
quite bad.

Regards,
-- 
Ilya Kasnacheev


пн, 20 дек. 2021 г. в 15:35, Maxim Muzafarov :

> The second release candidate for the 2.11.1 version is ready.
>
> Since this is an emergency release the vote will remain open for as
> short an amount as time as required to vet the release. All votes are
> welcome and we encourage everyone to test the release, but only PMC
> votes are “officially” counted. As always, at least 3 +1 votes and
> more positive than negative votes are required. See voting guidelines:
> https://www.apache.org/foundation/voting.html
>
> +1 - to accept Apache Ignite 2.11.1-rc2
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)
>
>
> * RELEASE CANDADATE *
>
> Check the release difference between 2.11 and 2.11.1:
> https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1
>
> I have uploaded a release candidate to:
> https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
> https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/
>
> The following staging can be used for testing:
> https://repository.apache.org/content/repositories/orgapacheignite-1535/
>
> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite
>
> The tag name is 2.11.1-rc2:
>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc
>
> RELEASE_NOTES:
>
> https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1
>
> Complete list of resolved issues:
>
>
> https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))
>
>
> * CHECKS *
>
> Additional checks have been performed (available for users included into
> the release group on TeamCity).
>
> TC [Check RC: Licenses, compile, chksum]
>
> https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
>
> See notes on how to verify release here
> https://www.apache.org/info/verification.html
> and
>
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification
>

[VOTE] Release Apache Ignite 2.11.1 RC2

2021-12-20 Thread Maxim Muzafarov

The second release candidate for the 2.11.1 version is ready.

Since this is an emergency release the vote will remain open for as
short an amount as time as required to vet the release. All votes are
welcome and we encourage everyone to test the release, but only PMC
votes are “officially” counted. As always, at least 3 +1 votes and
more positive than negative votes are required. See voting guidelines:
https://www.apache.org/foundation/voting.html

+1 - to accept Apache Ignite 2.11.1-rc2
0 - don't care either way
-1 - DO NOT accept Apache Ignite Ignite 2.11.1-rc2 (explain why)


* RELEASE CANDADATE *

Check the release difference between 2.11 and 2.11.1:
https://github.com/apache/ignite/compare/ignite-2.11...ignite-2.11.1

I have uploaded a release candidate to:
https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc2/
https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc2/

The following staging can be used for testing:
https://repository.apache.org/content/repositories/orgapacheignite-1535/
https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite

The tag name is 2.11.1-rc2:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=eae1147dd1cd625cc229098489be8d208f6cabcc

RELEASE_NOTES:
https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.11.1

Complete list of resolved issues:

https://issues.apache.org/jira/issues/?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.11.1%27))


* CHECKS *

Additional checks have been performed (available for users included into
the release group on TeamCity).

TC [Check RC: Licenses, compile, chksum]
https://ci.ignite.apache.org/viewLog.html?buildId=6333527=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages

See notes on how to verify release here
https://www.apache.org/info/verification.html
and
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification

Re: [DISCUSS] Custom service proxy context

2021-12-20 Thread Pavel Tupitsyn

Alex,

> the count of methods will increase in geometric progression

I would say it is linear, not geometric.
Anyway, a common fix for "too many parameters" issue is Parameter Object
pattern [1],
I suggest introducing "ServiceProxyConfiguration" class.


> We already using such an approach in transactions for example, where we
> have withLabel, withTracing modifier

I'm not sure this is a good approach and I'd like to avoid using it in more
places.
- it looks like a builder pattern, but it is not
- there is no "withoutTracing" so I can't go back
- when I get "IgniteTransactions" instance in some method, I don't know if
tracing is enabled or not, there is no way to check, no way to disable


> I'm voting for option (3).

Can you clarify please, is it going to be a new interface, let's say
IgniteServicesSomething,
and "IgniteServices extends IgniteServicesSomething"?


[1] https://wiki.c2.com/?ParameterObject

On Mon, Dec 20, 2021 at 12:15 PM Alex Plehanov 
wrote:

> Pavel,
>
> As for option (1): the count of methods will increase in geometric
> progression with each new parameter. For example, if we decide to add
> tracing to services, we should keep current methods as-is for backward
> compatibility and add new methods supporting a tracing parameter.
>
> > Also, we don't provide methods like withTimeout, withSticky, so adding
> withContext will introduce another inconsistency.
> We already using such an approach in transactions for example, where we
> have withLabel, withTracing modifier, and the timeout method parameter. I
> think it's nothing wrong here. We can't get rid of timeout and sticky
> parameters due to backward compatibility.
>
> > (3) seems to be too complicate
> I see no complication here. From the user's point of view - almost nothing
> changed. The user can use the same IgniteService interface when
> using services without modifiers. When using modifiers - only interface
> with methods related to modifiers will be available. In most cases, the
> user even no need to know about this new interface.
>
> I'm voting for option (3).
>
> чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn :
>
> > Pavel,
> >
> > My vote is for option (1). Simple and clear.
> >
> > As you noted, with (2) it is not clear which methods are affected.
> > Also, we don't provide methods like withTimeout, withSticky, so adding
> > withContext will introduce another inconsistency.
> >
> > (3) seems to be too complicated.
> >
> > On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin 
> wrote:
> >
> > > Hi folks!
> > >
> > > The discussed feature is currently under development and recently
> > > there was a proposal for an API improvement, which I want to discuss.
> > >
> > > It is about how the user can specify a service call context when
> > > getting a proxy.
> > >
> > > I see the following options:
> > >
> > > 1. Passing the context as an argument to the proxy getter method.
> > >
> > >Ignite.services().serviceProxy(name,..., callCtx)
> > >
> > >The disadvantage is that for ease of use, we add several
> > >overloads of this method with different combinations of parameters.
> > >
> > > 2. Adding a new method "withCallContext(callCtx)" (returns
> > > IgniteServices) to the IgniteServices interface.
> > >
> > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...)
> > >
> > >The disadvantage is that most of the IgniteServices methods
> > >are not related to the service call context (deploy, cancel
> > >of the service, etc.).
> > >
> > > 3. (extension of the 2nd option) Adding a new
> > > "withCallContext(callCtx)" method which returns a new interface.
> > >
> > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...)
> > >
> > >Unlike the 2nd option, the "withCallContext()" method returns a new
> > > interface
> > >(for example, IgniteServiceProxies or IgniteContextAwareServices),
> > which
> > >contains only methods that use the service call context.
> > >
> > > WDYT?
> > >
> > > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin :
> > > >
> > > > > 1. Add init/execute/cancel methods without parameters.
> > > > > 2. Add default no-op implementations for the new methods (this is
> > > required
> > > > > to preserve compatibility).
> > > > > 3. For old methods that take ServiceContext as a parameter, add
> > default
> > > > > implementations that delegate to new methods.
> > > > > 4. Deprecate the old methods on the API.
> > > > > 5. On the implementation level, still use the old methods (again -
> > for
> > > > > compatibility).
> > > > > 6. Finally, add a @ServiceContextResource annotation to inject
> > > > > ServiceContext.
> > > >
> > > > I like this idea and I have filed a ticket for this change [1].
> > > > If there is no objection, I plan to implement this shortly.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-15801
> > > >
> > > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov :
> > > > >
> > > > > > and it fully switches to annotation-based injection.

Re: [CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

2021-12-20 Thread Anton Vinogradov

The ability to kill applications is less important than gaining access.
We may release 2.11.2 if necessary.
But now we must release 2.11.1 asap because it fixes a critical security
issue.

On Mon, Dec 20, 2021 at 2:01 PM Ivan Daschinsky  wrote:

> What do you mean, Anton? This is quite dangerous vulnerability and it is
> recommended to update log4j asap.
>
> пн, 20 дек. 2021 г. в 14:00, Anton Vinogradov :
>
> > Maxim,
> > Look like an issue is not related to security problems we fix.
> > Any reason to cancel the vote (delay release) to include this bugfix?
> >
> > On Mon, Dec 20, 2021 at 1:28 PM Maxim Muzafarov 
> wrote:
> >
> > > Cancelling the vote.
> > >
> > > I'll cherry-pick the following [1] to the release branch and prepare a
> > > new RC today.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-16153
> > >
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>

Re: [CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

2021-12-20 Thread Ivan Daschinsky

What do you mean, Anton? This is quite dangerous vulnerability and it is
recommended to update log4j asap.

пн, 20 дек. 2021 г. в 14:00, Anton Vinogradov :

> Maxim,
> Look like an issue is not related to security problems we fix.
> Any reason to cancel the vote (delay release) to include this bugfix?
>
> On Mon, Dec 20, 2021 at 1:28 PM Maxim Muzafarov  wrote:
>
> > Cancelling the vote.
> >
> > I'll cherry-pick the following [1] to the release branch and prepare a
> > new RC today.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-16153
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

2021-12-20 Thread Anton Vinogradov

Maxim,
Look like an issue is not related to security problems we fix.
Any reason to cancel the vote (delay release) to include this bugfix?

On Mon, Dec 20, 2021 at 1:28 PM Maxim Muzafarov  wrote:

> Cancelling the vote.
>
> I'll cherry-pick the following [1] to the release branch and prepare a
> new RC today.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-16153
>

Re: 0-day CVE in log4j

2021-12-20 Thread Vishwas Bm

Correct url to rest-http module

https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/rest-http/pom.xml#L131

On Mon, 20 Dec, 2021, 16:06 Vishwas Bm,  wrote:

> Hi,
>
> Why is ignite rest module still using old log4j version dependency?
>
>
> https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/log4j/pom.xml#L46
>
> Can this be removed ? There is a critical CVE against this package.
>
> Regards,
> Vishwas
>
>
> On Wed, 15 Dec, 2021, 12:57 Aleksandr Nikolaev, 
> wrote:
>
>> Hi folks,
>>
>> Ok i'm update log4j version 2.15 to 2.16
>>
>> https://issues.apache.org/jira/browse/IGNITE-16127
>>
>>
>> On 15.12.2021 09:54, Pavel Tupitsyn wrote:
>> > Igniters,
>> >
>> > Looks like we need to update to 2.16, there is an additional attack
>> vector
>> > [1]
>> >
>> > [1]
>> >
>> https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
>> >
>> > On Mon, Dec 13, 2021 at 4:06 PM Maxim Muzafarov 
>> wrote:
>> >
>> >> Folks,
>> >>
>> >> Should we describe all the WA available for the issue [1]? There is
>> >> already a lot of information about CVE, and nevertheless, it will not
>> >> be superfluous.
>> >>
>> >> [1] https://issues.apache.org/jira/browse/IGNITE-16101
>> >>
>> >> On Mon, 13 Dec 2021 at 15:37, Ivan Daschinsky 
>> wrote:
>> >>> Unfortunately, we need patch our Log4j2 adapter in order to work with
>> >>> log4j-2.15
>> >>> So there is no choice other than to release 2.11.1
>> >>>
>> >>> пн, 13 дек. 2021 г. в 15:21, Anton Vinogradov :
>> >>>
>>  Folks,
>> 
>>  My 200 rubles here,
>> > I want to include it to the 2.12 scope.
>>  Why not 2.11.1 as well?
>>  We should provide a fixed version for current customers asap.
>>  2.12 require migration, while 2.11.1 can be applied as-is.
>> 
>> 
>>  On Mon, Dec 13, 2021 at 12:18 PM Stephen Darlington <
>>  stephen.darling...@gridgain.com> wrote:
>> 
>> > Another workaround appears to be using the
>> > -Dlog4j2.formatMsgNoLookups=true option. Also, “Java versions
>> greater
>>  than
>> > 6u211, 7u201, 8u191, and 11.0.1 are less affected by this attack
>> >> vector,
>>  at
>> > least in theory, because the JNDI can't load remote code using
>> LDAP.”
>> >
>> > (
>> >
>> >>
>> https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
>> > )
>> >
>> >> On 12 Dec 2021, at 10:56, Dmitriy Pavlov 
>> >> wrote:
>> >> Hi Igniters,
>> >>
>> >> Preliminary: change of the log4j version does not affect any tests
>> >> (Alexander Nikolaev, correct me if I'm wrong).
>> >>
>> >> If you're using embedded Ignite, it's perfectly possible to enforce
>> > jog4j2
>> >> dependency to be 2.15.0 in your project final pom.xml or
>> >> build.gradle
>>  or
>> >> any other build system properties.
>> >>
>> >> https://issues.apache.org/jira/browse/IGNITE-16101 ticket seems
>> >> to be
>> >> a blocker for 2.12. But for now, as a workaround, it's possible to
>>  select
>> >> the latest version manually.
>> >>
>> >> Sincerely,
>> >> Dmitriy Pavlov
>> >>
>> >> сб, 11 дек. 2021 г. в 09:47, Nikita Amelchev > >>> :
>> >>> Hello.
>> >>>
>> >>> The issue to update dependency was created:
>> >>> https://issues.apache.org/jira/browse/IGNITE-16101
>> >>>
>> >>> I want to include it to the 2.12 scope.
>> >>>
>> >>> сб, 11 дек. 2021 г., 09:19 Raymond Wilson <
>> >> raymond_wil...@trimble.com
>> > :
>>  All
>> 
>>  This blew up today: CVE-2021-44228 (
>> 
>> 
>> >>
>> https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/
>>  )
>> 
>>  Will there be a risk assessment with respect to Ignite for this
>> >> CVE?
>>  Thanks,
>>  Raymond.
>> 
>>  --
>>  
>>  Raymond Wilson
>>  Trimble Distinguished Engineer, Civil Construction Software (CCS)
>>  11 Birmingham Drive | Christchurch, New Zealand
>>  raymond_wil...@trimble.com
>> 
>>  <
>> 
>> >>
>> https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch
>> >
>> >
>> >>>
>> >>> --
>> >>> Sincerely yours, Ivan Daschinskiy
>>
>

Re: 0-day CVE in log4j

2021-12-20 Thread Vishwas Bm

Hi,

Why is ignite rest module still using old log4j version dependency?

https://github.com/apache/ignite/blob/21f7ca41c4348909e2fd26ccf59b5b2ce1f4474e/modules/log4j/pom.xml#L46

Can this be removed ? There is a critical CVE against this package.

Regards,
Vishwas


On Wed, 15 Dec, 2021, 12:57 Aleksandr Nikolaev, 
wrote:

> Hi folks,
>
> Ok i'm update log4j version 2.15 to 2.16
>
> https://issues.apache.org/jira/browse/IGNITE-16127
>
>
> On 15.12.2021 09:54, Pavel Tupitsyn wrote:
> > Igniters,
> >
> > Looks like we need to update to 2.16, there is an additional attack
> vector
> > [1]
> >
> > [1]
> >
> https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
> >
> > On Mon, Dec 13, 2021 at 4:06 PM Maxim Muzafarov 
> wrote:
> >
> >> Folks,
> >>
> >> Should we describe all the WA available for the issue [1]? There is
> >> already a lot of information about CVE, and nevertheless, it will not
> >> be superfluous.
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-16101
> >>
> >> On Mon, 13 Dec 2021 at 15:37, Ivan Daschinsky 
> wrote:
> >>> Unfortunately, we need patch our Log4j2 adapter in order to work with
> >>> log4j-2.15
> >>> So there is no choice other than to release 2.11.1
> >>>
> >>> пн, 13 дек. 2021 г. в 15:21, Anton Vinogradov :
> >>>
>  Folks,
> 
>  My 200 rubles here,
> > I want to include it to the 2.12 scope.
>  Why not 2.11.1 as well?
>  We should provide a fixed version for current customers asap.
>  2.12 require migration, while 2.11.1 can be applied as-is.
> 
> 
>  On Mon, Dec 13, 2021 at 12:18 PM Stephen Darlington <
>  stephen.darling...@gridgain.com> wrote:
> 
> > Another workaround appears to be using the
> > -Dlog4j2.formatMsgNoLookups=true option. Also, “Java versions greater
>  than
> > 6u211, 7u201, 8u191, and 11.0.1 are less affected by this attack
> >> vector,
>  at
> > least in theory, because the JNDI can't load remote code using LDAP.”
> >
> > (
> >
> >>
> https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
> > )
> >
> >> On 12 Dec 2021, at 10:56, Dmitriy Pavlov 
> >> wrote:
> >> Hi Igniters,
> >>
> >> Preliminary: change of the log4j version does not affect any tests
> >> (Alexander Nikolaev, correct me if I'm wrong).
> >>
> >> If you're using embedded Ignite, it's perfectly possible to enforce
> > jog4j2
> >> dependency to be 2.15.0 in your project final pom.xml or
> >> build.gradle
>  or
> >> any other build system properties.
> >>
> >> https://issues.apache.org/jira/browse/IGNITE-16101 ticket seems
> >> to be
> >> a blocker for 2.12. But for now, as a workaround, it's possible to
>  select
> >> the latest version manually.
> >>
> >> Sincerely,
> >> Dmitriy Pavlov
> >>
> >> сб, 11 дек. 2021 г. в 09:47, Nikita Amelchev  >>> :
> >>> Hello.
> >>>
> >>> The issue to update dependency was created:
> >>> https://issues.apache.org/jira/browse/IGNITE-16101
> >>>
> >>> I want to include it to the 2.12 scope.
> >>>
> >>> сб, 11 дек. 2021 г., 09:19 Raymond Wilson <
> >> raymond_wil...@trimble.com
> > :
>  All
> 
>  This blew up today: CVE-2021-44228 (
> 
> 
> >>
> https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/
>  )
> 
>  Will there be a risk assessment with respect to Ignite for this
> >> CVE?
>  Thanks,
>  Raymond.
> 
>  --
>  
>  Raymond Wilson
>  Trimble Distinguished Engineer, Civil Construction Software (CCS)
>  11 Birmingham Drive | Christchurch, New Zealand
>  raymond_wil...@trimble.com
> 
>  <
> 
> >>
> https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch
> >
> >
> >>>
> >>> --
> >>> Sincerely yours, Ivan Daschinskiy
>

[CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

2021-12-20 Thread Maxim Muzafarov

Cancelling the vote.

I'll cherry-pick the following [1] to the release branch and prepare a
new RC today.

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

Re: [DISCUSS] Custom service proxy context

2021-12-20 Thread Alex Plehanov

Pavel,

As for option (1): the count of methods will increase in geometric
progression with each new parameter. For example, if we decide to add
tracing to services, we should keep current methods as-is for backward
compatibility and add new methods supporting a tracing parameter.

> Also, we don't provide methods like withTimeout, withSticky, so adding
withContext will introduce another inconsistency.
We already using such an approach in transactions for example, where we
have withLabel, withTracing modifier, and the timeout method parameter. I
think it's nothing wrong here. We can't get rid of timeout and sticky
parameters due to backward compatibility.

> (3) seems to be too complicate
I see no complication here. From the user's point of view - almost nothing
changed. The user can use the same IgniteService interface when
using services without modifiers. When using modifiers - only interface
with methods related to modifiers will be available. In most cases, the
user even no need to know about this new interface.

I'm voting for option (3).

чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn :

> Pavel,
>
> My vote is for option (1). Simple and clear.
>
> As you noted, with (2) it is not clear which methods are affected.
> Also, we don't provide methods like withTimeout, withSticky, so adding
> withContext will introduce another inconsistency.
>
> (3) seems to be too complicated.
>
> On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin  wrote:
>
> > Hi folks!
> >
> > The discussed feature is currently under development and recently
> > there was a proposal for an API improvement, which I want to discuss.
> >
> > It is about how the user can specify a service call context when
> > getting a proxy.
> >
> > I see the following options:
> >
> > 1. Passing the context as an argument to the proxy getter method.
> >
> >Ignite.services().serviceProxy(name,..., callCtx)
> >
> >The disadvantage is that for ease of use, we add several
> >overloads of this method with different combinations of parameters.
> >
> > 2. Adding a new method "withCallContext(callCtx)" (returns
> > IgniteServices) to the IgniteServices interface.
> >
> >Ignite.services().withCallContext(callCtx).serviceProxy(name,...)
> >
> >The disadvantage is that most of the IgniteServices methods
> >are not related to the service call context (deploy, cancel
> >of the service, etc.).
> >
> > 3. (extension of the 2nd option) Adding a new
> > "withCallContext(callCtx)" method which returns a new interface.
> >
> >Ignite.service().withCallContext(callCtx).serviceProxy(name,...)
> >
> >Unlike the 2nd option, the "withCallContext()" method returns a new
> > interface
> >(for example, IgniteServiceProxies or IgniteContextAwareServices),
> which
> >contains only methods that use the service call context.
> >
> > WDYT?
> >
> > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin :
> > >
> > > > 1. Add init/execute/cancel methods without parameters.
> > > > 2. Add default no-op implementations for the new methods (this is
> > required
> > > > to preserve compatibility).
> > > > 3. For old methods that take ServiceContext as a parameter, add
> default
> > > > implementations that delegate to new methods.
> > > > 4. Deprecate the old methods on the API.
> > > > 5. On the implementation level, still use the old methods (again -
> for
> > > > compatibility).
> > > > 6. Finally, add a @ServiceContextResource annotation to inject
> > > > ServiceContext.
> > >
> > > I like this idea and I have filed a ticket for this change [1].
> > > If there is no objection, I plan to implement this shortly.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-15801
> > >
> > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov :
> > > >
> > > > > and it fully switches to annotation-based injection.
> > > >
> > > > +1 to do it.
> > > >
> > > > > 19 окт. 2021 г., в 22:14, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> написал(а):
> > > > >
> > > > > That's actually a good point. In Java, we can do the following:
> > > > > 1. Add init/execute/cancel methods without parameters.
> > > > > 2. Add default no-op implementations for the new methods (this is
> > required
> > > > > to preserve compatibility).
> > > > > 3. For old methods that take ServiceContext as a parameter, add
> > default
> > > > > implementations that delegate to new methods.
> > > > > 4. Deprecate the old methods on the API.
> > > > > 5. On the implementation level, still use the old methods (again -
> > for
> > > > > compatibility).
> > > > > 6. Finally, add a @ServiceContextResource annotation to inject
> > > > > ServiceContext.
> > > > >
> > > > > If I haven't missed anything, this is not a breaking change, and it
> > fully
> > > > > switches to annotation-based injection.
> > > > >
> > > > > I'm not sure this is possible in .NET though.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin <
> xxt...@gmail.com>
> > wrote:
> > > > >
>

Re: [DISCUSSION] Reject join of nodes with different character encodings

2021-12-20 Thread Mikhail Petrov


Thank you all for your replies!
I got the idea and agreed with it. Based on the results of the 
discussion, I have filed a ticket [1].

I will try to investigate it.

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

On 16.12.2021 20:11, Ivan Daschinsky wrote:

Andrey, agree with you, good point.

чт, 16 дек. 2021 г., 16:27 Andrey Mashenkov :


Guys,

I like the idea with a flag, but for a different purpose.
I think it is easy to detect the issue (using the flag) when
metastorage was created on a new version with a fixed charset, or on an
older version with the user-defined default.
Regarding the flag, we can choose a new strategy forcing UTF-8, or fallback
to the old one with defaultCharset and print a warning and recommendation
in log.

Adding any compatibility stuff is absolutely error-prone because if you
fail in the middle of restoring process, you will get broken metastorage
with keys in different charsets.
At this point, there is no way to detect broken keys anymore.

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

Re: [DISCUSSION] Reject join of nodes with different character encodings

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

Re: [DISCUSSION] Reject join of nodes with different character encodings

Re: [DISCUSSION] Reject join of nodes with different character encodings

Re: [DISCUSS] Custom service proxy context

Re: [DISCUSS] Custom service proxy context

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

Re: 0-day CVE in log4j

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

Re: [VOTE] Release Apache Ignite 2.11.1 RC2

[VOTE] Release Apache Ignite 2.11.1 RC2

Re: [DISCUSS] Custom service proxy context

Re: [CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

Re: [CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

Re: [CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

Re: 0-day CVE in log4j

Re: 0-day CVE in log4j

[CANCEL] [VOTE] Release Apache Ignite 2.11.1 RC1

Re: [DISCUSS] Custom service proxy context

Re: [DISCUSSION] Reject join of nodes with different character encodings

26 matches

Site Navigation

Mail list logo

Footer information