I just checked the ignite doc for atomic configuration.
But it doesn't say that it is applicable to distributed data structures.
Is it really applicable to distributed data structures like count down latch
On Tue 9 Jun, 2020, 7:26 AM Prasad Bhalerao Hi,
> I was under the impression that
Roman,
Please check the following methods:
* CacheContiniousQueryHandler (the filter usage):
https://github.com/apache/ignite/blob/6955ac291352dd67c1f84a006cda512ee54f38bb/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryHandler.java#L994
Vladimir Steshin created IGNITE-13134:
-
Summary: Fix connection recovery timout.
Key: IGNITE-13134
URL: https://issues.apache.org/jira/browse/IGNITE-13134
Project: Ignite
Issue Type:
Moldachev Sergey created IGNITE-13133:
-
Summary: Add integration with QuerydslPredicateExecutor for
spring-data integrations
Key: IGNITE-13133
URL: https://issues.apache.org/jira/browse/IGNITE-13133
Vlad, thanks for starting this discussion.
I'll try to clarify the motivation for this change as I see it.
In general, Ignite clusters are vulnerable to the data loss. Of course, we
have configurable PartitionLossPolicy, which allows to handle data loss
safely and mitigate its consequences. But
Hello!
I have added you to contributors, You should now be able to assign that
issue to yourself.
Regards,
--
Ilya Kasnacheev
пн, 8 июн. 2020 г. в 18:43, Aleksey Kurinov :
> Hey, just wanted to add to my previous email
>
> could you please assign
>
Hi
We need to have ability to calling shutdown with various guaranties.
For example:
Need to reboot a node, but after that node should be available for
historical rebalance (all partitions in MOVING state should have gone to
OWNING).
Implemented a circled reboot of cluster, but all data should
Hi
We need to have ability to calling shutdown with various guaranties.
For example:
Need to reboot a node, but after that node should be available for
historical rebalance (all partitions in MOVING state should have gone to
OWNING).
Implemented a circled reboot of cluster, but all data should
Hi
We need to have ability to calling shutdown with various guaranties.
For example:
Need to reboot a node, but after that node should be available for
historical rebalance (all partitions in MOVING state should have gone to
OWNING).
Implemented a circled reboot of cluster, but all data should
Hi
We need to have ability to calling shutdown with various guaranties.
For example:
Need to reboot a node, but after that node should be available for
historical rebalance (all partitions in MOVING state should have gone to
OWNING).
Implemented a circled reboot of cluster, but all data should
Hey, just wanted to add to my previous email
could you please assign
https://issues.apache.org/jira/browse/IGNITE-13040 task
to me or advise some another task for beginners
i can work with SQL, Spring related tasks
-- Forwarded message -
From: Aleksey Kurinov
Date: Mon, Jun 8,
Hello
I'm Aleksei Kurinov,
Software Developer from Epam Systems company.
I'd like to contribute to the Ignite project.
I'm a java developer but never contributed to open source projects.
I'd like to familiar with the process so for starting I'd prefer to work on
some trivial task for beginners
my
Andrey,
I see the following options for PR checks (without intention to merge it):
1. Disable the checkstyle plugin in pom.xml or remove all rules from
checkstyle.xml (for PR branch).
2.
- import checkstyle.xml cofiguration to IntilliJ IDEA inspections
(Preferences > Editor > Inspections)
- be
Andrey,
I see the following options for PR checks (without intention to merge it):
1.
On Mon, 8 Jun 2020 at 17:59, Andrey Mashenkov
wrote:
>
> HI,
>
> > Why do you want to run a reproducer from the user list on the TC?
> It may be useful to verify a race that can't be reproduced locally on my
HI,
> Why do you want to run a reproducer from the user list on the TC?
It may be useful to verify a race that can't be reproduced locally on my NB
due to some performance reasons.
> If all code style rules are good then we should use them in daily coding,
isn’t it?
Yes, also we do not force
Igniters, I suppose, that existence of manual pinger, introduced in [1], in
our ZkDiscoveryImpl is under a big question. This weird thing was
introduced to solve specific issue, specifically strange freeze of all
threads of process during deallocate (Unsafe.freeMemory) of large amount of
data.
Hello, Andrey.
Sorry, I still don’t understand your use-case.
Can you, please, use correct quoting so I can parse your message? :)
Why do you want to run a reproducer from the user list on the TC?
> There is no specific rule.
If all code style rules are good then we should use them in daily
Hi Niolay,
Why do you ignore code style rules while developing «quick reproducer»?
I don't think it worth effor to fix a user code (e.g. from userlist) just
to validate some race condition.
There is no specific rule.
I'm sad we have no ability to run user code without using any hacks to skip
Hello, Andrey.
> I've just found that I should waste my time fixing styles in user code that
> (may be) reproduce some bug, just to validate the bug or fix provided by the
> user.
Why do you ignore code style rules while developing «quick reproducer»?
What specific code style rule is an issue
Konstantin,
+1
I've just found that I should waste my time fixing styles in user code that
(may be) reproduce some bug, just to validate the bug or fix provided by
the user.
I'm ok with the idea to block commits with style errors to master branch,
but not for other branches\PR.
Can anybody
> I see no relation between possible data loss on shutdown and waiting for
> some jobs to complete.
Yes, I do not think that is.
More over that I want to union waiting of jobs and waiting rebalance in one
shutdown policy. Rather, these various shutdown types mean various types of
waiting.
Hi Igniters.
I've recently submitted patch[1] that implemented subj.
Any help with review would be appreciated.
[1] - https://issues.apache.org/jira/browse/IGNITE-12808
--
Sincerely yours, Ivan Daschinskiy
Hello!
How do you find out that you can only access data from one node but not the
other? How does it manifest?
Regards,
--
Ilya Kasnacheev
чт, 4 июн. 2020 г. в 18:26, C Ravikiran :
> I am able to see Topology snapshot in my logs as ver=23 servers=2
> offheap=93 gb heap=120 gb
>
> I am able
Graceful policy should only be applicable to caches having a number of
backups > 0.
пн, 8 июн. 2020 г. в 14:54, Alexei Scherbakov :
> V.Pyatkov
>
>
> While I agree we need a way to prevent unintentional data loss on
> shutdown, I do not like the proposed shutdown flags enum.
> I see no relation
V.Pyatkov
While I agree we need a way to prevent unintentional data loss on shutdown,
I do not like the proposed shutdown flags enum.
I see no relation between possible data loss on shutdown and waiting for
some jobs to complete.
All we need is a new method (duplicated by system property), like
Of course I meant ticket [1] increased cluster stability in situation of
blinking network.
[1] https://issues.apache.org/jira/browse/IGNITE-7163
On Mon, Jun 8, 2020 at 1:51 PM Sergey Chugunov
wrote:
> Vladimir,
>
> Adding to what Alexey has said I remember that cases of short-term network
>
Vladimir,
Adding to what Alexey has said I remember that cases of short-term network
issues (blinking network) were also a driver for this improvement. They are
indeed hard to reproduce but have been seen in real world set-ups and have
proven to increase cluster stability.
On Sat, Jun 6, 2020 at
Hello, Alexey.
Thanks for the review.
My understanding if the following:
We will have 3 in-depth tool to find issues in cluster:
1. Metrics + System views - data that describe Ignite entities very high-level.
2. Profiling - tool to know what specific query of transactions are slow.
In many
Hi
We need to have ability to calling shutdown with various guaranties.
For example:
Need to reboot a node, but after that node should be available for
historical rebalance (all partitions in MOVING state should have gone to
OWNING).
Implemented a circled reboot of cluster, but all data should
Hi, I have created jira for this issue
https://issues.apache.org/jira/browse/IGNITE-13132
Thanks,
Akash
On Sun, Jun 7, 2020 at 9:29 AM Akash Shinde wrote:
> Can someone please help me with this issue.
>
> On Sat, Jun 6, 2020 at 6:45 PM Akash Shinde wrote:
>
>> Hi,
>> Issue: Countdown latched
Akash Shinde created IGNITE-13132:
-
Summary: Countdown latched gets reinitialize to original value(4)
when one or more (but not all) node goes down.
Key: IGNITE-13132
URL:
Nikita, Igniters,
I left a few comments on the tool itself in the PR.
However, I would like to reiterate and discuss why a user would prefer to
use the profiling tool over tracing? Profiling tool only captures very
high-level details of the operations (a single cache operation, for
example), and
Vladimir,
Such behavior can be introduced by an erroneous firewall configuration (I
can't find a link, but I remember that quite a large number of major
incidents are caused by an incorrect configuration change). If such a case
can be detected, we prefer Ignite to shutdown some of the nodes
Dear Igniters,
Many of you heard about starting development of new SQL engine based on
Calcite. Currently we are only in beginning of the way and it will require
many works to achieve the goal. In order to understand where are we and
which features already done and which of them could be started
Hello!
Unfortunately your merged change is not visible in this PR (0 files
changed). Please create your pull request off your feature branch, not
master.
Regards,
--
Ilya Kasnacheev
вс, 7 июн. 2020 г. в 20:20, kartik somani :
> Hello,
>
> I have created a pull request for this issue
> <
>
Denis,
It has been done in the same day as it announced here as described at
https://www.apache.org/security/committers.html#vulnerability-handling.
Probably it require some time to information to be updated.
Also I can confirm that no any plans to provide patch for any previous
versions of
Alexander Emelianov created IGNITE-13131:
Summary: OpenCensusMetricExporterSpi and prometheus on server node
Key: IGNITE-13131
URL: https://issues.apache.org/jira/browse/IGNITE-13131
Project:
37 matches
Mail list logo
