Re: IEP-70: Async Continuation Executor

I don't agree that the code isn't related to Ignite - it is something that the user does via Ignite API, so they would be right to expect Ignite to handle the invocations. One more thing I'd like to mention - monitoring. I don't think commonPool exposes anything to JMX by default, and a custom e

Re: IEP-70: Async Continuation Executor

Thought about this some more. I agree that we need to be able to switch to synchronous listeners when it's critical for performance. However, I don't like to introduce an Executor property for that. In fact, the only value we really expect the user to set in that property is Runnable::run - see

Re: IEP-70: Async Continuation Executor

ly with > existing IgniteFuture#listenAsync, > not sure why you dislike it. > > > [1] > https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html > > On Mon, Mar 29, 2021 at 10:23 PM Stanislav Lukyanov > wrote: > >> Thought about this som

Re: IEP-70: Async Continuation Executor

27;m OK to proceed with the approach you're suggesting if I haven't > convinced you by now > > Are you OK to merge the changes as is (ForkJoinPool#commonPool as the > default executor), > or do we change it to Ignite public pool? > > On Mon, Mar 29, 2021 at 11:0

Re: IEP-70: Async Continuation Executor

nyway, I'll leave to you to decide. > On 15 Apr 2021, at 11:02, Stanislav Lukyanov wrote: > > Hi Pavel, > > I'd prefer public pool. > > Thanks, > Stan > >> On 12 Apr 2021, at 20:17, Pavel Tupitsyn wrote: >> >> Stan, >> >> S

Re: Exceeding the DataStorageConfiguration#getMaxWalArchiveSize due to historical rebalance

+1 to cancel WAL reservation on reaching getMaxWalArchiveSize +1 to add a public property to replace IGNITE_THRESHOLD_WAL_ARCHIVE_SIZE_PERCENTAGE I don't like the name getWalArchiveSize - I think it's a bit confusing (is it the current size? the minimal size? the target size?) I suggest to name

Re: Exceeding the DataStorageConfiguration#getMaxWalArchiveSize due to historical rebalance

ave a limit of M gigabytes to store it". Do we have checkpoint timestamp stored anywhere? (cp start markers?) Perhaps we can actually implement this? Thanks, Stan > On 6 May 2021, at 14:13, Stanislav Lukyanov wrote: > > +1 to cancel WAL reservation on reaching getMaxWalArchiv

Re: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

Hi Eduard, I strongly believe that if a configuration option is cluster wide then it belongs to distributed metastore and not to IgniteConfiguration. This allows to get cluster-wide consistency guarantees and API for dynamic change out of the box (need to teach the internals to re-read the prope

Re: Exceeding the DataStorageConfiguration#getMaxWalArchiveSize due to historical rebalance

d by Kirill. Stan > On 7 May 2021, at 15:09, ткаленко кирилл wrote: > > Stas hello! > > I didn't quite get your last idea. > What will we do if we reach getMaxWalArchiveSize? Shall we not delete the > segment until minWalArchiveTimespan? > > 06.05.2021,

Re: Exceeding the DataStorageConfiguration#getMaxWalArchiveSize due to historical rebalance

hvieSize properties as the >> solution, >> with the behavior as initially described by Kirill. >> >> Stan >> >> >>> On 7 May 2021, at 15:09, ткаленко кирилл wrote: >>> >>> Stas hello! >>> >>> I didn't quite get your la

Re: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

, >>> >>> I think this is an excellent idea to use distributed metastore. >>> >>> Should I leave system property for backward compatibility? >>> >>> >>> On Sun, 9 May 2021 at 19:04, Atri Sharma wrote: >>> >>>> +1 >>&

API Proposal: Declare IgniteClient::close that throws no exceptions (IGNITE-15688)

Hi Igniters, I found the following usability issue with java thin client API. Whenever you do `try (IgniteClient client = Ignition.startClient(cfg))`, you're forced to declare `catch (Exception e)`. This is because IgniteClient interface currently doesn't override close() from AutoClosable. Be

Re: API Proposal: Declare IgniteClient::close that throws no exceptions (IGNITE-15688)

Patch, PR and visa are in the ticket. Igor, please review and merge when you're ready. Thanks, Stan > On 6 Oct 2021, at 12:54, Igor Sapego wrote: > > Sounds good, no objections from my side. > > Best Regards, > Igor > > > On Wed, Oct 6, 2021 at 11:4

Re: [WANTED A NEW RELEASE MANAGER] Apache Ignite 3.0.0 beta 1 RELEASE

Thanks Slava. For me, that's a dream team of two! :) Happy to work in this way if there are no objections. Thanks, Stan > On 13 Oct 2022, at 17:08, Andrey Gura wrote: > > Slava, Stan, > > formally Stan can't be a release manager because he isn't a committer. So > it would be better if Slava wi

Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE

There are 11 unresolved tickets in the scope now, 4 In Progress and 7 Patch Available. I think we should try to set the code freeze according to the ticket estimates instead of just setting it to the end of next week. I'll work with each ticket owner to determine the critical path. I also saw

Re: [Sugestion] Switching ignite scheduler to cron-utils

Hi Lukasz, Ilya, I completely agree with Ilya that the core Ignite modules shouldn't deal with that. That said, I've seen numerous situations when people tried to implement scheduling of tasks for Ignite. Sometimes, they wouldn't do it in a distributed fashion, and it would because the hosting

Re: [DISCUSSION] Change default behaviour of atomic operations inside transactions

Hi all, Can someone please clarify what specific changes will be implemented in 2.15 and 2.16? What will be in release notes in 2.15 and 2.16? Thanks, Stan > On 18 Oct 2022, at 21:50, Nikita Amelchev wrote: > > Hi, Maksim. > > I think marking the issue as 'important' and filling out the rele

Re: [DISCUSSION] Change default behaviour of atomic operations inside transactions

t; > See merged PR: https://github.com/apache/ignite/pull/10327/files > > сб, 22 окт. 2022 г. в 17:42, Stanislav Lukyanov : >> >> Hi all, >> >> Can someone please clarify what specific changes will be implemented in 2.15 >> and 2.16? What will be in rel

Re: [DISCUSSION] Change default behaviour of atomic operations inside transactions

>> Hi, Stan! >>>> >>>>>> Say, I have an ATOMIC and TRANSACTIONAL caches in my system, and I >>> need >>>> to change them at the same time >>>> >>>> Looks very unreliable. Which guarantees users expect from Ignite in

Re: [DISCUSSION] Add DataStreamer's default per-node-batch-setting for PDS.

Hi Vladimir, I think this is potentially an issue but I don't think this is about PDS at all. The description is a bit vague, I have to say. AFAIU what you see is that when the caches are persistent the streamer writes data faster than the nodes (especially, backup nodes) process the writes. Th

Re: [Sugestion] Switching ignite scheduler to cron-utils

hich is > closes to non distributed fashion you mentioned. > If we will end up building additional logic for it we'll definitely look for > consultation and another contribution to ignite project. > > WRT ignite-schedule removal, should it first go over deprecation cycle in >

Re: Shutdown policy refactoring

Hi Aleksandr, Thanks for driving this. Someone should put a stop to the shutdown behavior nonsense :) But let me complicate things a bit for you. I see multiple dimensions that are in play when node shutdown happens: - Running operations (Compute, SQL, Cache): interrupt or wait for completion

Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE

ail Pochatkin >> >>> >>> wrote: >>> >>>> Hello, Igniters. >>>> >>>> I want to point out that the current beta seems to be blocked by >>>> [IGNITE-17966] <https://issues.apache.org/jira/browse/IGNITE-17966>. >

Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE

out that the current beta seems to be blocked by >>>> [IGNITE-17966] <https://issues.apache.org/jira/browse/IGNITE-17966>. >> The >>>> main problem is that we cannot enable Gradle build on CI at this >> moment, >>>> but we need it because all

Re: Apache Ignite 3.0.0 beta 1 RELEASE [Time, Scope, Manager]

Igniters, The initial code freeze date for 3.0.0 beta 1 was missed, so we need to pick a new timeline. There are currently 5 tickets in progress or in review that are in the scope, with significant progress in each of them. Let's set the following dates: Scope Freeze: October 12, 2022 Code Fr

Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE

I also added https://issues.apache.org/jira/browse/IGNITE-17989 and https://issues.apache.org/jira/browse/IGNITE-17357 to the scope. Stan > On 4 Nov 2022, at 18:26, Игорь Гусев wrote: > > > Hi Igniters, > > I’d like to include some doc into beta1 if its not too late > https://issues.apache.o

Re: Apache Ignite 3.0.0 beta 1 RELEASE [Time, Scope, Manager]

have been playing with the beta branch already in the past weeks. Stan > On 2 Nov 2022, at 15:19, Igor Sapego wrote: > > +1 from me > > Best Regards, > Igor > > > On Wed, Nov 2, 2022 at 3:48 AM Stanislav Lukyanov > wrote: > >> Igniters, >> >

Re: [VOTE] Release Apache Ignite 3.0.0-beta1 RC1

Pavel, Regarding .NET client binaries - do you mean .dll files? Do you think they should be a part of the .zip? The same .zip or a separate one? Isn't nuget package enough for .NET ecosystem? Thanks, Stan > On 9 Nov 2022, at 19:55, Pavel Tupitsyn wrote: > > Also: > - Source code is missing (

Re: [VOTE] Release Apache Ignite 3.0.0-beta1 RC1

still >> include Java client binaries in the zip file. >> >> Anyway, I'm ok with NuGet-only binaries, but let's include them in the set >> of files for the vote, like we do in 2.x, so the package can be tested. >> >> On Thu, Nov 10, 2022 at 3:46 PM S

Re: Hint for user that baseline topology should be changed in order to trigger rebalance

We already have a ticket for this open BTW: https://issues.apache.org/jira/browse/IGNITE-8115 . I would also avoid saying anything about rebalancing - at this point the user may not know what it is. This message is very clearly targeted at new

Re: Extended logging for rebalance performance analysis

Kirill, I've looked through the patch. Looks good, but it feels like the first thing someone will try to do given bytesRcvd and duration is to divide one by another to get an average speed. Do you think it's reasonable to also add it to the logs? Maybe even to the metrics? Also, this works with

Re: [DISCUSSION] Add index rebuild time metrics

If multiple indexes are to be built "number of indexed keys" metric may be misleading. As a cluster admin, I'd like to know: - Are all indexes ready on a node? - How many indexes are to be built? - How much resources are used by the index building (how many threads are used)? - Which index(es?) i

Re: Extended logging for rebalance performance analysis

nomalies. Second, this allows to automate alerts: e.g. if you know your typical historical rebalance speed, you can trigger an alert if it drops below that. > > 03.07.2020, 02:49, "Stanislav Lukyanov" : >> Kirill, >> >> I've looked through the patch. >&g

Re: Proposal of new event QUERY_EXECUTION_EVENT

Maksim, Can we change the EVT_CACHE_QUERY_EXECUTED to fire earlier? Or should there be an EVT_CACHE_QUERY_EXECUTION_STARTED for the query start, while the old event would continue to work for query finish? I think the new event needs to either reuse the old one, or be its mirror for the query s

Re: Extended logging for rebalance performance analysis

topVer=AffinityTopologyVersion [topVer=4, >> minorTopVer=0], progress=1/3, rebalanceId=1] >> >> 3) Completion of the entire rebalance. >> Completed rebalance chain: [rebalanceId=1, partitions=116, entries=400, >> duration=41ms, bytesRcvd=40,4 KB] >> >> These m

