Hi Nikolay,
In fact I did not mean anything supernatural. A scheme you mentioned
> I thought we just release module with the 1.0.0 version and specify supported
> Ignite version somewhere in the documentation.
sounds fine to me.
Best regards,
Ivan Pavlukhin
чт, 6 февр. 2020 г. в 15:00, Nikolay
Vladimir,
IGNITE_REUSE_MEMORY_ON_DEACTIVATE doesn't prevent cache contents from
clearing.
It allows allocated memory reuse on re-activation to avoid OS specific
issues if allocated heap is rather large.
You are right to create separate ticket for implementing required behavior.
чт, 6 февр. 2020
Nick
I see no difficulty in assinging each cancellable object an IgniteUuid
(which is actually java UUID and is guaranteed to be unique per node).
We can have registry of running queries and just poking to what registry is
enough to understand query type.
чт, 6 февр. 2020 г. в 17:17, Вячеслав Коп
I'm strongly support removal of MVCC from master.
At the current state it bloats code base and should be reworked from
scratch using separate code base.
чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev :
> Hello!
>
> Please keep in mind that you need to create a separate proposal voting
> thread if
Hi, Maxim.
I had not a chance to start working on it.
GG-17396 is about bitset implementation approach for out-of-order updates.
Doesn't seem high priority for me right now.
чт, 6 февр. 2020 г. в 20:24, Maxim Muzafarov :
> Hello, Alexei,
>
>
> Do we have any updates on this issue [1] with replac
Hello, Alexei,
Do we have any updates on this issue [1] with replacing GG-X TODOs
by Ignite analogues?
Can you at least share an information about this issue - GG-17396? Is
it still actual? Mentioned here [2].
[1] https://issues.apache.org/jira/browse/IGNITE-12422
[2]
https://github.com/ap
Ivan, thanks, I agree, added this clause:
The vote we are going to have is reduced to two choices so far:
* Never deprecate the old APIs unless the new APIs are stable and released
without @IgniteExperimental. The old APIs javadoc may be updated with a
reference to new APIs to encourage users to
Hello!
Please keep in mind that you need to create a separate proposal voting
thread if you really like it to count. I wonder if Dmitry Pavlov can help
us with the procedure.
Otherwise, I think it makes total sense to restrict MVCC clusters to only
have MVCC caches or REPLICATED TRANSACTIONAL cac
Andrey Aleksandrov created IGNITE-12637:
---
Summary: IgniteSparkSession doesn't start the clients on really
distributed cluster
Key: IGNITE-12637
URL: https://issues.apache.org/jira/browse/IGNITE-12637
Ilya,
1. MVCC support requires code maintenance for other developed features
even if has not used and disabled. Currently, we've got an x2 level of
difficulty for implementation of new features.
2. It would be much easy to develop and support clusters with
mvcc-caches only rather than have a mix
Hello!
Why would we drop MVCC!?
I can totally imagine a scenario where a large Ignite user surfaces with
fixes for MVCC mode, if it is kept as an experimental feature. Then maybe
it will graduate to beta some time in future.
If it does too much strain on the TC, let's discuss that, but I don't
r
Hello!
How about we introduce a *developer warning* about this inconsistency, see
what happens in a release with this warning, and then maybe eventually turn
it into error?
Please note that plain error will be breaking existing code which should
make it blocker for minor releases.
Regards,
--
I
Mirza Aliev created IGNITE-12636:
Summary: Full rebalance instead of historical one
Key: IGNITE-12636
URL: https://issues.apache.org/jira/browse/IGNITE-12636
Project: Ignite
Issue Type: Bug
A little bit more formalism. The thread subject is about API
deprecation in general. But it looks like that discussion boils down
to a replacement of old API with a new one. I suppose there should be
a possibility to deprecate API for removal if the Community decided to
do so.
> @IgniteExperimenta
Hello,
It seems to me we missed API that should be introduced into control utility.
Nikolay, could you please note this requirement on the IEP page?
Thanks,
S.
чт, 6 февр. 2020 г. в 15:29, Nikolay Izhikov :
> Ticket [1] created.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12632
>
> > 5
Or, is flag [1] is actual only for persistence mode? Related ticket [2] is
completely about disabled persistence.
If previous assumption is right, I think, we can involve flag [1] in ticket
[2].
[1]
org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
[2] https://issues.apach
Yury Gerzhedovich created IGNITE-12635:
--
Summary: Reservation WALRecord for compatibility purposes
Key: IGNITE-12635
URL: https://issues.apache.org/jira/browse/IGNITE-12635
Project: Ignite
Denis, Alexei,
Regarding usage of flag
org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
[1]
When enabled, I think the following test should work. But it fails.
//
@Test
public void testDataPresent()
Pavel Tupitsyn created IGNITE-12634:
---
Summary: .NET: Publish symbol packages
Key: IGNITE-12634
URL: https://issues.apache.org/jira/browse/IGNITE-12634
Project: Ignite
Issue Type: Bug
Ticket [1] created.
[1] https://issues.apache.org/jira/browse/IGNITE-12632
> 5 февр. 2020 г., в 15:36, Nikolay Izhikov написал(а):
>
> Alexey.
>
> I’m talking the following scenario:
>
> 1. Consider we have unified bean to kill tasks:
>
> CancelMXBean {
> public void cancel(long id);
> By the way, is there any reason to have this code in the master branch
I support removal MVCC from master.
> 6 февр. 2020 г., в 15:26, Andrey Gura написал(а):
>
> +1
>
> By the way, is there any reason to have this code in the master
> branch? It seems feature is in unsupportable state and
+1
By the way, is there any reason to have this code in the master
branch? It seems feature is in unsupportable state and just wastes TC
time and our effort to support MVCC related tests.
On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
wrote:
>
> Agree, let's mark MVCC experimental.
>
> Stephen,
> ...
> So I think that we can't mix these two approaches.
Sounds reasonable. Thanks for clarification.
> Also, it's not clear for me -- are there any reasons to continue support
> of the ServiceLoader approach, given the fact that configurations needed
> for a plugin, in this case, are also spec
Igor Seliverstov created IGNITE-12633:
-
Summary: Calcite integration. Query cancel purpose.
Key: IGNITE-12633
URL: https://issues.apache.org/jira/browse/IGNITE-12633
Project: Ignite
Issue
Hi Artsiom,
Welcome to Apache Ignite Community!
I added a contributor role to your Jira account. Now you can assign
tickets to yourself. Do not hesitate to ask if you need any
assistance.
Please check this page out for commonly asked questions pertaining to
the contribution process:
https://igni
Nikolay Izhikov created IGNITE-12632:
Summary: [IEP-39] Management API to cancel user provided tasks and
queries.
Key: IGNITE-12632
URL: https://issues.apache.org/jira/browse/IGNITE-12632
Project:
Hello, Ivan.
> As usual we need to decide about versioning and a correspondence to Ignite
> versions
> As we are going to have a separate release cycle I can imagine an independent
> versioning scheme with a range of supported Ignite versions.
Please, clarify, what do you mean?
Do you have any
Thanks, updated the justification:
The vote we are going to have is reduced to two choices so far:
* Never deprecate the old APIs unless the new APIs are stable and released
without @IgniteExperimental. The old APIs javadoc may be updated with a
reference to new APIs to encourage users to evaluat
Agree, let's mark MVCC experimental.
Stephen, the annotation serves as an additional documentation-style marker.
For now there are no compile-time warnings when the API is used.
чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
stephen.darling...@gridgain.com>:
> Yes! I’ve already seen people tr
Hello,
I think the right answer is YES. It should be marked with the new
annotation @IgniteExperimental.
Thanks,
S.
чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
stephen.darling...@gridgain.com>:
> Yes! I’ve already seen people try to use this without awareness that it’s
> not production re
Nikolay,
This sounds like a philosophical question :)
By rigid I mean inability to change some properties without whole cluster
restart, and I do think it's bad. I have a good example in mind - the
number of threads running rebalance. Originally, we added a validation
check for this configuration
Yes! I’ve already seen people try to use this without awareness that it’s not
production ready.
What happens with the annotation, incidentally? Is it just in the documentation
or do you get a compile-time warning?
> On 6 Feb 2020, at 11:32, Nikolay Izhikov wrote:
>
> Hello, Igniters.
>
> Sho
Hello, Igniters.
Should we mark MVCC feature with the new @IgniteExperimental?
We explicitly note users that MVCC has beta status, for now [1]
> Beta version of Transactional SQL and MVCC
> In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to
> allow users to experiment a
>> most users do not want to lose data by default.
But some ready to sacrifice.
I know at least one case when "pure speed without insurance" required when
the ML model is studying.
On Thu, Feb 6, 2020 at 1:39 PM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> I'm quite sure most users
I'm quite sure most users do not want to lose data by default.
It's not wise to recommend such thing even with explicit warning.
чт, 6 февр. 2020 г. в 13:30, Anton Vinogradov :
> The statement seems to be correct for cases when we'd like to perform fast
> loading and computation and not afraid o
Hello!
I want to be a new community member so I ask you to give me contributors
permissions
https://issues.apache.org/jira/secure/ViewProfile.jspa?name=artsiom_panko
Hello,
I have two notes
> * Allow to deprecate the old APIs even when new APIs are marked with
> @IgniteExperimental to explicitly notify users that the new APIs are available
I think the main reason is not «notify users that new APIs are available», but
«Notify users that old APIs will be rem
Agree, I was implying this option. Corrected:
The vote we are going to have is reduced to two choices so far:
* Never deprecate the old APIs unless the new APIs are stable and released
without @IgniteExperimental. The old APIs javadoc may be updated with a
reference to new APIs to encourage users
The statement seems to be correct for cases when we'd like to perform fast
loading and computation and not afraid of data loss.
Performance boost always means we lose some guarantee.
Let's just update the proposal with the explicit warning that reducing
backups to zero may lead to data loss on any
The discussion thread is started:
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Public-API-deprecation-rules-td45647.html
ср, 5 февр. 2020 г. в 12:43, Alexey Goncharuk :
> Sorry for the rush, I think I got it - it's right in the voting process
> [1]. This would be a vote on a proc
One comment about first choice.
The formulation has one issue from my point of view: Never deprecate
the old APIs unless the new APIs are stable *and released* without
@IgniteExperimental.
Actually we can introduce new stable API and deprecate old API at the
same time without releasing of new API
Definitely wrong recommendation.
Please file a ticket for removal.
чт, 6 февр. 2020 г. в 12:26, Zhenya Stanilovsky :
>
> Igniters, i found that suggesting zero backup for performance improvements
> sounds like malicious and further problems suggestion. May be it`s time to
> remove it ?
>
> Exampl
Hello, Alexey.
Sorry, my question is not related to the current discussion
> this makes the cluster configuration rigid;
Is it a bad thing to make cluster node configuration rigid?
> 6 февр. 2020 г., в 12:20, Alexey Goncharuk
> написал(а):
>
> Vladimir,
>
> In current implementation the fl
Igniters, i found that suggesting zero backup for performance improvements
sounds like malicious and further problems suggestion. May be it`s time to
remove it ?
Example:
[07:59:27] Performance suggestions for grid (fix if possible)
[07:59:27] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_D
Vladimir,
In current implementation the flag does not change if data is kept or
cleared from memory - after deactivation the internal structures are
cleared and only data region is kept allocated. If you add a validation for
this flag, you forbid users to do a rolling cluster restart and
enable/di
Looks good to me.
On Thu, Feb 6, 2020 at 11:45 AM Ivan Pavlukhin wrote:
> Igniters,
>
> I raised a PR for a ticket [1] removing section from
> parent pom.xml. I described the motivation in the ticket. Shortly,
> this section has a little meaning today and even worse is misleading.
>
> Please re
Igniters,
I raised a PR for a ticket [1] removing section from
parent pom.xml. I described the motivation in the ticket. Shortly,
this section has a little meaning today and even worse is misleading.
Please review.
[1] https://issues.apache.org/jira/browse/IGNITE-12630
Best regards,
Ivan Pavlu
Anton Kalashnikov created IGNITE-12631:
--
Summary: Incorrect rewriting wal record type in marshalled mode
during iteration
Key: IGNITE-12631
URL: https://issues.apache.org/jira/browse/IGNITE-12631
Ivan Pavlukhin created IGNITE-12630:
---
Summary: Remove developers sections from parent pom.xml
Key: IGNITE-12630
URL: https://issues.apache.org/jira/browse/IGNITE-12630
Project: Ignite
Issue
Nikolay,
Thank you for driving it! It is great to establish this process in
practice earlier because it seems that we need to release a Flink
integration soon because Ignite 2.8 is going to be released without
that integration bundled.
As usual we need to decide about versioning and a corresponde
50 matches
Mail list logo
