ou help
> me with it?
>
> Sent from my iPhone
>
> > On 25 Apr 2019, at 16:25, Anton Vinogradov wrote:
> >
> > Folks,
> >
> > Just an update.
> > According to all your tips I decided to refactor API, logic, and approach
> > (mostly everything
27;m still ok with your proposal.
On Tue, Apr 30, 2019 at 9:24 PM Sergey Kozlov wrote:
> Anton
>
> I'm Ok with your proposal but IMO it should be provided as IEP?
>
> On Mon, Apr 29, 2019 at 4:05 PM Anton Vinogradov wrote:
>
> > Sergey,
> >
> > I'd li
nd computing some kind of commutative
> hash. It's safe under partition write lock.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11611
> [2] https://issues.apache.org/jira/browse/IGNITE-6324
> [3] https://issues.apache.org/jira/browse/IGNITE-11256
>
> пн, 6 мая
ulated partition hashes validation on PME can
> be a good addition to IGNITE-10078 logic: we'll be able to detect
> situations when extended update counters are equal, but for some reason
> (bug or whatsoever) partition contents are different.
>
> Best Regards,
> Ivan Rakov
>
e.org/jira/browse/IGNITE-10078
On Tue, Apr 30, 2019 at 3:14 PM Anton Vinogradov wrote:
> Ivan,
>
> Thanks for the detailed explanation.
> I'll try to implement the PoC to check the idea.
>
> On Mon, Apr 29, 2019 at 8:22 PM Ivan Rakov wrote:
>
>> > But how to
me
> (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, Ant
aving
> pre-calculated partition hash value, we can automatically detect
> inconsistent partitions on every PME. What do you think?
>
> [1] -
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-Pagereplacement(rotatio
+1 to simplification.
On Mon, Apr 29, 2019 at 3:32 PM Mikhail Petrov
wrote:
> Hi Igniters!
>
> Now plugin loading is based on presence of plugin class name in
> META-INF/service/org.apache.ignite.plugin.PluginProvider file. I propose to
> add special configuration in IgniteConfiguration for pass
Sergey,
I'd like to continue the discussion since it closely linked to the problem
I'm currently working on.
1) writeSynchronizationMode should not be a part of cache configuration,
agree.
This should be up to the user to decide how strong should be "update
guarantee".
So, I propose to have a spe
Igniters and especially Ivan Rakov,
"Idle verify" [1] is a really cool tool, to make sure that cluster is
consistent.
1) But it required to have operations paused during cluster check.
At some clusters, this check requires hours (3-4 hours at cases I saw).
I've checked the code of "idle verify" a
Sergey,
+1 to your proposal.
Looks pretty similar to Kafka's approach.
Ilya,
>> Will they stay unsynced, or is there any mechanism of re-syncing?
Yes, I'm currently working [1] on it.
The current implementation allows restoring the latest value.
[1] https://issues.apache.org/jira/browse/IGNITE
ation once refactoring will be finished.
On Tue, Apr 16, 2019 at 2:20 PM Anton Vinogradov wrote:
> Nikolay, that was the first approach
>
> >> I think we should allow to the administrator to enable/disable
> Consistency check.
> In that case, we have to introduce cluster-wide
to time>
> periods or load.
>
> I think we should allow to administrator to enable/disable Consistency
> check.
> This option shouldn't be related to application code because "Consistency
> check" is some kind of maintance procedure.
>
> What do you th
> > Anton,
> >
> > I'm trying tell you that this proxy can produce false positive result,
> > incorrect result and just hide bugs. What will the next solution?
> > withNoBugs proxy?
> >
> > You can perform consistency check using idle verify utility. Reco
is reaching bugless
> implementation of current functionality.
>
> On Mon, Apr 15, 2019 at 4:51 PM Anton Vinogradov wrote:
> >
> > Andrey,
> >
> > >> It means also that at least method name is bad.
> > Agreed, already discussed with Aleksey Plekhanov.
> > Deci
thConsistency proxy because I doesn't have
> other choice - all ways are unreliable and withConsistency just sounds
> better.
>
> Eventually we will have two different ways for working with cache
> values with different bugs set. What is the profit?
>
>
>
> On F
gt;>
>> Thanks for the PoC.
>>
>> > finds correct values according to LWW strategy
>>
>> Can you, please, clarify what is LWW strategy?
>>
>> В Ср, 03/04/2019 в 17:19 +0300, Anton Vinogradov пишет:
>> > Ilya,
>> >
>>
alues according to LWW strategy
>
> Can you, please, clarify what is LWW strategy?
>
> В Ср, 03/04/2019 в 17:19 +0300, Anton Vinogradov пишет:
> > Ilya,
> >
> > This is impossible due to a conflict between some isolation levels and
> > get-with-consistency expec
t;
> Can you do a run of all tests with cache.forConsistency(), see if there are
> cases that fail?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 3 апр. 2019 г. в 16:17, Anton Vinogradov :
>
> > Igniters,
> >
> > Sometimes, at real deployment, we're
Igniters,
Sometimes, at real deployment, we're faced with inconsistent state across
the topology.
This means that somehow we have different values for the same key at
different nodes.
This is an extremely rare situation, but, when you have thousands of
terabytes of data, this can be a real problem
ase manager, I will try to do it. And I
> hope Anton will guide me if I'll be stuck somewhere.
>
> ср, 20 мар. 2019 г. в 13:04, Anton Vinogradov :
>
> > 2.7.42?
> > 2.7.100500?
> >
> > Let's just keep 2.7.3.
> >
> > On Wed, Mar
; because there is ignite-core 2.7.1. issued from Ignite fork. This
> >> issue
> >> > is
> >> > > now solved, so 2.8.1/2.9.1. can be created later without any risk
> >> > >
> >> > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenanc
.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov :
>
> > +1 to 2.7.1 version.
> >
> > I think it's time to learn to do minor releases.
> >
> > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov :
> >
> >
> I think your statement doesn't differs with Dmitry statement much.
> > Do we have committer who merge without confidence in patch content?
> > If yes, they should stop to do it.
> >
> >
> > пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov :
> >
> > > H
just don't merge. Let is stay in Patch Available as long as needed.
>
> In case of lazy consensus we may ask committers to add comments to the
> ticket explaining why they decided to merge a ticket without expert's
> review. This should help us avoid bad commits.
>
> Thou
The major objection is to release 2.7.1 as 2.8.
1) A lot of people fixed issues at master with version 2.8.
So, they and their companies/customers (who used Ignite) waits for 2.8
because of fixes.
At least my company waits for fixes at 2.8.
It will be a real problem to update all private links for
Dmitry,
Phrase "Code modifications can be approved by silence: by lazy consensus
(72h) after Dev.List announcement." looks unacceptable to me.
Please roll back the changes and start the discussion at the private list
and never do such updates in the future without the discussion.
On Fri, Mar 15,
+1 to 2.7.1 release and such releases at future.
On Sat, Mar 9, 2019 at 2:14 PM Vyacheslav Daradur
wrote:
> Denis,
>
> >> After this release, let's introduce a practice of maintenance
> >> releases
>
> What a reason of waiting for 2.8 to introduce maintenance release?
>
> Let's prepare 2.7.1 wit
Folks,
Please make sure you keep IEP updated and each issue mentioned.
On Tue, Feb 26, 2019 at 4:28 PM Павлухин Иван wrote:
> Ivan,
>
> Thank you for detailed answers! I would put a great care to
> @RunWith(JUnitPlatform.class) construction. As stated in junit5 docs
> [1] it does not support al
sion.
> >
> > Later we can come back to this topic and dive into it once again, maybe
> we
> > can merge it into one taking the best parts of both.
> >
> > ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
> >
> > > >> 1. Automatic tests scaling
#x27;t cover the case when some code which works on the
> > current
> > > > version will not work on older versions due to compile/runtime
> > > > incompatibility.
> > > >
> > > > Please, describe the issue in more details?
> > > >
m/apache/ignite/pull/5974/files#diff-3c44ef223c31de9ff1e10bd7699cbcdc
> >
> >
> > I think such representing of Ignite product version is more cleaner than
> > existing approach with Java classes with dependencies and manual
> dependecy
> > management.
> >
>
+5,327 −59
What about the current compatibility framework?
I see no removal or updates.
>> Each new version is represented by a single pom
Sound not good.
Could you please share examples for each feature you mentioned?
Anyway. I don't like the idea to implement something new instead of
improving
Oleg,
You may use TODO if it is really necessary.
I see no reason to have any todo at JUnit3TestLegacySupport class since
it's already marked as legacy and should be removed in the future.
And we should have an issue about this removal.
Why you closed GNITE-10177 "cleanup Junit 3 from the project
Oleg,
Every commit should be final.
Comments, TODOs and partial fixes (why @deprecated still at Javadoc?) are
unacceptable.
On Mon, Feb 18, 2019 at 3:23 PM oignatenko wrote:
> Hi Anton,
>
> There you go:
>
> PR to remove deprecation: https://github.com/apache/ignite/pull/6122
> JIRA: https://is
Oleg,
Task creation is not equaled to task in progress.
It means nothing, to be honest.
Are you going to fix this issue?
That's not the first time we have such discussion at the community.
So, now I have a clear vision.
Since you contributed code with problems you are responsible to
- fix them or
Oleg,
Still, see beforeTestsStarted is deprecated.
Since we found this deprecation was incorrect, we have to roll it back.
Please fix the issue.
On Thu, Feb 7, 2019 at 5:18 PM oignatenko wrote:
> Hi Ivan,
>
> For the sake of precision, startGrid() is currently overridden in one of
> subclasses
Congrats!
On Fri, Feb 15, 2019 at 2:23 PM Павлухин Иван wrote:
> Ilya,
>
> My congratulations! Hope to hear from you about hair-splitting in
> context of affinity and topology.
>
> пт, 15 февр. 2019 г. в 13:44, Dmitriy Pavlov :
> >
> > Congrats, Ilya. I'm glad that it eventually happened.
> >
>
I vote for any proper solution :)
For now, we have to rollback the deprecation.
On Thu, Feb 7, 2019 at 11:46 AM Павлухин Иван wrote:
> Hi,
>
> AFAIK various startGrid* methods of GridAbstractTest are not tied to
> concrete instance of test class. I think that a we can make them
> static. Also s
beforeTestsStarted() was deprecated recently.
See following comment at beforeTestsStarted():
* @deprecated This method is deprecated. Instead of invoking or overriding
it, it is recommended to make your own
* method with {@code @BeforeClass} annotation.
But, according to Junit documentation:
* An
Denis,
>> Node availability check is based on the fact, that it receives fresh
>> metrics once in metricsUpdateFreq ms.
I see the problem here.
Node availability should be checked using some ping (fast and small)
message instead of huge and slow metrics message.
On Wed, Jan 30, 2019 at 4:08 PM D
Denis,
+1 to the idea to get rid of priority.
Discovery should handle only messages used to update cluster state and
topology.
They are all small and have high priority.
There is no real reason to use discovery for metrics and similar "readonly"
features.
Maybe, better case it to have special "d
getting around 150 scala_2.10 downloads monthly. Is there
> any other component which uses it? I would remove the module in 3.0 to not
> break the compatibility.
>
> --
> Denis
>
> On Thu, Jan 10, 2019 at 8:13 AM Nikolay Izhikov
> wrote:
>
> > +1
> >
&g
+1
On Thu, Jan 10, 2019 at 6:02 PM Alexey Kuznetsov
wrote:
> +1 to drop support of Scala 2.10 in Ignite 2.8.
>
>
> On Thu, Jan 10, 2019 at 9:59 PM Yuriy Babak wrote:
>
> > Hi Igniters,
> >
> > What do you think about the drop Scala 2.10 support?
> >
> > Currently, we support two versions of Sca
Denis,
Correct me in case I got it all wrong.
Since metrics are scheduled, a possible situation is to have more than 1
TcpDiscoveryMetricsUpdateMessage inside the queue due to slow ... some
reasons.
Proposed solution looks like a fix hides the real problem.
My proposal is
1) Write a warning mess
Dmitriy,
This does not look like a production-ready case :)
How about
1) Once you need to write an entry - you have to chose not random "page
from free-list with enough space"
but "page from free-list with enough space closest to the beginning of the
file".
2) Once you remove entry you have to m
4 дек. 2018 г., 15:23 Anton Vinogradov a...@apache.org:
>
> > Folks,
> >
> > The important thing here is that 99% of "final static" ip-finders were
> > removed. (~800 pcs.)
> > Non-static, mostly, kept as is since removal may or cause a test failure.
> >
Seems, the next step is to integrate tcbot with github.
It will be nice to have an opportunity to ask the bot to check PR right
from PR.
On Wed, Jan 9, 2019 at 12:04 PM Anton Vinogradov wrote:
> >> Committers can set up account matching between GitHub and Apache. After
> >> t
>> Committers can set up account matching between GitHub and Apache. After
>> this setup, you can merge pull requests from GitHub Web UI
That's awesome!
On Mon, Dec 31, 2018 at 1:49 AM Dmitriy Pavlov wrote:
> Dear Ignite Developers,
>
> I would like to repeat announce from other thread with mor
Slava,
please fill the issue with fix and tcbot visa.
On Tue, Dec 25, 2018 at 12:18 PM Vyacheslav Daradur
wrote:
> I prepared PR [1] to fix the issue, the test became green.
>
> Anton, could you assist with the merge, please?
>
> [1] https://github.com/apache/ignite/pull/5739
> [2] https://ci.i
aned by GC because of static final
> fields.
>
> Guys, please, do not generate a new one )
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10715
>
> On Tue, Dec 18, 2018 at 6:29 PM Anton Vinogradov wrote:
> >
> > Folks,
> >
> > Now I see 5-10% speedup at
Folks,
That's extremely awesome!
Now I see what stacktrace cause future creation and who will gain the
result and how.
Are there any chances to keep variable's values at original stacktrace?
Will this work correctly in case of concurrent calls?
for example, when more that one stacktrace will cau
Folks,
Now I see 5-10% speedup at all TC suites right after the merge.
Great fix!
On Mon, Dec 17, 2018 at 2:39 PM Vyacheslav Daradur
wrote:
> Andrey Mashenkov, at first sight, I have not seen any problems with
> .NET platform.
>
> I believe we need carefully configure ports in platform's examp
in the nearest future best way to mute test will be to
> > ignore it using:
> > @IgniteIgnore
> > or @Ignore
> > or Assume.that()
> >
> > In this case, we will not need TeamCity mutes anymore.
> >
> > I'm not sure which way of ignoring will be bes
.
> Here you should be able to unmute existing mutes.
> пн, 17 дек. 2018 г. в 16:21, Anton Vinogradov :
> >
> > Great feature!
> >
> > Could you please explain how to have a deal with it?
> > How should I mite/unmute tests for now?
> >
> > On F
Great feature!
Could you please explain how to have a deal with it?
How should I mite/unmute tests for now?
On Fri, Dec 14, 2018 at 6:50 PM Dmitriy Pavlov wrote:
> We have IgniteIgnore, so we can use it. It seems behavior is the same. We
> need just to understand in which case we can get issue
Anton Vinogradov created IGNITE-10663:
-
Summary: Consistency check
Key: IGNITE-10663
URL: https://issues.apache.org/jira/browse/IGNITE-10663
Project: Ignite
Issue Type: Task
Infra should be the owner.
BTW, How about to specify strict PR flow and get community approval before
starting such batch closes?
On Tue, Dec 11, 2018 at 5:35 PM Pavel Tupitsyn wrote:
> Dmitriy, admin rights allow closing any PRs, I wonder who is admin for
> Ignite GitHub mirror.
>
> On Tue, De
> > > at
> > >
> > >
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
> > > at
> > >
> > >
> org.apache.ignite.internal.managers.communication.GridIoManager.pro
t; I think we should continue work to turn off NoOpHandler in all tests.
>
> Dmitriy Pavlov, can you do it, as a committer of this patch?
>
> On 12/6/18 3:02 PM, Anton Vinogradov wrote:
> >>> I still hope Anton will do the first bunch of tests research to
> > demonstra
he test, and how it is
> > checked?
> > - failure handler influence, etc.
> >
> > I still hope Anton will do the first bunch of tests research to
> demonstrate
> > the idea.
> >
> > чт, 6 дек. 2018 г. в 13:39, Anton Vinogradov :
> >
> > > Dmit
6 дек. 2018 г. в 13:08, Dmitrii Ryabov :
> >
> > Ivan, I think `Workarounds` class isn't good idea, because it looks like
> we
> > create stable workarounds, which will never be fixed.
> >
> > I agree with Nikolay's solution. If no one minds, I'll cre
but I does not see anything (anyone) what can guarantee it.
> > > > > So, I personally prefer an option 1 against 2 because I believe
> that
> > > > > it is good if the system "can make a progress".
> > > > >
> &g
++1
On Wed, Dec 5, 2018 at 5:55 PM Denis Mekhanikov
wrote:
> Slava,
>
> These are exactly my thoughts, so I fully support you here.
> I already wrote about it:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/IP-finder-in-tests-td33322.html
> But I kind of abandoned this activity. Feel
we have TC run results for the PR before massive failure handler
> fallbacks were added?
> Let's create a ticket to investigate possibility of using any meaningful
> failure handler for such tests with TC report attached.
>
> On Wed, Dec 5, 2018 at 4:41 PM Anton Vinogradov wrote:
t; So threat this change as contributed mechanism for failing tests. Is it Ok
> for you?
>
> ср, 5 дек. 2018 г., 15:59 Anton Vinogradov :
>
> > >> I didn't get. What is the problem in saving No-Op for several tests?
> Why
> > >> should we keep No-Op for all?
&g
t; >
> > > > Could you please summarize what does aforementioned patch made really
> > > > worse?
> > > >
> > > > As I see, the patch added a very good thing -- meaningful failure
> > > > handler in tests. And I think it is really impo
-paste"? :)
On Wed, Dec 5, 2018 at 3:38 PM Anton Vinogradov wrote:
> Dmitriy Pavlov, Dmitrii Ryabov,
>
> >> Anton, there is no reason to revert other's contributions because you
> know
> >> how to do things better.
>
> What I see is "We replaced n
t; > worse?
> > >
> > > As I see, the patch added a very good thing -- meaningful failure
> > > handler in tests. And I think it is really important. But was is the
> > > harm and does it overweight positive result? And why?
> > > ср, 5 дек. 2018 г. в 14:
the patch added a very good thing -- meaningful failure
> handler in tests. And I think it is really important. But was is the
> harm and does it overweight positive result? And why?
> ср, 5 дек. 2018 г. в 14:03, Anton Vinogradov :
> >
> > Dmitriy,
> >
> > That&#x
Dmitrii contribution, but the initial
> selection of no-op.
>
> If you will do a test failure fixes later and you will set new handler
> StopNode+FailTest as the only option - ok for me.
>
> ср, 5 дек. 2018 г. в 13:35, Anton Vinogradov :
>
> > Dmitriy,
> >
> >
strate your idea how to transfer and handle
> exceptions. I believe it will not work because the fail handler is
> activated from any pool inside a node.
>
> ср, 5 дек. 2018 г. в 13:05, Anton Vinogradov :
>
> > Dmitriy,
> >
> > >> Which code block will do a thr
st of failover test doesn't expects if any critical internal issue
> occur and there is no need to fallback to noop.
> Other test should set custom failure handler to detect expected failures or
> if grid hanging simulation is needed (to keep hanged grid under control).
>
> On We
; >
> > > If you expect failure handler should be triggered, you can override
> > default
> > > one and rise some flag, which can be checked in test.
> > > This will make test clearer.
> > >
> > > With noop, you'll get previous unwanted beha
And you have to check the reason of failure inside the try-catch block, of
course.
In case found not equals to expected then test should rethrow the exception.
вт, 4 дек. 2018 г. в 23:21, Anton Vinogradov :
> Dmitrii,
>
> The solution is not clear to me.
> In case you expect the fa
t; BTW, if you find in any of your tests it does't need an old value of
> > handler (=NoOp), feel free to remove it.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > вт, 4 дек. 2018 г. в 20:02, Anton Vinogradov :
> >
> > > Dmitrii,
> > >
&
Dmitrii,
Could you please explain the reason of explicit set of 100+
NoOpFailureHandlers?
вт, 4 дек. 2018 г. в 19:12, Dmitrii Ryabov :
> Hello, Igniters!
>
> Today the test framework's default no-op failure handler was changed to the
> handler, which stops the node and fails the test.
>
> Over
Anton Vinogradov created IGNITE-10497:
-
Summary: jvm-pause-detector-worker should be JVM singleton
Key: IGNITE-10497
URL: https://issues.apache.org/jira/browse/IGNITE-10497
Project: Ignite
+1
пт, 30 нояб. 2018 г. в 10:05, Seliverstov Igor :
> +1
>
> пт, 30 нояб. 2018 г., 9:59 Nikolay Izhikov nizhi...@apache.org:
>
> > Igniters,
> >
> > We've uploaded a 2.7.0 release candidate to
> >
> > https://dist.apache.org/repos/dist/dev/ignite/2.7.0-rc1/
> >
> > Git tag name is 2.7.0-rc1
> >
>
Nikolay,
I have some comments.
1) Master key setup and removal is a responsibility of system administrator.
No matter how he will set a new master key or remove an old.
The only need it to have both keys, new and old, installed before starting
the rotation process.
2) Master Key rotation is a pr
Thank you very much!
вт, 9 окт. 2018 г. в 17:43, Petr Ivanov :
> New dedicated disk subsystem is installed for MTCGA utility, hope that'll
> help to free resources for other services.
>
>
> > On 21 Sep 2018, at 21:10, Anton Vinogradov wrote:
> >
> > Folks,
&
Currently, you may ask for a review by mention someone and asking him to
review.
And this approach looks good to me.
In case we'll invent reviewer field who will set the reviewer?
It's NOT ok to set somebody as a reviewer!
You should ask somebody to be a reviewer first.
And in case he agrees he wi
Nikolay,
Please check all vote_* steps to make sure that's the only problem
пн, 24 сент. 2018 г. в 18:53, Petr Ivanov :
> How then you’ll be able to push artifacts to SVN repository for vote?
>
>
>
> > On 24 Sep 2018, at 18:28, Nikolay Izhikov wrote:
> >
> > Hello, Igniters.
> >
> > Cos, I have
TCGA utility “lives” on the same server, possible resource race
> > condition, will try to separate services (at least on disk subsystem
> level)
> > - connection to GitHub is an issue too — sometimes fetch speed drops
> > significantly, that will be investigated also
&g
Still, see the same issues.
Denis,
Could you please prioritize the fix?
вт, 18 сент. 2018 г. в 14:01, Anton Vinogradov :
> Also, I see following on each resolve attempt.
> UpsourceRequestExceptionImpl: 108: Internal error: An error occurred
> during flushing data to database
>
Nikolay,
I'll perform prereview once PR will be ready.
Then we'll need some time to fix all found issues.
After that final review by another expert will be required.
Let's define the deadline for final PR and reviewer (Alexey Goncharuk?).
In other words, let's define the exact date until which fi
triy Pavlov
> >
> > вт, 18 сент. 2018 г. в 16:22, Paul Anderson :
> >
> > > Hi, may I ask for IGNITE-9298 to be included in 2.7 pls
> > >
> > > On Tue, Sep 18, 2018 at 1:03 PM Nikolay Izhikov
> > > wrote:
> > >
> > > >
Ilya,
I like your idea.
Let's create IEP and jira issues.
I will be glad to take a part in this journey once we'll discuss every
optimization in details.
чт, 13 сент. 2018 г. в 22:51, Dmitriy Setrakyan :
> Ilya,
>
> Thanks for the detailed explanation. Everything you suggested makes sense.
> Ne
Also, I see following on each resolve attempt.
UpsourceRequestExceptionImpl: 108: Internal error: An error occurred during
flushing data to database
вт, 18 сент. 2018 г. в 13:56, Anton Vinogradov :
> Folks,
>
> Who is responsible for Upsouce [1]?
> I see a performance issues last
Folks,
Who is responsible for Upsouce [1]?
I see a performance issues last week.
Can we check Upsource health?
[1] https://reviews.ignite.apache.org
Nikolay,
1) *Do not* create ignite-2.7 branch until we're not started preparation to
real 2.7.
Use some temporary branch for this check instead, eg.
ignite-2.7-release-test
2) Please make sure you'll not cause real release actions (maven release
and so on).
Perform only vote_* steps.
3) Make sur
Anton Vinogradov created IGNITE-9560:
Summary: Security permissions to restrict arbitrary code exectution
Key: IGNITE-9560
URL: https://issues.apache.org/jira/browse/IGNITE-9560
Project: Ignite
l through gitter/Skype to discuss the
> > details? Sometimes 5 minutes of chat can be more productive than long
> > running email chains. Please, do not hesitate to directly email me if you
> > mind to have a chat/call.
> >
> > On Wed, Jun 27, 2018 at 11:26 AM Anton
sure that we should perform exactly 1000 executions, hopefully, we will
> stop adding to the queue new tasks at some point.
>
> On Tue, 4 Sep 2018 at 12:59 Anton Vinogradov wrote:
>
> > Maxim,
> > 20 is not 1k :)
> > Also, you forgot to check GridCacheRebalancingAsyncS
s) be done
> > in TC?
> >
> >
> > On Tuesday, September 4, 2018, 5:42:01 p.m. GMT+9, Anton Vinogradov <
> > a...@apache.org> wrote:
> >
> > Roman,
> >
> > I see you uncommented this line.
> > I do not remember deadlock detail, but
Roman,
I see you uncommented this line.
I do not remember deadlock detail, but I remember it was the extremely rare
case.
I found and "fixed" it some days before merge when I had 24x7 sanity check
week :)
So, I propose to have at least 1_000 runs of this tests before keeping this
uncommented.
Dmitry,
Not sure I understand the issue, but I see no reason to rollback anything.
In case we have some issues, let's just fix them.
сб, 25 авг. 2018 г. в 0:53, Dmitriy Pavlov :
> Hi Anton,
>
> Do you have objections about a partial rollback of changes?
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 24
Vyacheslav.
It looks like we able to restart all services on grid startup from old
definitions (inside cache) in case persistence turned on.
Se no problems to provide such automated migration case.
Also, we can test it using compatibility framework.
BTW, Is proposed solution provides the guarante
Issue [1] created.
[1] https://issues.apache.org/jira/browse/IGNITE-9346
пн, 20 авг. 2018 г. в 17:27, Denis Magda :
> Yes, let’s just remove md5. Will you create the ticket and handle this for
> 2.7?
>
> Denis
>
> On Monday, August 20, 2018, Anton Vinogradov
Anton Vinogradov created IGNITE-9346:
Summary: md5 should be removed from release
Key: IGNITE-9346
URL: https://issues.apache.org/jira/browse/IGNITE-9346
Project: Ignite
Issue Type: Task
301 - 400 of 940 matches
Mail list logo