Re: [DISCUSSION] Add index rebuild time metrics

t;> "IsIndexRebuildInProgress", "IndexBuildCountPartitionsLeft". >> >> I suggest adding another metric "Indexrebuildkeyprocessed", which will >> allow you to determine how many records are left to rebuild for cache. >> >> I think your comments are

Re: [DISCUSSION] Cache warmup

Kirill, Thanks for driving this. This is awaited by many users. A few comments and questions. I would keep CacheWarmup interface purely internal and never view it as an interface which a user would be implementing. There are multiple reasons for that: - The logic of the cache warmup is very lo

Re: [DISCUSSION] Cache warmup

Hi Kirill, Alexey, On the interface structure. So, as a user I'll see one interface, WarmUpConfiguration, with no methods. I choose an implementation and configure it like cfg.setWarmUpConfiguration(new LoadEverythingWarmupConfiguration()); Ignite tries to map the LoadEverythingWarmupConfigura

Re: [DISCUSSION] Cache warmup

All of this looks awesome, covers the use cases I know about. Thanks! Stan > On 10 Aug 2020, at 15:39, ткаленко кирилл wrote: > > Hi, Stan again :-) > > I suggest adding a little more flexibility to configuration: > 1)Add default warm-up configuration for all regions into > org.apache.ignite.

