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

va 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 Stanislav Lukyanov >> wrote:

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: 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: [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 >

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

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

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 beta distribut

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

l 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: 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

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

tioned. > 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 > 2.15? > > Kind regards, > Łukasz > > >

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.

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

t;> 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 >> this >>>> case? For example - tra

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

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 release notes in 2.15 a

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

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

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: [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

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:46 AM

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.

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: >>> >>>> +

Re: Exceeding the DataStorageConfiguration#getMaxWalArchiveSize due to historical rebalance

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 last idea. >>> What will we do if

Re: Exceeding the DataStorageConfiguration#getMaxWalArchiveSize due to historical rebalance

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, 20:00, "Stanislav Lukyanov&quo

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

Re: Exceeding the DataStorageConfiguration#getMaxWalArchiveSize due to historical rebalance

have 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 getMaxWalArch

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: IEP-70: Async Continuation Executor

, 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, >> >> Sorry for t

Re: IEP-70: Async Continuation Executor

ith 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:09 PM Stanislav Lukyanov >

[jira] [Created] (IGNITE-14507) Un-deprecate IGNITE_BINARY_SORT_OBJECT_FIELDS

Stanislav Lukyanov created IGNITE-14507: --- Summary: Un-deprecate IGNITE_BINARY_SORT_OBJECT_FIELDS Key: IGNITE-14507 URL: https://issues.apache.org/jira/browse/IGNITE-14507 Project: Ignite

Re: IEP-70: Async Continuation Executor

t; 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 some more. >> >> I agree that w

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 -

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

[jira] [Created] (IGNITE-13985) C++: Continuous Queries should fail to register if remote filter is in C++ and there are non-C++ affinity nodes

Stanislav Lukyanov created IGNITE-13985: --- Summary: C++: Continuous Queries should fail to register if remote filter is in C++ and there are non-C++ affinity nodes Key: IGNITE-13985 URL: https

[jira] [Created] (IGNITE-13975) Validate that tables beind joined have the same partition distribution

Stanislav Lukyanov created IGNITE-13975: --- Summary: Validate that tables beind joined have the same partition distribution Key: IGNITE-13975 URL: https://issues.apache.org/jira/browse/IGNITE-13975

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

[jira] [Created] (IGNITE-13777) idle_verify should report real size of the partitions

Stanislav Lukyanov created IGNITE-13777: --- Summary: idle_verify should report real size of the partitions Key: IGNITE-13777 URL: https://issues.apache.org/jira/browse/IGNITE-13777 Project: 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.

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 >

[jira] [Created] (IGNITE-13341) OOME is ignored if thrown in a client connector thread

Stanislav Lukyanov created IGNITE-13341: --- Summary: OOME is ignored if thrown in a client connector thread Key: IGNITE-13341 URL: https://issues.apache.org/jira/browse/IGNITE-13341 Project

[jira] [Created] (IGNITE-13340) copyOnRead=false doesn't work for byte array values

Stanislav Lukyanov created IGNITE-13340: --- Summary: copyOnRead=false doesn't work for byte array values Key: IGNITE-13340 URL: https://issues.apache.org/jira/browse/IGNITE-13340 Project: Ignite

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

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

Re: Extended logging for rebalance performance analysis

logyVersion [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 messages have a commo

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

Re: Extended logging for rebalance performance analysis

, 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. >> Looks good, but it fee

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?)

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

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

[jira] [Created] (IGNITE-11977) Data streamer pool MXBean is registered as ThreadPoolMXBean instead of StripedExecutorMXBean

Stanislav Lukyanov created IGNITE-11977: --- Summary: Data streamer pool MXBean is registered as ThreadPoolMXBean instead of StripedExecutorMXBean Key: IGNITE-11977 URL: https://issues.apache.org/jira/browse

[jira] [Created] (IGNITE-11976) @SpringResource is silently ignored if no Spring context is provided

Stanislav Lukyanov created IGNITE-11976: --- Summary: @SpringResource is silently ignored if no Spring context is provided Key: IGNITE-11976 URL: https://issues.apache.org/jira/browse/IGNITE-11976

[jira] [Created] (IGNITE-11968) FailureProcessor reports tcp-comm-worker as blocked when resolving communication errors in ZK

Stanislav Lukyanov created IGNITE-11968: --- Summary: FailureProcessor reports tcp-comm-worker as blocked when resolving communication errors in ZK Key: IGNITE-11968 URL: https://issues.apache.org/jira/browse

[jira] [Created] (IGNITE-11894) Add fetchSize to JDBC cache stores

Stanislav Lukyanov created IGNITE-11894: --- Summary: Add fetchSize to JDBC cache stores Key: IGNITE-11894 URL: https://issues.apache.org/jira/browse/IGNITE-11894 Project: Ignite Issue

[jira] [Created] (IGNITE-11836) keyFields must be empty if keyType is an SQL type

Stanislav Lukyanov created IGNITE-11836: --- Summary: keyFields must be empty if keyType is an SQL type Key: IGNITE-11836 URL: https://issues.apache.org/jira/browse/IGNITE-11836 Project: Ignite

[jira] [Created] (IGNITE-11829) Distribute joins fail if number of tables > 7

Stanislav Lukyanov created IGNITE-11829: --- Summary: Distribute joins fail if number of tables > 7 Key: IGNITE-11829 URL: https://issues.apache.org/jira/browse/IGNITE-11829 Project: Ign

[jira] [Created] (IGNITE-11533) Improve memory usage reporting in the logs

Stanislav Lukyanov created IGNITE-11533: --- Summary: Improve memory usage reporting in the logs Key: IGNITE-11533 URL: https://issues.apache.org/jira/browse/IGNITE-11533 Project: Ignite

[jira] [Created] (IGNITE-11471) JDBC: Thin driver should start with a random server to connect

Stanislav Lukyanov created IGNITE-11471: --- Summary: JDBC: Thin driver should start with a random server to connect Key: IGNITE-11471 URL: https://issues.apache.org/jira/browse/IGNITE-11471

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

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

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

[jira] [Created] (IGNITE-11365) Partition sizes differ after streaming with allowOverwrite=false with concurrent PME

Stanislav Lukyanov created IGNITE-11365: --- Summary: Partition sizes differ after streaming with allowOverwrite=false with concurrent PME Key: IGNITE-11365 URL: https://issues.apache.org/jira/browse/IGNITE

[jira] [Created] (IGNITE-11355) Mention CacheConfiguration.sqlIndexMaxInlineSize and QueryGroupIndex.inlineSize in inline size suggestions

Stanislav Lukyanov created IGNITE-11355: --- Summary: Mention CacheConfiguration.sqlIndexMaxInlineSize and QueryGroupIndex.inlineSize in inline size suggestions Key: IGNITE-11355 URL: https://issues.apache.org

[jira] [Created] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names

Stanislav Lukyanov created IGNITE-11312: --- Summary: JDBC: Thin driver doesn't reports incorrect property names Key: IGNITE-11312 URL: https://issues.apache.org/jira/browse/IGNITE-11312 Project

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: Starting with missing PDS pieces

ruk 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 talk

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

[jira] [Created] (IGNITE-11230) Fix Javadoc for DataStorageConfiguration

Stanislav Lukyanov created IGNITE-11230: --- Summary: Fix Javadoc for DataStorageConfiguration Key: IGNITE-11230 URL: https://issues.apache.org/jira/browse/IGNITE-11230 Project: Ignite

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

[jira] [Created] (IGNITE-11146) SQL: QueryIndex and DDL generate indexes with different default names

Stanislav Lukyanov created IGNITE-11146: --- Summary: SQL: QueryIndex and DDL generate indexes with different default names Key: IGNITE-11146 URL: https://issues.apache.org/jira/browse/IGNITE-11146

[jira] [Created] (IGNITE-11141) Add Java method to create a cache from a template

Stanislav Lukyanov created IGNITE-11141: --- Summary: Add Java method to create a cache from a template Key: IGNITE-11141 URL: https://issues.apache.org/jira/browse/IGNITE-11141 Project: Ignite

.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

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

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

ity 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 release.

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

[jira] [Created] (IGNITE-10983) Check that persistenceEnabled is consistent on all nodes

Stanislav Lukyanov created IGNITE-10983: --- Summary: Check that persistenceEnabled is consistent on all nodes Key: IGNITE-10983 URL: https://issues.apache.org/jira/browse/IGNITE-10983 Project

[jira] [Created] (IGNITE-10952) Document SET STREAMING command options

Stanislav Lukyanov created IGNITE-10952: --- Summary: Document SET STREAMING command options Key: IGNITE-10952 URL: https://issues.apache.org/jira/browse/IGNITE-10952 Project: Ignite

[jira] [Created] (IGNITE-10922) Add a way to override any configuration property via a system property

Stanislav Lukyanov created IGNITE-10922: --- Summary: Add a way to override any configuration property via a system property Key: IGNITE-10922 URL: https://issues.apache.org/jira/browse/IGNITE-10922

[jira] [Created] (IGNITE-10921) Add IGNITE_CONSISTENT_ID system property

Stanislav Lukyanov created IGNITE-10921: --- Summary: Add IGNITE_CONSISTENT_ID system property Key: IGNITE-10921 URL: https://issues.apache.org/jira/browse/IGNITE-10921 Project: Ignite

[jira] [Created] (IGNITE-10900) Print a warning if native persistence is used without an explicit consistent ID

Stanislav Lukyanov created IGNITE-10900: --- Summary: Print a warning if native persistence is used without an explicit consistent ID Key: IGNITE-10900 URL: https://issues.apache.org/jira/browse/IGNITE-10900

[jira] [Created] (IGNITE-10887) Docs: Align performance tips for .Net with Java

Stanislav Lukyanov created IGNITE-10887: --- Summary: Docs: Align performance tips for .Net with Java Key: IGNITE-10887 URL: https://issues.apache.org/jira/browse/IGNITE-10887 Project: Ignite

[jira] [Created] (IGNITE-10856) cassandra-store seems to be broken by incorrect guava version

Stanislav Lukyanov created IGNITE-10856: --- Summary: cassandra-store seems to be broken by incorrect guava version Key: IGNITE-10856 URL: https://issues.apache.org/jira/browse/IGNITE-10856

[jira] [Created] (IGNITE-10808) Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage

Stanislav Lukyanov created IGNITE-10808: --- Summary: Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage Key: IGNITE-10808 URL: https://issues.apache.org/jira/browse/IGNITE-10808

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: 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

RE: Volunteer needed: AWS Elastic Load Balancer IP Findersimplemented

: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 can

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: REST GridCacheCommandHandler writes ERROR in log in caseofbaduser input

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 I

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 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

RE: Volunteer needed: AWS Elastic Load Balancer IP Findersimplemented

pful 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.com>

Re: Pre-touch for Ignite off-heap memory

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. > > > > > > > > I gu

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

> - 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.apache.org

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

[jira] [Created] (IGNITE-10563) Allow manual fsync for WAL

Stanislav Lukyanov created IGNITE-10563: --- Summary: Allow manual fsync for WAL Key: IGNITE-10563 URL: https://issues.apache.org/jira/browse/IGNITE-10563 Project: Ignite Issue Type

[jira] [Created] (IGNITE-10516) Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables

Stanislav Lukyanov created IGNITE-10516: --- Summary: Storage is corrupted after CREATE INDEX IF NOT EXISTS on different tables Key: IGNITE-10516 URL: https://issues.apache.org/jira/browse/IGNITE-10516

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

[jira] [Created] (IGNITE-10506) Emphasize the need to close the query cursors in docs

Stanislav Lukyanov created IGNITE-10506: --- Summary: Emphasize the need to close the query cursors in docs Key: IGNITE-10506 URL: https://issues.apache.org/jira/browse/IGNITE-10506 Project: Ignite

[jira] [Created] (IGNITE-10225) Striped pool starvation check reports false-positive warnings if a job starts right before the check

Stanislav Lukyanov created IGNITE-10225: --- Summary: Striped pool starvation check reports false-positive warnings if a job starts right before the check Key: IGNITE-10225 URL: https://issues.apache.org/jira

[jira] [Created] (IGNITE-10223) Affinity methods should return List instead of Collection

Stanislav Lukyanov created IGNITE-10223: --- Summary: Affinity methods should return List instead of Collection Key: IGNITE-10223 URL: https://issues.apache.org/jira/browse/IGNITE-10223 Project

[jira] [Created] (IGNITE-10152) Allow warming up data region before a node has joined

Stanislav Lukyanov created IGNITE-10152: --- Summary: Allow warming up data region before a node has joined Key: IGNITE-10152 URL: https://issues.apache.org/jira/browse/IGNITE-10152 Project: Ignite

[jira] [Created] (IGNITE-10150) DisappearedCacheWasNotFoundMessageSelfTest fails with NPE

Stanislav Lukyanov created IGNITE-10150: --- Summary: DisappearedCacheWasNotFoundMessageSelfTest fails with NPE Key: IGNITE-10150 URL: https://issues.apache.org/jira/browse/IGNITE-10150 Project

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

  1   2   >