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
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
+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
> > >
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
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
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
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
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
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
+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
> >
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
+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] --
+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
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
>
>
+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
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.
>
>
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”
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
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
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
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
>
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?
>
>
>
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
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
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
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,
26 matches
Mail list logo