Re: Changes in run.sh script

I believe that remote JMX access should NOT be enabled by default in any Ignite distributions - neither docker nor regular binary package. Enabling remote JMX requires caution. It is a powerful interface, and the fact that ignite.sh enables it by default with no security (!) bothers me a lot. On

IGNITE-13364: Improve index inline defaults

Hi Igniters, I'd like to discuss the change implemented by Evgeniy Rudenko in the ticket https://issues.apache.org/jira/browse/IGNITE-13364. I see that the fix is ready for review and merging, and I'm interested in it so I'd like to pick it up on the last mile. I also wanted to bring community's

RE: [DISCUSSION] Control.sh global rework in apache ignite 3.0

Hi, Sounds good. I agree with all points so far. I don’t really see why to wait for 3.0 though. As long as the old commands work I think it’s fine to do all of that in a minor release. Even moving the code to a separate module is fine as all the classes are internal and unlikely to be used in

RE: [DISCUSSION] Control.sh global rework in apache ignite 3.0

rework utility in 2.8 release. ср, 23 янв. 2019 г. в 18:48, Stanislav Lukyanov : > Hi, > > Sounds good. I agree with all points so far. > > I don’t really see why to wait for 3.0 though. > As long as the old commands work I think it’s fine to do all of that in a > minor

