Hi, Denis.
> - How is the performance stats ext is different from the profiling tool
> released in 2.10?
The performance statistics extension is a script to build an HTML
report. The core module collects statistics to binary files and this
feature was released in 2.10.
чт, 25 мар. 2021 г. в
Andrey,
Can you compile a full list of these risky methods, and elaborate on what
the risks are?
Generally, CompletableFuture is a much better option, because it's
standard. But we need to make sure it actually fits our needs and doesn't
do more harm than good.
-Val
On Thu, Mar 25, 2021 at
Hi Community,
First off, I want to thank the community for being so welcoming and
helpful. This is an awesome place to be in.
Now that I have worked on some issues, I would like to get my hands deeper
and with larger issues in the core. Also, some more intermediate tickets to
tackle, my queue
I think both options are fine, but personally lean toward CompletableFuture.
чт, 25 мар. 2021 г. в 17:56, Atri Sharma :
> I would suggest using CompletableFuture -- I don't see a need for a custom
> interface that is unique to us.
>
> It also allows a lower barrier for new contributors for
Alexei,
> we already have ways to control a listener's behavior
No, we don't have a way to fix current broken and dangerous behavior
globally.
You should not expect the user to fix every async call manually.
> commonPool can alter existing deployments in unpredictable ways,
> if commonPool is
> I don't agree that the code isn't related to Ignite - it is something
that the user does via Ignite API
This is a misconception. When you write general-purpose async code, it
looks like this:
myClass.fooAsync()
.chain(igniteCache.putAsync)
.chain(myClass.barAsync)
.chain(...)
And so on, you
Aaron Anderson created IGNITE-14420:
---
Summary: Support pluggable dependency injection frameworks
Key: IGNITE-14420
URL: https://issues.apache.org/jira/browse/IGNITE-14420
Project: Ignite
+1
I missed our progress on the extensions frontier. Great to see more
capabilities added to the Spring framework support.
Several questions (but, I fully support the release of the extensions):
- How is the performance stats ext is different from the profiling tool
released in 2.10?
-
Vladislav Pyatkov created IGNITE-14419:
--
Summary: SPI suite hangs sporadically on private TC
Key: IGNITE-14419
URL: https://issues.apache.org/jira/browse/IGNITE-14419
Project: Ignite
Hello Nikita,
+1 to follow your suggestion.
Please let me know if you need any help.
I also think the issues mentioned by you can be done in parallel and
they don't block the release :-)
On Thu, 25 Mar 2021 at 17:26, Nikita Amelchev wrote:
>
> Igniters,
>
> Since Ignite 2.10 has been released,
Ivan Daschinskiy created IGNITE-14418:
-
Summary: Document asyncio version of python ignite thin client
Key: IGNITE-14418
URL: https://issues.apache.org/jira/browse/IGNITE-14418
Project: Ignite
I would suggest using CompletableFuture -- I don't see a need for a custom
interface that is unique to us.
It also allows a lower barrier for new contributors for understanding
existing code
On Thu, 25 Mar 2021, 20:18 Andrey Mashenkov,
wrote:
> Hi Igniters,
>
> I'd like to start a discussion
Kirill,
Indeed current behavior of force rebuild API seems broken, we need to fix
it, +1 from me too.
BTW would it be useful to allow rebuilding individual indices?
On Wed, Mar 24, 2021 at 6:20 PM ткаленко кирилл
wrote:
> Hello!
>
> What do you mean by the implementation plan?
> Implement
Hi Igniters,
I'd like to start a discussion about replacing our custom IgniteFuture
class with CompletableFuture - existed JDK class
or rework it's implementation (like some other products done) to a
composition of CompletionStage and Future interfaces.
or maybe other option if you have any
Igniters,
Since Ignite 2.10 has been released, I think we can now release new
extension modules:
performance-statistics-ext
spring-data-ext
spring-tx-ext
I want to be a release manager for these if nobody minds.
The release process can be started after resolving a few documentation issues:
Amelchev Nikita created IGNITE-14417:
Summary: Document performance-statistics-ext module
Key: IGNITE-14417
URL: https://issues.apache.org/jira/browse/IGNITE-14417
Project: Ignite
Issue
Andrey,
> * Ignite shouldn't start if existed persistence has the MVCC index (cache)
> and maybe other internal persistent MVCC structures.
> * Even if the user dropped all MVCC indices/caches before the upgrade,
> probably there can be an incomplete checkpoint and there are WAL records
>
Vyacheslav Koptilin created IGNITE-14416:
Summary: Cluster initialization via ignite-ctl tool
Key: IGNITE-14416
URL: https://issues.apache.org/jira/browse/IGNITE-14416
Project: Ignite
Vyacheslav Koptilin created IGNITE-14415:
Summary: Define protocol of creating distributed metastorage group
Key: IGNITE-14415
URL: https://issues.apache.org/jira/browse/IGNITE-14415
Project:
Vyacheslav Koptilin created IGNITE-14414:
Summary: Cluster initialization flow
Key: IGNITE-14414
URL: https://issues.apache.org/jira/browse/IGNITE-14414
Project: Ignite
Issue Type:
Vyacheslav Koptilin created IGNITE-14413:
Summary: Start of Ignite node should be supported by ignite-ctl
tool
Key: IGNITE-14413
URL: https://issues.apache.org/jira/browse/IGNITE-14413
Vyacheslav Koptilin created IGNITE-14412:
Summary: Interaction between component, dms watch and vault
Key: IGNITE-14412
URL: https://issues.apache.org/jira/browse/IGNITE-14412
Project: Ignite
Vyacheslav Koptilin created IGNITE-14411:
Summary: Define minimal set of cluster components and their
lifecycle
Key: IGNITE-14411
URL: https://issues.apache.org/jira/browse/IGNITE-14411
Vyacheslav Koptilin created IGNITE-14410:
Summary: Node components startup
Key: IGNITE-14410
URL: https://issues.apache.org/jira/browse/IGNITE-14410
Project: Ignite
Issue Type: New
Vyacheslav Koptilin created IGNITE-14409:
Summary: Vault based on Ignite-3 PDS
Key: IGNITE-14409
URL: https://issues.apache.org/jira/browse/IGNITE-14409
Project: Ignite
Issue Type:
Vyacheslav Koptilin created IGNITE-14408:
Summary: Vault based on custom persistent storage
Key: IGNITE-14408
URL: https://issues.apache.org/jira/browse/IGNITE-14408
Project: Ignite
Vyacheslav Koptilin created IGNITE-14407:
Summary: In-memory implementation of Vault
Key: IGNITE-14407
URL: https://issues.apache.org/jira/browse/IGNITE-14407
Project: Ignite
Issue
Vyacheslav Koptilin created IGNITE-14406:
Summary: Define interface for Vault
Key: IGNITE-14406
URL: https://issues.apache.org/jira/browse/IGNITE-14406
Project: Ignite
Issue Type:
Vyacheslav Koptilin created IGNITE-14405:
Summary: Local persistent key-value storage (Vault)
Key: IGNITE-14405
URL: https://issues.apache.org/jira/browse/IGNITE-14405
Project: Ignite
Folks,
I see no reason to postpone this patch. I think we can proceed with
this patch with the commitment to remove MVCC from the public API
until the next release (2.11). These changes for sure must be
well-documented but for the 2.10 release, we already have in the
release notes [1] warnings
I've moved indexes from the indexing module to the core module, but I did
not move H2Mvcc*IO classes that are responsible for storing MVCC data in
indexes. Also for other indexes code I've skipped some blocks with
if-condition that checks if cache is MVCC or not.
Actually, there isn't so much
Pavel,
The change still looks a bit risky to me, because the default executor is
set to commonPool and can alter existing deployments in unpredictable ways,
if commonPool is heavily used for other purposes.
Runnable::run usage is not obvious as well and should be properly
documented as a way to
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
Alexei,
> Sometimes it's more desirable to execute the listener in the same thread
> It's up to the user to decide.
Yes, we give users a choice to configure the executor as Runnable::run and
use the same thread if needed.
However, it should not be the default behavior as explained above (bad
Nikita Safonov created IGNITE-14404:
---
Summary: Highlight that Ignite supports only Java 8 and 11
Key: IGNITE-14404
URL: https://issues.apache.org/jira/browse/IGNITE-14404
Project: Ignite
Andrey N. Gura created IGNITE-14403:
---
Summary: Create ignite-core module for Ignite 3
Key: IGNITE-14403
URL: https://issues.apache.org/jira/browse/IGNITE-14403
Project: Ignite
Issue Type:
Maksim,
It seems to me from the description "Patch completely breaks MVCC" the
proposed patch should be postponed until at least the public API for
MVCC will be removed.
Or can you clarify the impact of the patch ? Does the existing MVCC
functionality will remain unbroken ?
чт, 25 мар. 2021 г.
Pavel,
While I understand the issue and overall agree with you, I'm against the
execution of listeners in separate thread pool by default.
Sometimes it's more desirable to execute the listener in the same thread,
for example if it's some lightweight closure.
It's up to the user to decide.
I
Hi Maksim,
Do you mean MVCC will not work at all or MVCC will not support indices
after your changes?
Anyway, this looks like a major change and may be too harmful for the minor
version (10.1).
Before break MVCC index (or MVCC mode) we should force the user first to
drop all MVCC indices (or
Stan,
We have thread pools dedicated for specific purposes, like cache (striped),
compute (pub), query, etc
As I understand it, the reason here is to limit the number of threads
dedicated to a given subsystem.
For example, Compute may be overloaded with work, but Cache and Discovery
will keep
Pavel,
This is a great work, fully agree with the overall idea and approach.
However, I have some reservations about the API. We sure do have a lot of async
stuff in the system, and I would suggest to stick to the usual design - create
a separate thread pool, add a single property to control
Hi, Igniters!
the MVCC feature marked as IgniteExperimental and this annotation is more
weaker than deprecated. So we can remove this functionality in any moment.
So I propose:
1. Now I leave all affected tests marked as ignored.
2. Create a ticket for removing TRANSACTIONAL_SNAPSHOT from
Pavel Tupitsyn created IGNITE-14402:
---
Summary: Java Thin: Continuous Query
Key: IGNITE-14402
URL: https://issues.apache.org/jira/browse/IGNITE-14402
Project: Ignite
Issue Type: New Feature
Alessandro Pezze' created IGNITE-14401:
--
Summary: string setCipherSuites don't specify format
Key: IGNITE-14401
URL: https://issues.apache.org/jira/browse/IGNITE-14401
Project: Ignite
Alessandro Pezze' created IGNITE-14400:
--
Summary: string setCipherSuites don't specify format
Key: IGNITE-14400
URL: https://issues.apache.org/jira/browse/IGNITE-14400
Project: Ignite
Mikhail Petrov created IGNITE-14399:
---
Summary: Document thin client support for spring-cache integration.
Key: IGNITE-14399
URL: https://issues.apache.org/jira/browse/IGNITE-14399
Project: Ignite
Mikhail Petrov created IGNITE-14398:
---
Summary: Document thin client support for spring-data integration.
Key: IGNITE-14398
URL: https://issues.apache.org/jira/browse/IGNITE-14398
Project: Ignite
Mikhail Petrov created IGNITE-14397:
---
Summary: Document spring-transactions integration.
Key: IGNITE-14397
URL: https://issues.apache.org/jira/browse/IGNITE-14397
Project: Ignite
Issue
Sergei Ryzhov created IGNITE-14396:
--
Summary: Сrash of snapshot test on ducktape
Key: IGNITE-14396
URL: https://issues.apache.org/jira/browse/IGNITE-14396
Project: Ignite
Issue Type: Test
Dmitriy Sorokin created IGNITE-14395:
Summary: Shorter test results directory name
Key: IGNITE-14395
URL: https://issues.apache.org/jira/browse/IGNITE-14395
Project: Ignite
Issue Type:
50 matches
Mail list logo
