Congrats, Slava!
ср, 19 февр. 2020 г. в 08:38, Ivan Pavlukhin :
>
> Hooray!
>
> Best regards,
> Ivan Pavlukhin
>
> ср, 19 февр. 2020 г. в 00:28, Dmitriy Govorukhin
> :
> >
> > My congratulations, Slava!
> >
> > On Tue, Feb 18, 2020 at 11:33 PM Andrey Kuznetsov wrote:
> >
> > > Congratulations,
Congratulations, Slava!
вт, 18 февр. 2020 г., 22:20 Dmitriy Pavlov :
> Hello Ignite Community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Vyacheslav Koptilin to become a committer and we are pleased to announce
> that he has accepted.
>
> Vyacheslav investigated
Hooray!
Best regards,
Ivan Pavlukhin
ср, 19 февр. 2020 г. в 00:28, Dmitriy Govorukhin :
>
> My congratulations, Slava!
>
> On Tue, Feb 18, 2020 at 11:33 PM Andrey Kuznetsov wrote:
>
> > Congratulations, Slava!
> >
> > вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov :
> >
> > > Hello Ignite
My congratulations, Slava!
On Tue, Feb 18, 2020 at 11:33 PM Andrey Kuznetsov wrote:
> Congratulations, Slava!
>
> вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov :
>
> > Hello Ignite Community,
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited
> > Vyacheslav Koptilin to
Congratulations, Slava!
вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov :
> Hello Ignite Community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Vyacheslav Koptilin to become a committer and we are pleased to announce
> that he has accepted.
>
> Vyacheslav investigated
Valerii Shinkevich created IGNITE-12698:
---
Summary: Configurable application name for yarn
Key: IGNITE-12698
URL: https://issues.apache.org/jira/browse/IGNITE-12698
Project: Ignite
Hello Ignite Community,
The Project Management Committee (PMC) for Apache Ignite has invited
Vyacheslav Koptilin to become a committer and we are pleased to announce
that he has accepted.
Vyacheslav investigated and fixed a number of non-trivial issues in the
Ignite Native persistent store, was
Valerii Shinkevich created IGNITE-12697:
---
Summary: Ignite YARN containers don't start properly for no
apparent reason.
Key: IGNITE-12697
URL: https://issues.apache.org/jira/browse/IGNITE-12697
Ilya, looks like there is a misunderstanding.
We don't start near cache on a subset of server nodes. Let me explain again.
Consider the following code, executed on any node (client or server - does
not matter):
ignite.createCache(new CacheConfiguration("c").setNearConfiguration(new
Hello!
I have ran nightlies, it runs OK (with exception of MVCC Cache 7 which seem
to always hang on master) but there's virtually no speed difference in this
run.
Still, I think it makes sense to fix number of threads used. WDYT? I would
be glad to have a formal review.
Regards,
--
Ilya
Hello!
I'm not sure that we can/want to create near cache on a subset of server
nodes.
If this is indeed possible, I would decouple that from .Net and introduce
as a separate feature.
Ideally we should be able to start or stop near cache on any node, server
or client, and this should be the
Andrey N. Gura created IGNITE-12696:
---
Summary: Remove deprecated @MXBeanParametersNames and
@MXBeanParametersDescriptions annotations
Key: IGNITE-12696
URL: https://issues.apache.org/jira/browse/IGNITE-12696
Ilya, as noted above:
> There are 2 kinds of Near Caches:
> - On client nodes: created per-node by calling ignite.CreateNearCache
> - On server nodes: created on all server nodes if
CacheConfiguration.NearCacheConfiguration is not null
>
> When user says ignite.CreateCache(new CacheConfiguration
Hello!
Why would it waste additional memory? All nodes are also Java nodes so they
will start near caches all right.
Don't we have near cache start-up on per-node basis for clients, anyway?
I'm not convinced why we need this flag. I have to admit my understanding
of near caches is limited.
Ilya, Aleksandr,
The flag is called platformNearCacheEnabled, my idea is to have just one
flag for all platforms.
If some platform is present on the given node (.NET, C++) and it supports
native near caching,
then the flag is honored, otherwise it is ignored. We should not throw
exceptions,
Pavel,
I think it’s ok to add a new flag.
Though we may change a name to something like #usePlatformCacheIfAvailable
But it may vary depending on the implementation, i.e.
should we throw an error if there is no native cache
available for a platform or just ignore the configuration.
вт,
Hello!
I suggest parametrizing it with platformId, to make it possible to
implement in e.g. C++ later without creating yet another parameter. Maybe
we can migrate Java near caches to same mechanism in the future.
Why would enabling it affect mixed clusters?
Regards,
--
Ilya Kasnacheev
вт, 18
Hello!
I have added you, so you may proceed assigning tickets to yourself.
Please read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
Regards,
--
Ilya Kasnacheev
вт, 18 февр. 2020 г. в 14:20, Алексей Высотин :
> Hello Ignite Community,
>
> My name is Alexey and I'm a
Igor Seliverstov created IGNITE-12695:
-
Summary: Calcite integration. DML support. MERGE support
Key: IGNITE-12695
URL: https://issues.apache.org/jira/browse/IGNITE-12695
Project: Ignite
Igor,
The problem is - we need to pass this flag around the cluster for Server
Near Caches,
so that .NET near caches are started accordingly.
There are 2 kinds of Near Caches:
- On client nodes: created on every client node separately by calling
ignite.CreateNearCache
- On server nodes: created
By the way, some ODBC tests became flaky about the same time as well.
May it be there is one root cause somewhere in SQL?
Best Regards,
Igor
On Mon, Feb 17, 2020 at 9:36 PM Pavel Tupitsyn wrote:
> I did a quick look some time ago, no idea what is going on, honestly. Tests
> became flaky for
Do you suggest to introduce it in general configuration? Why not introduce
it only on platform side? Is there any .NET-specific configuration?
Best Regards,
Igor
On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn wrote:
> Igniters,
>
> I'm working on .NET Near Cache feature [1]
> (storing
Hello!
A single runAll of this code was 5h faster than regular master, in net
time, but this might as well be measurement artifact. I will compare Run
All Nightly which I have already started.
Regards,
--
Ilya Kasnacheev
пн, 17 февр. 2020 г. в 18:04, Ivan Pavlukhin :
> Ilya,
>
> > 5 is
Hi, Alex, do you have any experience with Ignite itself? if no, I could
suggest you to run cluster on a few nodes before development and run
examples.
What kind of Ignite tickets are you looking for?
Core/SQL/ML/Tests/Docs/anything else?
вт, 18 февр. 2020 г. в 14:20, Алексей Высотин :
> Hello
Hello Ignite Community,
My name is Alexey and I'm a Java and Scala developer with a current focus
on Big Data stack like Spark and Hadoop.
I would like to take part in the Apache Ignite project and make a
contribution to it.
I'm thinking to start with some easy fix or bugfix to get more
Igniters,
I've prepared the issue [1] and PR [2] with removing @deprecate
annotation on DataRegionMetrics and adding @IgniteExperimental to the
new metrics API.
Can anyone review my changes?
[1] https://issues.apache.org/jira/browse/IGNITE-12690
[2] https://github.com/apache/ignite/pull/7440
Alexey Scherbakov created IGNITE-12694:
--
Summary: A possible partition desync if last supplier has left and
returned later.
Key: IGNITE-12694
URL: https://issues.apache.org/jira/browse/IGNITE-12694
Hello!
I have just merged a fix for embarrassing issue where you could UPDATE
entries with Spring Data, but not "Update" or "update" them.
I suggest adding this fix to the scope of 2.8, since Spring Data is popular
and it does not in any way affect code outside of its modules.
Hello, Alexey.
> We need to agree whether IgniteMxBean#active(boolean) and
> Ignite#active(boolean) behaving differently is ok from the user side.
I think it’s not OK.
We should provide consistent behavior for all management APIs: jmx, control.sh,
REST, Java API.
The primary use-case I keep
I do not think the change size can even be an argument for not doing a
proper improvement. We need to agree whether IgniteMxBean#active(boolean)
and Ignite#active(boolean) behaving differently is ok from the user side.
Folks,
Looks like we came to an agreement - rebalanceDelay and rebalanceOrder
should be deprecated.
Anyone else has objections ?
чт, 13 февр. 2020 г. в 14:40, Alexei Scherbakov <
alexey.scherbak...@gmail.com>:
> But in combination with BLT it will work as intended - no rebalancing
> under
Nikolai Kulagin created IGNITE-12693:
Summary: Incorrect operation of the eviction policy internal
counter
Key: IGNITE-12693
URL: https://issues.apache.org/jira/browse/IGNITE-12693
Project:
32 matches
Mail list logo
