Max,
Thanks for spotting this, great catch!
Zhenya, could you please file a ticket of at least Critical priority?
On Fri, Oct 9, 2020 at 9:24 AM Zhenya Stanilovsky
wrote:
>
>
> Thanks Maxim, the test is correct no need for removal.
> I checked 2.9 too, but looks it all ok there. I will take a
Hello Sergey,
I went over the public API changes briefly and left some minor comments on
GitHub
Thanks,
Pavel
On Fri, Oct 9, 2020 at 9:59 AM Sergey Chugunov
wrote:
> Hello Igniters,
>
> I'm getting closer to finishing main ticket for Maintenance Mode feature
> [1] and now working on test fixes
Hello, Igniters.
I prepared a patch [1] for blocker ticket [2] - «Server node fail and stops in
case wrong datatype put in indexed field»
Can someone, please, help me with the review?
[1] https://github.com/apache/ignite/pull/8330
[2] https://issues.apache.org/jira/browse/IGNITE-13553
Hi everyone,
I believe I have a fix for this bug -
https://issues.apache.org/jira/browse/IGNITE-13500, So Zhenya you can leave
this problem to me.
--
Best regards,
Anton Kalashnikov
09.10.2020, 10:19, "Sergey Chugunov" :
> Max,
>
> Thanks for spotting this, great catch!
>
> Zhenya, could yo
Ivan Daschinskiy created IGNITE-13564:
-
Summary: Improve SYSTEM_WORKER_BLOCKED reporting.
Key: IGNITE-13564
URL: https://issues.apache.org/jira/browse/IGNITE-13564
Project: Ignite
Issue T
Mikhail,
+1 for migrate
чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov :
>
> Igniters,
>
> I propose to migrate spring-data modules from ignite main repository to
> ignite-extensions.
>
>
> Are there any objections?
>
>
> I've created ticket [1] and PR to both ignite [2] and ignite-extensions
> [3] r
Of course, i still have no ticket filled. As was discussed in private i will
fill other ticket that can lead to potential problems.
>Hi everyone,
>
>I believe I have a fix for this bug -
>https://issues.apache.org/jira/browse/IGNITE-13500, So Zhenya you can leave
>this problem to me.
>
>--
+1.
Saikat, can you, please, take a look?
> 9 окт. 2020 г., в 11:54, Nikita Amelchev написал(а):
>
> Mikhail,
>
> +1 for migrate
>
> чт, 8 окт. 2020 г. в 18:34, Mikhail Petrov :
>>
>> Igniters,
>>
>> I propose to migrate spring-data modules from ignite main repository to
>> ignite-extension
Hello!
-1 from me for now.
"Since Spring Data integration is actively used (compared to most others),
I would argue that it should only moved to extensions last, when this
process is debugged thoroughly and when we have at least one "essentials +
extensions" release shipped with feedback.
I thin
Test0/cache-default/index.bin
>>> +---+
>>> Ignite ver. 2.10.0-SNAPSHOT#20201009-sha1:DEV
>>> +---+
at
org.apache.ignite.internal.processors.cache.persistence.fi
Ilya, we should move modules that is not related to Ignite core to extension.
We shouldn’t support all possible integrations in the Ignite itself.
> I would argue that it should only moved to extensions last,
> when this process is debugged thoroughly and when we have at least one
> "essentials
Yury Gerzhedovich created IGNITE-13566:
--
Summary: Calcite integration. Table size statistics for cost planer
Key: IGNITE-13566
URL: https://issues.apache.org/jira/browse/IGNITE-13566
Project: Igni
Hi, Igniters.
While working with ignite-extensions, I've faced some mismatch with naming of
tag for extension:
Artifact is 'ignite-spring-boot-autoconfigure-ext'
Module is 'spring-boot-autoconfigure-ext'
But tag is 'ignite-spring-boot-1.0.0'
Can we:
1. match tag name with either module arti
+1
And, as a matter of fact, I think that spring data integration should be in
spring-projects organization, just like spring-data-neo4j, spring-data-mongodb
and the others. This way we will always have spring-data integration working
correctly with the latest version of spring-data.
09.10.2020
Denis,
I would suggest to stay on a safe ground and associate an every commit
with a ticket until we have a Community decision about relaxing this
process for documentation tickets. As far as I remember sometimes as
an exception we use a single ticket number for multiple commits (e.g.
fix licenses
Amelchev Nikita created IGNITE-13567:
Summary: TcpDiscoverySpi: incorrect value of the joiningNodeClient
flag for the joining client
Key: IGNITE-13567
URL: https://issues.apache.org/jira/browse/IGNITE-13567
Hello!
I mean the Apache Ignite 2.9 release and Ignite Extensions 1.0 release.
Once we get that in the wild and gather a few months of feedback (or lack
thereof) then we can go on with it.
Regards,
--
Ilya Kasnacheev
пт, 9 окт. 2020 г. в 12:42, Nikolay Izhikov :
> Ilya, we should move modules
Yury Gerzhedovich created IGNITE-13568:
--
Summary: Calcite integration. Decrease bounds of index scan
Key: IGNITE-13568
URL: https://issues.apache.org/jira/browse/IGNITE-13568
Project: Ignite
Ilya, I haven't meant that removal of spring-data from Ignite main
repository should be done before the 2.9 release and be included in it.
Migration of spring-data to ignite-extensions could help us to make
SpringData integration updates available for users earlier then the next
Ignite release
Ilya.
My understanding is the following - there is no such thing as «Ignite
Extensions release»
We can and should release each module separately.
You can take as an example - spring-boot-autoconfigure extension release.
I made it without releasing any other modules.
This mean - we can release
Anton Kalashnikov created IGNITE-13569:
--
Summary: disable archiving + walCompactionEnabled probably broke
reading from wal on server restart
Key: IGNITE-13569
URL: https://issues.apache.org/jira/browse/IGNITE
Hi Pavel,
Thanks, I looked through your comments and fixed them. Could you please
check one more time?
On Fri, Oct 9, 2020 at 10:27 AM Pavel Tupitsyn wrote:
> Hello Sergey,
>
> I went over the public API changes briefly and left some minor comments on
> GitHub
>
> Thanks,
> Pavel
>
> On Fri, Oc
+1
I said about it few months ago.
пт, 9 окт. 2020 г., 15:13 Nikolay Izhikov :
> Ilya.
>
> My understanding is the following - there is no such thing as «Ignite
> Extensions release»
> We can and should release each module separately.
>
> You can take as an example - spring-boot-autoconfigure ext
Hi Bojidar,
Welcome to the Apache Ignite Community!
I added your account to a contributors list, now you can assign
tickets to yourself. Am I getting it right that your contribution is
in .NET part?
Also it could be helpful to get familiar with a contribution process
https://cwiki.apache.org/con
Hi Igniters,
If we are using ignite in a web service,can we reuse single IgniteClient for
all requests or we have to create IgniteClient for each requests??
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
On Fri, Oct 9, 2020 at 5:15 PM Ivan Pavlukhin wrote:
> Hi Bojidar,
>
> Welcome to the Apache Ignite Community!
>
> Thanks!
> I added your account to a contributors list, now you can assign
> tickets to yourself. Am I getting it right that your contribution is
> in .NET part?
>
> Indeed, it is a
Bojidar,
While my knowledge can be outdated, but in my time it was required to
create a pull request in GitHub and launch a TC bot check against that
PR manually.
2020-10-09 18:08 GMT+03:00, Bojidar Marinov :
> On Fri, Oct 9, 2020 at 5:15 PM Ivan Pavlukhin wrote:
>
>> Hi Bojidar,
>>
>> Welcome t
Hey Ivan,
According to the "How to contribute" document, submitting patch files is a
valid alternative to github pull requests, refs
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-2.CreateaPatch-file
.
If that information is outdated, I would happily open a pu
Hello!
In any case, we need to release *something* and wait for it to be used by
actual users.
Currently this is not happening since 2.8.1 contains all extensions as
modules.
Regards,
--
Ilya Kasnacheev
пт, 9 окт. 2020 г. в 15:12, Nikolay Izhikov :
> Ilya.
>
> My understanding is the followi
Bojidar,
Sincerely I never used an approach with attaching patch files. It
would be great if you can open PR.
I suppose we should check with the Community whether a patch file
approach is outdated and delete the section from the guide if it is.
2020-10-09 18:27 GMT+03:00, Bojidar Marinov :
> Hey
How do we release all the modules that have already been moved to the
extensions repository?
https://github.com/apache/ignite-extensions/tree/master/modules
For instance, when 2.9 comes out and the users start bumping up their
Ignite versions in pom.xml, what should they set for Kafka, camel, etc.
Nikolay,
re: the minor improvements. I'm not against of including those if we can
prepare the docs before the vote starts. Presently, the docs are "frozen"
for the 2.9 release, but I can scratch some time and take part in the docs
review the next week.
-
Denis
On Fri, Oct 9, 2020 at 12:40 AM Ni
It's preferable to use a single client connection. The clients are
multi-threaded, if I'm not mistaken. Btw, what type of the client you use
(.NET, Java, ...)?
-
Denis
On Fri, Oct 9, 2020 at 7:53 AM midulaj wrote:
> Hi Igniters,
>
> If we are using ignite in a web service,can we reuse single I
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New Critical Failure in master-nightly Disk Page Compressions
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_DiskPageCompressions?branch=%3Cdefault%3E
No changes
Hi Nikolay,
I have reviewed the PR and shared my comments.
Ilya,
My thoughts are that as soon the ignite 2.9.0 is released we should be able
to release the ignite-extensions module 1st version pointing to
ignite-core 2.9.0
version. So, for example ignite-flink-ext version 1.0.0 will be dependent
Hi Mikhail,
Also once the changes are complete please add modules details and
Testsuites in the teamcity build config
https://ci.ignite.apache.org/admin/editBuildParams.html?id=buildType:Tests_IgniteExtensions_Build
Regards,
Saikat
On Fri, Oct 9, 2020 at 7:09 AM Mikhail Petrov wrote:
> Ilya, I
Hi Petr,
Can you please share if the tag you are referring to is git release tag or
changes required in some other file?
If it is git release tag we can follow the naming convention as
ignite-spring-boot-autoconfigure-ext-1.0.1 going forward.
Regards,
Saikat
On Fri, Oct 9, 2020 at 5:11 AM Petr
37 matches
Mail list logo