Review and merge IGNITE-10921

Hi Igniters, Can anyone please review and merge IGNITE-10921? Artur Muradimov contributed the change, I did a review myself and now we need a committer to finish this. Thanks, Stan

.Net docs need to be aligned with Java - dev review needed!

Hi Igniters, I see that some parts of the .Net docs on readme.io are outdated compared to the Java docs. E.g. take off-heap memory page https://apacheignite-net.readme.io/docs/off-heap-memory - the info there is for Ignite 1.x while in 2.x we don’t have all these tiered modes. Such discrepancie

Starting with missing PDS pieces

Hi Igniters, I’d like to talk about Ignite startup when we have some of the persistence files missing. This is related to the topic “Ignite index corruption issue -> unrecoverable cluster” that is discussed nearby, but not exactly the same – I’d like to avoid talking about indexes for now (let

RE: IgniteServices.serviceProxy and local services

I don’t think we should change the existing method contract – localFirst=true as a default looks OK. But a new method that allows to change that to localFirst=false is nice. Checking service() for a local service first is not that great when your proxy isn’t sticky. You may want to have a non-st

RE: Starting with missing PDS pieces

oncharuk was proposing a data recovery tool which might apply WALs and make cluster recoverable. Alex, could you remind us about this? Do you see other scenarios firing off in production? - Denis On Mon, Feb 4, 2019 at 12:34 AM Stanislav Lukyanov wrote: > Hi Igniters, > > I’d like to

RE: Ignite index corruption issue -> unrecoverable cluster

From: Denis Magda Sent: 7 февраля 2019 г. 3:12 To: dev; Stanislav Lukyanov Subject: Re: Ignite index corruption issue -> unrecoverable cluster Stan, Thanks for staring "Starting with missing PDS pieces" that is promising to embed usability changes into the source code. In the meanti

RE: Consistent ID specification from previous random UUID

Dmitry, I seems to me that the algorithm of using different schemes for persistence folder naming is flawe. Why don’t we just name the folder same as consistent ID all the time? How about the following algorithm of db folder and consistenID generation 1.. If the consistent ID is explicitly set to

RE: JVM warnings during Java 11 startup

Guys, The issue is that we chose the easiest way to start working with Java 9+, which is the illegal-access=permit. This is a blanket option that affects the whole VM which is better to avoid – hence the warnings. A better solution is to use --add-opens statements. Same as add-exports, one needs

RE: ipFinder configuration for Samples

Yakov, Our product is for engineers sitting in one office. Companies which use Ignite have many engineers running Ignite on their laptops the same way as companies that make changes to Ignite. “Could it be because of the multicast?” is one of the questions I ask every time I see a question on S

RE: Volunteer needed: AWS Elastic Load Balancer IP Findersimplemented

Hi, I took a look at the code, and I believe the patch needs to be enhanced. The patch is about adding TcpDiscoveryApplicationElbIpFinder, but it also deprecates the existing TcpDiscoveryElbIpFinder and replaces it with its copy named TcpDiscoveryClassicElbIpFinder. I’d really prefer if the exi

RE: Volunteer needed: AWS Elastic Load Balancer IP Findersimplemented

then share the results of their testing together with the usual TC link. Stan From: Stanislav Lukyanov Sent: 2 октября 2018 г. 19:08 To: dev@ignite.apache.org Subject: RE: Volunteer needed: AWS Elastic Load Balancer IP Findersimplemented Hi, I took a look at the code, and I believe the patch needs

RE: Applicability of term 'cache' to Apache Ignite

How about separating our JCache implementation from the core of the probuct. Currently IgniteCache is the heart of Ignite. It is the basic storage unit. At the same time, it is the direct implementation of the JCache API, and some of the JCache features align somewhat awkwardly with Ignite concept

RE: Abbreviation code-style requirement.

+ for all three. I got used to seeing `cctx` and `ccfg` all over the place, but I remember the sorrow of seeing all of that the first time. I guess it’s nothing but a Stockholm syndrome now and I’m willing to cure myself :) Stan From: Eduard Shangareev Sent: 16 октября 2018 г. 19:01 To: dev@ig

