Ivan Rakov created IGNITE-13371:
---
Summary: Sporadic partition inconsistency after historical
rebalancing of updates with same key put-remove pattern
Key: IGNITE-13371
URL: https://issues.apache.org/jira/browse
t.
> I’d rather provide two separate metrics - processedKeys and localCacheSize.
>
> > 11 авг. 2020 г., в 16:26, Ivan Rakov написал(а):
> >
> >>
> >> As a compromise, I can add jmx methods (rebuilding indexes in the
> process
> >> and the percentage of
ndexes in the process
> and the percentage of rebuilding) for the entire node, but I tried to find
> a suitable place and did not find it, tell me where to add it?
> > On the other hand, % of index rebuild progress is self-descriptive. I
> don't
> > understand why we tend to make us
t; > I find one single metric much more usable. It would be perfect if metric
> > value is represented in percentage, e.g. current progress of local node
> > index rebuild is 60%.
>
> 10.08.2020, 19:11, "Ivan Rakov" :
> > Folks,
> >
> > Sorry for com
Folks,
Sorry for coming late to the party. I've taken a look at this issue during
review.
How can a local number of processed keys can help us to understand when
index rebuild will be finished?
We can't compare metric value with cache.size(). First one is node-local,
while cache size covers all
che.org/jira/browse/IGNITE-12489
> > [4]: https://issues.apache.org/jira/browse/IGNITE-12911
> > [5]: https://issues.apache.org/jira/browse/IGNITE-12553
> > [6]:
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Complete-Discontinuation-of-IGFS-an
Alex,
Tracing is merged to master:
https://issues.apache.org/jira/browse/IGNITE-13060
Can you please port it to 2.9?
For you convenience, there's PR versus 2.9 with conflicts resolved:
https://github.com/apache/ignite/pull/8046/files
--
Best Regards,
Ivan Rakov
On Wed, Jul 15, 2020 at 5:33 PM
0)
> > 2) Select only that partition for historical rebalance where difference
> > between counters less that partition size.
> >
> > Also implement mentioned optimization for historical iterator, that may
> > reduce a time on reading large WAL interval.
>
es. As a result, detection of
the absence of updates between two checkpoint markers with the same
partition counter can be false positive.
--
Best Regards,
Ivan Rakov
On Tue, Jul 14, 2020 at 3:03 PM Vladislav Pyatkov
wrote:
> Hi guys,
>
> I want to implement a more honest heuristic for histor
://issues.apache.org/jira/browse/IGNITE-13060
--
Best Regards,
Ivan Rakov
On Tue, Jul 14, 2020 at 6:16 AM Alexey Kuznetsov
wrote:
> Alex,
>
> Can you cherry-pick to Ignite 2.9 this issue:
> https://issues.apache.org/jira/browse/IGNITE-13246 ?
>
> This issue is about BASELINE events and
Igniters,
The PR is ready to be merged, all comments from my side have been fixed.
If anyone has more comments, please let know today.
Best Regards,
Ivan Rakov
On Tue, Jun 30, 2020 at 10:43 AM Alexander Lapin
wrote:
> Hello Igniters,
>
> I'd like to discuss with you and then donat
Ivan Rakov created IGNITE-13211:
---
Summary: Improve public exceptions for case when user attempts to
access data from a lost partition
Key: IGNITE-13211
URL: https://issues.apache.org/jira/browse/IGNITE-13211
+1 to Alex G.
>From my experience, the most interesting cases with Ignite rebalancing
happen exactly in production. According to the fact that we already have
detailed rebalancing logging, adding info about rebalance performance looks
like a reasonable improvement. With new logs we'll be able to
Vlad,
+1, that's what I mean.
We don't need either or dedicated USE_STATIC_CONFIGURATION in case
the user will be able to retrieve current shutdown policy and apply the one
he needs.
My only requirement is that ignite.cluster().getShutdownPolicy() should
return a statically configured value
the code freeze date.
Let's include tracing to the 2.9 release scope.
More info:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing
https://issues.apache.org/jira/browse/IGNITE-13060
--
Best Regards,
Ivan Rakov
On Sat, Jun 6, 2020 at 4:30 PM Denis Magda wrote:
> Hi fo
C_CONFIGURATION)
> throw new IllegalArgumentException("USE_STATIC_CONFIGURATION can
> only be passed as dynamic property value via
> ignite.cluster().setShutdownPolicy");
> ...
> }
> ...
> }
>
What do you think?
On Tue, Jun 9, 2020 at 11:46 AM Alexei
org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange(timeout)
>
>
>
> вт, 9 июн. 2020 г. в 15:12, Ivan Rakov :
>
> > Something went wrong with gmail formatting. Resending my reply.
> >
> > Alex,
> >
> > Also shutdown policy mu
wnPolicy shutdownPlc) {
> if (shutdownPlc == USE_STATIC_CONFIGURATION)
> throw new IllegalArgumentException("USE_STATIC_CONFIGURATION can
> only be passed as dynamic property value via
> ignite.cluster().setShutdownPolicy");
> ...
> }
> ...
&
C_CONFIGURATION)
> throw new IllegalArgumentException("USE_STATIC_CONFIGURATION can
> only be passed as dynamic property value via
> ignite.cluster().setShutdownPolicy");
> ...
> }
> ...
> }
>
What do you think?
On Tue, Jun 9, 2020 at 11:46 AM Alexei
and kill .
5. *Don't* add new options to the static IgniteConfiguration to avoid
conflicts between dynamic and static configuration
--
Best Regards,
Ivan Rakov
On Mon, Jun 8, 2020 at 6:44 PM V.Pyatkov wrote:
> Hi
>
> We need to have ability to calling shutdown with various guaranties.
> Fo
ting to default, in this
> case system param need to be appended.
>
>
>
> >https://issues.apache.org/jira/browse/IGNITE-13064 is raised with label
> >"newbie".
> >
> >On Tue, May 19, 2020 at 4:10 PM Ivan Rakov < ivan.glu...@gmail.com >
> wrote
https://issues.apache.org/jira/browse/IGNITE-13064 is raised with label
"newbie".
On Tue, May 19, 2020 at 4:10 PM Ivan Rakov wrote:
> Support this idea in general but why 5 minutes and not less?
>
> This value looks to me greater than any value that can possibly affect
>
Ivan Rakov created IGNITE-13064:
---
Summary: Set default transaction timeout to 5 minutes
Key: IGNITE-13064
URL: https://issues.apache.org/jira/browse/IGNITE-13064
Project: Ignite
Issue Type
Folks,
Just keeping you informed: I and my colleagues are highly interested in TDE
in general and keys rotations specifically, but we don't have enough time
so far.
We'll dive into this feature and participate in reviews next month.
--
Best Regards,
Ivan Rakov
On Sun, May 17, 2020 at 10:51 PM
Ivan Rakov created IGNITE-13052:
---
Summary: Calculate result of reserveHistoryForExchange in advance
Key: IGNITE-13052
URL: https://issues.apache.org/jira/browse/IGNITE-13052
Project: Ignite
along with Ignite and suddenly experience TX deadlock.
--
Best Regards,
Ivan Rakov
On Tue, May 19, 2020 at 10:31 AM Anton Vinogradov wrote:
> +1
>
> On Mon, May 18, 2020 at 9:45 PM Sergey Antonov
> wrote:
>
> > +1
> >
> > пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov
will hang for a while) and skip step with googling
and debugging.
2. Almost every system with transactions has timeout enabled by default.
WDYT?
--
Best Regards,
Ivan Rakov
Taras,
Congratulations and welcome!
On Tue, May 12, 2020 at 8:26 PM Denis Magda wrote:
> Taras,
>
> Welcome, that was long overdue on our part! Hope to see you soon among the
> PMC group.
>
> -
> Denis
>
>
> On Tue, May 12, 2020 at 9:09 AM Dmitriy Pavlov wrote:
>
> > Hello Ignite Community,
>
idance
> of duplicate (or even controversial) notifications from 2 bots at the
> same time.
>
> Best regards,
> Ivan Pavlukhin
>
> вт, 12 мая 2020 г. в 15:06, Ivan Rakov :
> >
> > Hi,
> >
> > I've created an INFRA ticket [1] for forwarding requests from &q
ity-bot
--
Best Regards,
Ivan Rakov
On Tue, May 12, 2020 at 12:44 PM Ilya Kasnacheev
wrote:
> Hello!
>
> It would be nice if somebody would try to bring up a parallel deployment of
> MTCGA bot on Apache domain.
>
> This way people will have a choice of using "old&
Hi,
IGNITE_WRITE_REBALANCE_PARTITION_DISTRIBUTION_THRESHOLD - threshold
> duration rebalance of cache group after which partitions distribution is
> output, set in milliseconds, default value is 10 minutes.
Does it mean that if the rebalancing process took less than 10 minutes,
only a short
Hi,
I suggest to include these fixes into 2.8.1 release:
https://issues.apache.org/jira/browse/IGNITE-12101
https://issues.apache.org/jira/browse/IGNITE-12651
On Fri, Apr 17, 2020 at 11:32 AM Ivan Pavlukhin wrote:
> Hi folks,
>
> A side note from an external spectator. Should not we reflect on
Hi everyone!
Major changes that are going to be contributed from our side:
- https://issues.apache.org/jira/browse/IGNITE-11704 - keeping tombstones
for removed entries to make rebalance consistent (this problem is solved by
on-heap deferred deletes queue so far).
-
ons?
>
>
> 30.03.2020 20:02, Ivan Rakov пишет:
> > Vladimir,
> >
> > @param forceDeactivation If {@code true}, cluster deactivation will be
> >> forced.
> > It's true that it's possible to infer semantics of forced deactivation
> from
> > other parts
t;
> /* /
>
> //
>
> /* NOTE:/
>
> //
>
> /* Deactivation clears in-memory caches (without persistence) including
> the system caches./
>
> Should be enough. Is not?
>
>
> 27.03.2020 10:51, Ivan Rakov пишет:
> > Vladimir, Igniters,
>
in untangling security logic. Let's help them a bit.
See more details in my JIRA comment:
https://issues.apache.org/jira/browse/IGNITE-12759
On Thu, Mar 26, 2020 at 5:54 PM Ivan Rakov wrote:
> Denis,
>
> I'll review your PR. If this issue is a subject to be included in 2.8.1 in
> em
Vladimir, Igniters,
Let's emphasize our final plan.
We are going to add --force flags that will be necessary to pass for a
deactivation if there are in-memory caches to:
1) Rest API (already implemented in [1])
2) Command line utility (already implemented in [1])
3) JMX bean (going to be
urity+Context+of+thin+client+on+remote+nodes
>
>
> вт, 24 мар. 2020 г. в 12:26, Ivan Rakov :
>
> > Alexey,
> >
> > That can be another version of our plan. If everyone agrees that
> > SecurityContext and SecuritySubject should be merged, such fix of thi
d intentionally.
>
> So, my understanding that current implementation would be here for a while.
> And after we fix it I totally support removing —force flag.
>
> > 24 марта 2020 г., в 12:06, Ivan Rakov
> написал(а):
> >
> >>
> >> I think the only qu
h Ivan. I've implemented both variants,
> > and I like one with #securityContext(UUID) more.
> >
> > Could you please take a look at PR [1] for the issue [2]?
> >
> > 1. https://github.com/apache/ignite/pull/7523
> > 2. https://issues.apache.org/jira/browse/IGNITE-
ata loss on deactivation for in-memory
> caches.
> >>
> >> For me, the ultimate value of Ignite into real production environment is
> >> user data.
> >> If we have some cases when data is lost - we should avoid it as hard as
> we
> >> can.
> >>
> >
Folks,
Let's revive this discussion until it's too late and all API changes are
merged to master [1].
Seems like we don't have a final agreement on whether we should add force
flag to deactivation API.
First of all, I think we are all on the same page that in-memory caches
data vanishing on
> "Possible results are not consistent due to rebalance still in progress" ?
> Thanks !
>
> >Понедельник, 23 марта 2020, 12:30 +03:00 от Ivan Rakov <
> ivan.glu...@gmail.com>:
> >
> >Zhenya,
> >
> >As for me, the current behavior of idle_veri
Zhenya,
As for me, the current behavior of idle_verify looks correct.
There's no sense in checking MOVING partitions (on which we explicitly
inform user), however checking consistency between the rest of owners still
makes sense: they still can diverge and we can be aware of the presence of
the
Alex, Denis,
Seems like security API is indeed a bit over-engineered.
Let's get rid of SecurityContext and use SecuritySubject instead.
> SecurityContext is just a POJO wrapper over
> SecuritySubject's
> org.apache.ignite.plugin.security.SecuritySubject#permissions.
> It's functionality can be
Hello,
+1 from me for rebalance delay deprecation.
I can imagine only one actual case for this option: prevent excessive load
on the cluster in case of temporary short-term topology changes (e.g. node
is stopped for a while and then returned back).
Now it's handled by baseline auto adjustment in
-1 Prohibit
>From my point of view, deprecation of the existing API will confuse users
in case API suggested as a replacement is marked with @IgniteExperimental.
On Mon, Feb 10, 2020 at 12:20 PM Nikolay Izhikov
wrote:
> +1
>
> > 10 февр. 2020 г., в 11:57, Andrey Mashenkov
> написал(а):
> >
>
see a discussion for a
> first time and there is already a conclusion. And the discussion was
> started lesser than 24 hours ago. I suppose we should allow everyone
> interested to share an opinion (here I agree with the proposal) and it
> usually requires some time in open-source communiti
atomic and transactional caches.
>
> -
> Denis
>
>
> On Tue, Feb 4, 2020 at 3:28 AM Ivan Rakov wrote:
>
> > Igniters,
> >
> > Apparently it's possible in Ignite to configure a cache group with both
> > ATOMIC and TRANSACTIONAL caches.
> > Proof: IgniteC
Ivan Rakov created IGNITE-12622:
---
Summary: Forbid mixed cache groups with both atomic and
transactional caches
Key: IGNITE-12622
URL: https://issues.apache.org/jira/browse/IGNITE-12622
Project: Ignite
> [1] https://issues.apache.org/jira/browse/IGNITE-2313
>
> On Tue, Feb 4, 2020 at 2:28 PM Ivan Rakov wrote:
>
> > Igniters,
> >
> > Apparently it's possible in Ignite to configure a cache group with both
> > ATOMIC and TRANSACTIONAL caches.
> > Proof: Ign
groups. I believe that in fact no one has ever tried to do it.
Please let me know if you are aware of any cases where mixed groups are
used or reasons to keep them. Otherwise I'll create a ticket to prohibit
mixed configurations.
[1]: https://issues.apache.org/jira/browse/IGNITE-11797
--
Best Reg
Ivan Rakov created IGNITE-12607:
---
Summary: PartitionsExchangeAwareTest is flaky
Key: IGNITE-12607
URL: https://issues.apache.org/jira/browse/IGNITE-12607
Project: Ignite
Issue Type: Bug
ctly forbidden.
>
> Please refer to https://www.db.com/disclosures for additional EU
> corporate and regulatory disclosures and to
> http://www.db.com/unitedkingdom/content/privacy.htm for information about
> privacy.
>
--
Best Regards,
Ivan Rakov
Ivan Rakov created IGNITE-12545:
---
Summary: Introduce listener interface for components to react to
partition map exchange events
Key: IGNITE-12545
URL: https://issues.apache.org/jira/browse/IGNITE-12545
t; >>> Folks,
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >>> Let me remind you that we are working on the 2.8 release
> > branch
> > > > >> > >>> stabilization c
Ivan Rakov created IGNITE-12531:
---
Summary: Cluster is unable to change BLT on 2.8 if storage was
initially created on 2.7 or less
Key: IGNITE-12531
URL: https://issues.apache.org/jira/browse/IGNITE-12531
Folks,
Since 2.4, Ignite cluster requires baseline topology in persistent mode.
That means if user wants to scale cluster and add more nodes, data won't be
redistributed among the whole node set until manual call of
IgniteCluster#setBaselineTopology.
Surely this behavior is well-documented, but
Maxim M. and anyone who is interested,
I suggest to include this fix to 2.8 release:
https://issues.apache.org/jira/browse/IGNITE-12225
Basically, it's a result of the following discussion:
Ivan Rakov created IGNITE-12510:
---
Summary: In-memory page eviction may fail in case very large
entries are stored in the cache
Key: IGNITE-12510
URL: https://issues.apache.org/jira/browse/IGNITE-12510
Ivan Rakov created IGNITE-12509:
---
Summary: CACHE_REBALANCE_STOPPED event raises for wrong caches in
case of specified RebalanceDelay
Key: IGNITE-12509
URL: https://issues.apache.org/jira/browse/IGNITE-12509
Ivan Rakov created IGNITE-12508:
---
Summary: GridCacheProcessor#cacheDescriptor(int) has O(N)
complexity
Key: IGNITE-12508
URL: https://issues.apache.org/jira/browse/IGNITE-12508
Project: Ignite
Ivan Rakov created IGNITE-12507:
---
Summary: Implement cache size metric in bytes
Key: IGNITE-12507
URL: https://issues.apache.org/jira/browse/IGNITE-12507
Project: Ignite
Issue Type
Ivan Rakov created IGNITE-12451:
---
Summary: Introduce deadlock detection for cache entry reentrant
locks
Key: IGNITE-12451
URL: https://issues.apache.org/jira/browse/IGNITE-12451
Project: Ignite
Ivan Rakov created IGNITE-12429:
---
Summary: Rework bytes-based WAL archive size management logic to
make historical rebalance more predictable
Key: IGNITE-12429
URL: https://issues.apache.org/jira/browse/IGNITE
+1 for Dmitry Pavlov
Best Regards,
Ivan Rakov
On 29.10.2019 10:50, Ilya Kasnacheev wrote:
+1 for Nikolay Izhikov (binding)
Regards,
https://issues.apache.org/jira/browse/IGNITE-12278
Best Regards,
Ivan Rakov
On 07.10.2019 15:08, Ivan Rakov wrote:
Denis, Alex,
Sure, new metric will be integrated into new metrics framework.
Let's not expose its value to control.sh right now. I'll create an
issue for aggregated
Ivan Rakov created IGNITE-12278:
---
Summary: Add metric showing how many nodes may safely leave the
cluster wihout partition loss
Key: IGNITE-12278
URL: https://issues.apache.org/jira/browse/IGNITE-12278
Denis, Alex,
Sure, new metric will be integrated into new metrics framework.
Let's not expose its value to control.sh right now. I'll create an issue
for aggregated "getMinimumNumberOfPartitionCopies" if everyone agrees.
Best Regards,
Ivan Rakov
On 04.10.2019 20:06, Denis Magda w
short path. I've started this topic due to request from user list, and
I've heard many similar complaints before.
Best Regards,
Ivan Rakov
On 04.10.2019 17:18, Nikolay Izhikov wrote:
Ivan.
We shouldn't force users to configure external tools and write extra code for
basic things.
Actually, I d
external tools and write extra code for basic things.
Alex,
Thanks, that's exact metric we need.
My point is that we should make it more accessible: via control.sh
command and single method for the whole cluster.
Best Regards,
Ivan Rakov
On 04.10.2019 16:34, Alex Plehanov wrote:
Ivan
is in danger of data loss. Another point is that current metrics
are bound to specific cache, which makes this information even harder to
analyze.
Thoughts?
--
Best Regards,
Ivan Rakov
Alexey,
I've merged https://issues.apache.org/jira/browse/IGNITE-12163 to master
and 2.7.6.
Best Regards,
Ivan Rakov
On 11.09.2019 18:13, Alexey Goncharuk wrote:
Good,
Please let me know when this is done, I will re-upload the release
artifacts.
ср, 11 сент. 2019 г. в 18:11, Alexandr
+1
Downloaded binaries, successfully assembled cluster.
Best Regards,
Ivan Rakov
On 23.08.2019 19:07, Dmitriy Pavlov wrote:
+1
Checked: build from sources, startup node on Windows, simple topology,
version and copyright year output,
2.7.6-rc0 is used in the Apache Ignite Teamcity Bot since
Choosing the smallest of two evils, I'll agree with user.dir.
Being able to run without preset env variables is strong benefit for
Ignite as a product.
Best Regards,
Ivan Rakov
On 12.08.2019 19:02, Denis Magda wrote:
+1 for the user.dir as a default one.
Denis
On Monday, August 12, 2019
#igniteWorkDir is set. It's better to let user know
about missing configuration options during startup than let OS corrupt
storage by cleaning temp dirs.
Thoughts?
Best Regards,
Ivan Rakov
On 12.08.2019 18:10, Anton Kalashnikov wrote:
Hello, Igniters.
Currently, in the case, when work directory wasn't
will be able to deal with current solution.
Distributed Metastorage is a good candidate for storing and handling
such configuration options.
Best Regards,
Ivan Rakov
On 05.08.2019 18:38, Nikolay Izhikov wrote:
Hello, Andrey.
Not necessary if we have exponential bounds' values for histograms
e resource intensive as it requires parsing logs for all the time
- It's less reliable as log messages may change
Best Regards,
Ivan Rakov
On 24.07.2019 14:57, Maxim Muzafarov wrote:
Folks,
+1 with Anton post.
What if we just update current metric getCurrentPmeDuration behaviour
to show durations on
Boolean metric "are we blocked right now"
is not needed as it's obviously can be inferred from "current PME block
time".
Best Regards,
Ivan Rakov
On 23.07.2019 16:02, Pavel Kovalenko wrote:
Nikita,
I agree with total blocking duration metric but
I still don't understand why
Hello Max,
Thanks for your analysis!
Have you created a JIRA issue for discovered defects?
Best Regards,
Ivan Rakov
On 17.07.2019 17:08, Maksim Stepachev wrote:
Hello, Igniters.
The main idea of the new security is propagation security context to
other nodes and does action
lock release
Best Regards,
Ivan Rakov
On 15.07.2019 9:34, Anton Vinogradov wrote:
Ivan R.
Thanks for joining!
Got an idea, but not sure that got a way of a fix.
AFAIK (can be wrong, please correct if necessary), at 2PC, locks are
acquired on backups during the "prepare" phase and re
1 (lock primary) and 2 (update primary +
lock backup + update backup), you may be sure that there will be no
false-positive results and no deadlocks as well. Protocol won't be
complicated: checking read from backup will just wait for commit if it's
in progress.
Best Regards,
Ivan Rakov
ut still may receive updates
from previous primary. I don't know how to handle these updates
correctly as they may conflict with new updates and locks.
How do you think, can we overcome this limitation with our existing
implementation of transactions?
Best Regards,
Ivan Rakov
On 01.07.2019 1
handle these updates
correctly as they may conflict with new updates and locks.
How do you think, can we overcome this limitation with existing
transaction implementation?
Best Regards,
Ivan Rakov
On 10.07.2019 2:25, Ivan Rakov wrote:
Hi Nikita,
I've checked out your branch, looked through the changes a
Best Regards,
Ivan Rakov
On 01.07.2019 11:13, Nikita Amelchev wrote:
Hi, Igniters.
I'm working on the implementation of lightweight PME for a baseline
node leave case. [1] In my implementation, each node recalculates a
new affinity and completes PME locally without distributed
communi
contents are different.
Best Regards,
Ivan Rakov
On 06.05.2019 12:27, Anton Vinogradov wrote:
Ivan, just to make sure ...
The discussed case will fully solve the issue [1] in case we'll also add
some strategy to reject partitions with missed updates (updateCnt==Ok,
Hash!=Ok).
For example, we may use
, PME happens on prod clusters from time to time
(several times per week), which can be enough. In case it's needed to
check consistency more often than regular PMEs occur, we can implement
command that will trigger fake PME for consistency checking.
Best Regards,
Ivan Rakov
On 29.04.2019 18:53
t do you
think?
[1] -
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-Pagereplacement(rotationwithdisk)
Best Regards,
Ivan Rakov
On 29.04.2019 12:20, Anton Vinogradov wrote:
Igniters and especially Ivan Rakov,
&qu
). To sum it up, both issues should be fixed now.
Best Regards,
Ivan Rakov
On 26.04.2019 14:40, Павлухин Иван wrote:
Ivan R.,
As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does
not expect lock/unlock events due to line:
if (atomicityMode() == ATOMIC)
return lockEvtCnt.get
entries on ATOMIC get, therefore I
suppose to remove part of code where we listen and check
EVT_CACHE_OBJECT_LOCKED/UNLOCKED events.
Best Regards,
Ivan Rakov
On 17.04.2019 22:05, Ivan Rakov wrote:
Hi Ivan,
I've checked your branch. Seems like these tests fail due to real
issue in functionality
Ivan Rakov created IGNITE-11807:
---
Summary: Index validation control.sh command may provide
false-positive error results
Key: IGNITE-11807
URL: https://issues.apache.org/jira/browse/IGNITE-11807
Project
Hi Ivan,
I've checked your branch. Seems like these tests fail due to real issue
in functionality.
I'll take a look.
Best Regards,
Ivan Rakov
On 17.04.2019 13:54, Ivan Fedotov wrote:
Hi, Igniters!
During work on iep-30[1] I discovered that
IgniteConfigVariationsAbstractTest subclasses
Ivan Rakov created IGNITE-11769:
---
Summary: Investigate JVM crash in PDS Direct IO TeamCity suites
Key: IGNITE-11769
URL: https://issues.apache.org/jira/browse/IGNITE-11769
Project: Ignite
Ivan Rakov created IGNITE-11762:
---
Summary: Test testClientStartCloseServersRestart causes hang of
the whole Cache 2 suite in master
Key: IGNITE-11762
URL: https://issues.apache.org/jira/browse/IGNITE-11762
Ivan Rakov created IGNITE-11747:
---
Summary: Document --tx control script commands
Key: IGNITE-11747
URL: https://issues.apache.org/jira/browse/IGNITE-11747
Project: Ignite
Issue Type: Task
Ivan Rakov created IGNITE-11735:
---
Summary: Safely handle new closures of IGNITE-11392 in mixed
cluster environment
Key: IGNITE-11735
URL: https://issues.apache.org/jira/browse/IGNITE-11735
Project
Ivan Rakov created IGNITE-11591:
---
Summary: Add info about lock candidates that are ahead in queue to
transaction timeout error message
Key: IGNITE-11591
URL: https://issues.apache.org/jira/browse/IGNITE-11591
Ivan Rakov created IGNITE-11484:
---
Summary: Get rid of ForkJoinPool#commonPool usage for csystem
critical tasks
Key: IGNITE-11484
URL: https://issues.apache.org/jira/browse/IGNITE-11484
Project: Ignite
. Andrey Kalinin* 04.03.2019 2:03
Best Regards,
Ivan Rakov
On 04.03.2019 13:56, Dmitriy Pavlov wrote:
Thanks to Alexey Plehanov for noticing and Infra Team for fixing the issue:
https://issues.apache.org/jira/browse/INFRA-17950
пн, 4 мар. 2019 г. в 13:53, Dmitriy Pavlov :
Hi Developers
Ivan Rakov created IGNITE-11465:
---
Summary: Multiple client leave/join events may wipe affinity
assignment history and cause transactions fail
Key: IGNITE-11465
URL: https://issues.apache.org/jira/browse/IGNITE
1 - 100 of 284 matches
Mail list logo
