Alexei,
I agree that there should be no principal difficulty with the unique ID for
each cancellable object, but I also see Nikolay's point about the wrong
copy-paste.
I like minimalistic APIs, but in this case the price of a mistake may be
high. Let's let a wider circle of community members to s
Thanks for clarification.
Igniters, I will proceed with the release in the next few days if there is no
objections on it.
> 7 февр. 2020 г., в 10:57, Ivan Pavlukhin написал(а):
>
> Hi Nikolay,
>
> In fact I did not mean anything supernatural. A scheme you mentioned
>> I thought we just releas
Nikolay, Ivan,
Thank you guys! I knew that I should not worry =)
Best regards,
Ivan Pavlukhin
ср, 5 февр. 2020 г. в 13:46, Ivan Rakov :
>
> Ivan,
>
> Thanks for pointing this out. Less than one day is indeed too early to
> treat this discussion thread as a "community conclusion". Still, the
> co
Ok. Then we are at the beginning. To prevent unexpected data loss on
deactivation CLI and JMX should require 'force' flag. If there are no extra
proposals I'm going to finish the pull request.
чт, 6 февр. 2020 г. в 21:43, Alexei Scherbakov :
> Vladimir,
>
> IGNITE_REUSE_MEMORY_ON_DEACTIVATE doesn
> To prevent unexpected data loss on
deactivation CLI and JMX should require 'force' flag
Vladimir, please, go for it.
пт, 7 февр. 2020 г., 11:19 Vladimir Steshin :
> Ok. Then we are at the beginning. To prevent unexpected data loss on
> deactivation CLI and JMX should require 'force' flag. If
Hello, Vyacheslav.
> It seems to me we missed API that should be introduced into control utility.
Do you think we should support control.sh for cancel tasks?
> 7 февр. 2020 г., в 11:04, Alexey Goncharuk
> написал(а):
>
> Alexei,
>
> I agree that there should be no principal difficulty with
Hi igniters!
Feature, which I working on, requires to update the page
https://apacheignite-mix.readme.io/docs/spring-data#section-apache-ignite-repository
.
Because the feature provides additional way to link Spring repository with
particular cache.
I think It is required additional example of cod
Hi Sergey,
Please create a ticket for documentation update as described in this
section:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-Documentingaticket
-Artem
On 07.02.2020 12:00, Sergey Chernolyas wrote:
Hi igniters!
Feature, which I working on, re
Hello!
Please keep in mind that readme.io pages are suggest-editable. You can
submit documentation changes at any time.
Regards,
--
Ilya Kasnacheev
пт, 7 февр. 2020 г. в 12:01, Sergey Chernolyas :
> Hi igniters!
>
> Feature, which I working on, requires to update the page
>
> https://apacheig
Ivan Bessonov created IGNITE-12638:
--
Summary: Classes persisted by DistributedMetaStorage are not
IgniteDTO
Key: IGNITE-12638
URL: https://issues.apache.org/jira/browse/IGNITE-12638
Project: Ignite
Folks,
Do not read between lines please. I didn't suggest MVCC removal. I
asked, literally: is there any reason to have this code in the master?
branch?
Instead of listing reasons why we should support it I see posts like
remove it from branch.
Please, do not distort the meaning of the question.
> 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.
Maxim,
I believe that not all features requires x2 level of implementation
difficulty. Could you list
Not sure where we got the idea that MVCC code is useless in master.
Alexei,
I know that you used the MVCC partition counters implementation in order to
fix tx & atomic caches protocol issues. The MVCC WAL backpointer mechanics
can and should be used when we will move transaction records logging f
Hell, Alexey.
> We should work on processes to prevent such merges in the future, but not
> waste time reverting something that can be used for profit.
Can you, please, clarify, what real-world use-cases for the current
implementation of MVCC exists?
> 7 февр. 2020 г., в 13:07, Alexey Gonchar
Note that someone uses it
Main problem is a recovery process when persistence enabled and a cluster have
more than one node.
It is a problem even for regular transactional caches, the main difference -
MVCC detects any inconsistencies while regular transactional caches may ignore
it without a
Nikolay,
Recently I noticed some changes in SQL indexes view content introduced
in [1]. Among changes I noticed:
1. Columns related to a cache group information disappeared.
2. "proxy" indexes info is now displayed in the view.
Was this changes made intentionally? Historically there were followin
Hello, Ivan.
Please, clarify what columns are missed?
Do you file a ticket to introduce those fields?
> 7 февр. 2020 г., в 13:26, Ivan Pavlukhin написал(а):
>
> Nikolay,
>
> Recently I noticed some changes in SQL indexes view content introduced
> in [1]. Among changes I noticed:
> 1. Columns r
> 1. Columns related to a cache group information disappeared.
Information about cache group can be gathered from SYS.CACHES and
SYS.CACHE_GROUPS.
> 2. "proxy" indexes info is now displayed in the view.
Yes, this was made intentionally.
I think we shouldn’t hide internal details from the user i
Nikolay,
I have not filed any ticket yet. I would like to discuss first.
> Yes, this was made intentionally.
> I think we shouldn’t hide internal details from the user in the system views.
Regarding proxy indices Cannot immediately agree here. My
understanding is that the view in question should
Hi Nikolay,
Yes, I think we should add this API to the control utility as well.
IMHO, the control utility is a more natural way of administration/control
of the cluster instead of JMX, for example.
Thanks,
S.
пт, 7 февр. 2020 г. в 11:38, Nikolay Izhikov :
> Hello, Vyacheslav.
>
> > It seems to
My humble opinion.
We need MVCC because it is our way to SQL transactions. SQL is a very
important user API (as you might know there is an active work on new
SQL engine). Fair SQL transactions is a supplementary and quite needed
feature, users ask about it on user list. I believe it is a future of
> IMHO, the control utility is a more natural way of administration/control
of the cluster instead of JMX, for example.
It’s questionable.
I don’t mind to improve control.sh in this IEP.
But, we should discuss to topic - what management utilities we are providing
*AND* supporting and how the sh
Ivan.
My understanding of system views reflected in IEP-35:
With the system views we should answer to the user question - «What objects are
existing in my node?»
> From a (unit) test I cannot figure out how a proxy index is different from an
> underlying one from a user perspective.
> Could
Igor Seliverstov created IGNITE-12639:
-
Summary: Calcite integration. DML support.
Key: IGNITE-12639
URL: https://issues.apache.org/jira/browse/IGNITE-12639
Project: Ignite
Issue Type: Ne
My point is MVCC should be redone from scratch without messing with other
pars of code.
Currently it's spaghetti unmaintanable code.
пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin :
> My humble opinion.
>
> We need MVCC because it is our way to SQL transactions. SQL is a very
> important user API (
I absolutely agree with Alexey that MVCC architecture should be
completely reviewed. Current implementation is uncompetitive with other
solutions. It is slow by design. Here are some my points:
- we use central coordinator for transactions ordering. This is very
similar to what Calvin [1] systems d
Ryabov Dmitrii created IGNITE-12640:
---
Summary: Update readme's advanced security page
Key: IGNITE-12640
URL: https://issues.apache.org/jira/browse/IGNITE-12640
Project: Ignite
Issue Type: T
Nikolay Izhikov created IGNITE-12641:
Summary: IgniteSequenceInternalCleanupTest flacky after
IGNITE-12598
Key: IGNITE-12641
URL: https://issues.apache.org/jira/browse/IGNITE-12641
Project: Ignite
Hi Nikolay, Ivan, Denis
I think we can release for spring boot autoconfigure module.
I will also go ahead and make release for flink ext.
I have pending PR for flume and zeromq, if I can get review and approval I
can go ahead and merge and release these modules as well.
Regards
Saikat
On Fri,
Folks, have we agreed on the release process? Saikat, could you point all
of us to a related discussion. If my memory doesn't fail me Alex Goncharuk
also wanted to step in before we do the first release.
-
Denis
On Fri, Feb 7, 2020 at 8:02 AM Saikat Maitra
wrote:
> Hi Nikolay, Ivan, Denis
>
>
Some more thoughts.
I think we can try out a first release and decide if everything is ok
along the way. I suppose that we should run tests with supported
Ignite versions (perhaps not all) and provide results. And finally
there will be a release vote.
Best regards,
Ivan Pavlukhin
пт, 7 февр. 202
Folks,
Do we have a consensus so far that MVCC should be annotated with
@IgniteExperimental? Are there any objections?
Best regards,
Ivan Pavlukhin
пт, 7 февр. 2020 г. в 15:58, Roman Kondakov :
>
> I absolutely agree with Alexey that MVCC architecture should be
> completely reviewed. Current imp
Hi Denis,
As discussed with Alexey I have captured the discussion details in
confluence wiki page. I have not received any concerns or follow up
questions on the release process. I can certainly pause and continue to
work on current migration of existing modules if more time required for the
revie
33 matches
Mail list logo