RE: Applicability of term 'cache' to Apache Ignite

d it. Moreover, it is hard to say whether we will have SQL > > API at all, because this is big effort with not very clear value, > provided > > that there are industrial interfaces (JDBC, ODBC). > > > > On Tue, Oct 16, 2018 at 3:23 PM Stanislav Lukyanov < > stanl

Partition Loss Policies issues

Hi Igniters, I've been looking into various scenarios of Partition Loss Policies usage recently, and found a number of issues in the current implementation. I'll start with an overview, but if you'd like to dive to a proposal I have right now then please feel free to scroll down to TLDR. The l

Re: Splitting cache and basic TC configuration on pure in-memory and persistent one

Hi all, I'm reviving this thread because it seems to me that it might be better to go back to the combined in-memory and PDS suites now. As usual, it is a long one, so feel free to skip to the TLDR. The decision for the split was mostly driven by the desire to have shorter time of suite runs. It

RE: Query regarding Ignite unit tests

Hi, This is better to be asked on the dev-list – added that to the To, and Bcc’ed user-list. I actually don’t think you can run tests for a specific module – either a single test, or a single test suite, or all of them. I would usually either run a single test from IDEA or run all tests via Te

RE: Pre-touch for Ignite off-heap memory

Igniters, What is being suggested here is an Ignite off-heap’s version of Java’s -XX:+AlwaysPreTouch. The latter is known to be used to guarantee that the committed memory is backed by physical RAM. This ensures that a) JVM doesn’t have to do it during the actual work (avoiding overhead for phy

RE: Pre-touch for Ignite off-heap memory

> > - allocate all on startup AND pre touch. > > - allocate specific data region for first assignment. > > - allocate specific data region for first assignment AND pre > touch. > > > > What do you think? > > > > [1] https://issues.apach

RE: Asynchronous index rebuild

Hi Vladimir, Thanks for this summary! Why the third option and not the second? The process of join-leave-build indexes-rejoin sounds kind of heavy. Topology changes are complex because of PME, so I think the less PME – the better. Rejoin to build indexes also means that not having indexes for

Re: Pre-touch for Ignite off-heap memory

tisfied if lazy region initialization > is enabled. Am I missing something? > пн, 17 дек. 2018 г. в 18:11, Stanislav Lukyanov : > > > > I don’t think these two issues require to be solved together, although I > agree there is some connection. > > > > > > >

RE: Volunteer needed: AWS Elastic Load Balancer IP Findersimplemented

; helpful to know whether TC can accept properties while initiating a run. > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist > > > > Uday > > > > On Tue, Oct 2, 2018 at 9:58 PM Stanislav Lukyanov < > stanlukya...@gmail.co

RE: REST GridCacheCommandHandler writes ERROR in log in case of baduser input

+1. ERROR and even WARNING messages are often treated as incidents in the production systems. Ignite produces a lot of these messages though. I’d suggest the following as a rule of thumb: - ERROR – we’re sure there is an issue with a node/cluster that needs attention; cluster stability and/or d

RE: REST GridCacheCommandHandler writes ERROR in log in case ofbaduser input

:12, Stanislav Lukyanov : > +1. > > ERROR and even WARNING messages are often treated as incidents in the > production systems. > Ignite produces a lot of these messages though. > > I’d suggest the following as a rule of thumb: > - ERROR – we’re sure there is an issue with a

RE: REST GridCacheCommandHandler writes ERROR in log in caseofbaduser input

when we discover internal errors. We could try and isolate cases when we are sure that there is error on user side, change log level for such errors. Regards, -- Ilya Kasnacheev чт, 20 дек. 2018 г. в 17:20, Stanislav Lukyanov : > I think that the error detected in the server’s SQL engine is

RE: REST GridCacheCommandHandler writes ERROR in log in caseofbaduser input

More food for thought - here are JCL guidelines that look close to what I’ve suggested: http://commons.apache.org/proper/commons-logging/guide.html#JCL_Best_Practices Big thanks to Oleg Ignatenko for the pointer. Thanks, Stan From: Stanislav Lukyanov Sent: 20 декабря 2018 г. 17:20 To: dev

RE: Volunteer needed: AWS Elastic Load Balancer IP Findersimplemented

at 12:09 AM Stanislav Lukyanov wrote: > Hi, > > Regarding the name - a not-so-good name isn’t always a sufficient > justification for renaming. > Public products such as Ignite have to also take into account convenience > for existing users. > Even in 3.0 when we technically

RE: S3 discovery and docker bridge networks

I thought about the same thing when using machines with Docker installed – it seems that regex/subnet exclusion really would help. I wonder if there are corner cases when it wouldn’t work well though. We’d need to handle this in both TcpCommunicationSpi and TcpDiscoverySpi. Probably even some vie

RE: Service grid redesign

I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code. I’ve left some comments – almost all are about minor issues, grammar and code style. Stan From: Vyacheslav Daradur Sent: 21 декабря 2018 г. 14:58 To: dev@ignite.apache.org Subject:

RE: control.bat authentication support

3:53 AM, Stanislav Lukyanov wrote: Hi,   Ignite doesn’t provide built-in support for authentication, so the built-in control.bat/sh also don’t have stubs for that. So yes, I guess you need to write your own tool.   A tool like that would be pretty simple though – just start a client node, parse

RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts

Hi folks, It looks like we stopped half-way with this activity. I’d like to pick it up. All seem to agree that we should simplify the timeout settings. Here are the specific actions I’d like to propose: 1. Promote the use of global timeouts as the best practice *What*: update the docs to encoura

RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts

e behavior of timeouts you listed in #2 - this can lead to unexpected behavior for users who already use them. I would just deprecate them and eventually remove. -Val On Mon, May 28, 2018 at 1:29 PM, Stanislav Lukyanov wrote: > Hi folks, > > It looks like we stopped half-way with this ac

RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts

e its behavior. Can we just deprecate it and eventually remove, just as we plan to do for all timeouts from #2? -Val On Tue, May 29, 2018 at 3:50 AM, Stanislav Lukyanov wrote: > Val, > > Which timeouts do you mean? > > In #2 I don’t propose to change behavior. > > I propose to chang

RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts

> same setting for TcpCommunicationSpi, BTW? If yes, behavior should be > consistent. > > As for TcpCommunicationSpi.socketWriteTimeout, I'm not sure why you want > to > change its behavior. Can we just deprecate it and eventually remove, just > as we plan to do for all timeouts from #2? >

RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts

e two timeouts? -Val On Wed, Jul 4, 2018 at 7:00 AM Stanislav Lukyanov wrote: > Hi, > > I’ve updated the proposed documentation update with a description of > metricsUpdateFrequency and a detailed description of > failureDetectionTimeout and clientFailureDetectionTimeout relat

Move CacheStore::loadCache to a separate interface

Hi Igniters, I’ve just created a ticket to move CacheStore::loadCache to a separate interface: https://issues.apache.org/jira/browse/IGNITE-8952 In short, this is to provide a way to only implement loadCache without messing with other methods CacheStore implements. More details are in the JIRA.

RE: Move CacheStore::loadCache to a separate interface

think it would be a nice newbie ticket. Stan From: Dmitry Pavlov Sent: 6 июля 2018 г. 16:25 To: dev@ignite.apache.org Subject: Re: Move CacheStore::loadCache to a separate interface As far as I understand we should to wait 3.0, shouldn't we? пт, 6 июл. 2018 г. в 16:17, Stanislav Lukyanov :

RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts

on client or on server? -Val On Fri, Jul 6, 2018 at 6:12 AM Stanislav Lukyanov wrote: > We could just use failureDetectionTimeout all the time I guess. > The only benefit of clientFailureDetectionTimeout is that it may allow > clients to be slower/on a slower network than servers. &

RE: Can .NET thin client have cache expire policy?

The same question is being discussed on the user-list: https://stackoverflow.com/questions/51314852/is-there-a-workaround-to-use-thin-client-with-cache-expiry-policy-in-apache-igni Stan From: Dmitriy Setrakyan Sent: 16 июля 2018 г. 3:03 To: dev Cc: Pavel Tupitsyn Subject: Can .NET thin client ha

RE: Can .NET thin client have cache expire policy?

Oops, wrong link. The correct one: http://apache-ignite-users.70518.x6.nabble.com/Thin-client-doesn-t-support-Expiry-Policies-tt22422.html From: Stanislav Lukyanov Sent: 16 июля 2018 г. 14:18 To: dev@ignite.apache.org Subject: RE: Can .NET thin client have cache expire policy? The same question

Pushing IGNITE-6826 forward

Hi Igniters, There is a small but annoying issue with examples using MulticastIpFinder by default. The JIRA is IGNITE-6826. AntonK and DmitriiR have suggested PRs to fix this, but PavelT had some concerns and the fix stuck as the result. Pavel, could you please suggest necessary changes to th

RE: Pushing forward IGNITE-6826: Change default DiscoverySpi ipFinder type for examples

ily clicked to find out details. It can seem not important, but saves a minute for everyone. Sincerely, Dmitriy Pavlov ср, 18 июл. 2018 г. в 16:32, Stanislav Lukyanov : > Hi Igniters, > > There is a small but annoying issue with examples using MulticastIpFinder > by default. > The JI

RE: Baseline topology without persistence

Currently BLT can’t be used without persistence – only persistent caches are affected by it. AFAIR making non-persistent caches make use of the baseline topology is the plan for IEP-4 Phase 2. Thanks, Stan From: Valentin Kulichenko Sent: 19 июля 2018 г. 0:04 To: dev@ignite.apache.org Subject: B

RE: Pushing IGNITE-6826 forward

vlov > > ср, 18 июл. 2018 г. в 16:32, Stanislav Lukyanov : > > > Hi Igniters, > > > > There is a small but annoying issue with examples using MulticastIpFinder > > by default. > > The JIRA is IGNITE-6826. > > > > AntonK and DmitriiR have sugg

RE: Apache Flink Sink + Ignite: Ouch! Argument is invalid

Hi guys, Thanks for helping with the fix! As this is a development topic now and not a usage one, I’m BCC’ing the user-list and replacing it with dev-list. Please continue the discussion there. Andrey, Dmitry, please help with the review. Thanks, Stan From: Saikat Maitra Sent: 22 июля 2018 г.

RE: ConcurrentLinkedHashMap works incorrectly after clear()

It seems that we currently use the CLHM primarily as a FIFO cache. I see two ways around that. First, we could implement such LRU/FIFO cache based on another, properly supported data structure from j.u.c. ConcurrentSkipListMap seems OK. I have a draft implementation of LruEvictionPolicy based on

Deprecating LOCAL cache

Hi Igniters, I’d like to start a discussion about the deprecation of the LOCAL caches. LOCAL caches are an edge-case functionality I haven’t done any formal analysis, but from my experience LOCAL caches are needed very rarely, if ever. I think most usages of LOCAL caches I’ve seen were misuses:

RE: Deprecating LOCAL cache

ith a node filter forcefully set? That's similar to what we do with REPLICATED caches which are actually PARTITIONED with infinite number of backups. This way we fix the issues described by Stan and don't have to deprecate anything. -Val On Wed, Jul 25, 2018 at 12:53 AM Stanislav Lukyanov w

RE: Deprecating LOCAL cache

don't have to deprecate > anything. > > -Val > > On Wed, Jul 25, 2018 at 12:53 AM Stanislav Lukyanov < > stanlukya...@gmail.com> > wrote: > > > Hi Igniters, > > > > I’d like to start a discussion about the deprecation of the LOCAL caches. >

RE: Deprecating LOCAL cache

ITIONED with > > > infinite number of backups. > > > > > > This way we fix the issues described by Stan and don't have to > deprecate > > > anything. > > > > > > -Val > > > > > > On Wed, Jul 25, 2018 at 12:53 AM Stanislav

RE: Adding experimental support for Intel Optane DC Persistent Memory

Hi, The link you’ve shared gives me 404. Perhaps you need to add a permission for everyone to access the page? Thanks, Stan From: Mammo, Mulugeta Sent: 26 июля 2018 г. 2:44 To: dev@ignite.apache.org Subject: Adding experimental support for Intel Optane DC Persistent Memory Hi, I have added a n

RE: Adding experimental support for Intel Optane DC Persistent Memory

Ah, ok, it’s just the ‘.’ at the end of the link. Removed it and it’s fine. From: Stanislav Lukyanov Sent: 26 июля 2018 г. 15:12 To: dev@ignite.apache.org Subject: RE: Adding experimental support for Intel Optane DC Persistent Memory Hi, The link you’ve shared gives me 404. Perhaps you need to

RE: IP finder in tests

+1. I don’t see why do we need to fallback to multicast for multi-JVM – let’s just set 127.0.0.1:47500..47509 by default, it’ll be enough for most (if not all) tests. Stan From: Dmitriy Pavlov Sent: 1 августа 2018 г. 14:21 To: dev@ignite.apache.org Subject: Re: IP finder in tests Hi Denis, Th

Hello Ignite

those? Thanks, Stanislav Lukyanov

RE: Hello Ignite

AM, Stanislav Lukyanov > wrote: > > Hello Ignite Devs, > > My name is Stan and I want to contribute to the Apache Ignite project. > I’d like to start by fixing https://issues.apache.org/jira/browse/IGNITE-7217. > > I understand that I need additional JIRA access rights to a

Handling slashes in cache names

Hi all, I’m looking into https://issues.apache.org/jira/browse/IGNITE-7264, and I need some guidance on what’s the best way to approach it. The problem is that cache names are not restricted, but if persistence is enabled the cache needs to have a corresponding directory on the file system (“c

RE: Handling slashes in cache names

false feeling of some directory > structure, which does not exist. We should also prohibit spaces as well. > > D. > > On Mon, Dec 25, 2017 at 7:09 AM, Stanislav Lukyanov < > stanlukya...@gmail.com> > wrote: > > > Hi all, > > > > I’m looking into https:/

  1   2   >