That is cool, completely forgot about it :)
2017-04-13 14:07 GMT+03:00 Pavel Tupitsyn :
> Alexey, we can read fields in any order in non-raw mode.
> Dmitriy's suggestion would work.
>
> On Thu, Apr 13, 2017 at 1:56 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.co
Agree, I will rename it if there are no objections.
2017-04-17 14:31 GMT+03:00 Vladimir Ozerov :
> Guys,
>
> I see that we throw our own "OutOfMemoryException" in this case. I think we
> should rename it to "IgniteOufOfMemoryException" to avoid confusion with
> JDK's "OutOfMemoryError". E.g. I lo
The reason we cannot add another memory region to page memory is
performance. Currently, the translation of a page ID to a virtual address
is basically a no-op. If we add dynamic memory expansion, we need to
maintain some sort of page ID mapping, which adds significant (in my view,
about 10%) overh
GNITE-4921
2017-04-18 12:04 GMT+03:00 Dmitriy Setrakyan :
> Thanks, Alexey, got it. What happens if a user starts multiple nodes on the
> same box? Will it work the way Denis suggested?
>
> On Tue, Apr 18, 2017 at 1:47 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
> https://github.com/apache/
> > > ignite/pull/1759>.
> > > > > Pavel, thank you very much for bringing that to my attention.
> > > > >
> > > > > - Alex
> > > > >
> > > > > 2017-04-07 20:28 GMT+03:00 Sergi Vlad
gt; Binary key representation is stable when we always have
> > equal
> > >>>>>>>>>>>>> serialized
> > >>>>>>>>>>>>>>> bytes when the original keys are e
; Fixed now. Thanks for checking!
> Roman
>
>
> On Tuesday, April 18, 2017 10:17 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>
> Hi Roman,
>
> I tried to run tests for RocketMQ streamer, but they failed for me (I've
> added a comment in the
Denis,
This suite is currently Work In Progress and should be ready shortly. The
goal is to get rid of 9 test suites which became obsolete since we moved
optimized marshaller off the public API.
Please validate your PRs against regular set of tests. We will let
community know when the project is
introduce one more configuration property to specify
> > default
> > > MemoryPolicy's size in bytes without having to use verbose syntax of
> > > *memoryPolicyConfiguration
> > > *section.
> > >
> > > Any thoughts on this?
> > >
> >
y I'm
> > also
> > > > suggesting to introduce one more configuration property to specify
> > > default
> > > > MemoryPolicy's size in bytes without having to use verbose syntax of
> > > > *memoryPolicyConfiguration
> > > > *sec
Denis,
Semantically nothing changed for expiry policies, it applies for all local
entries.
2017-04-21 2:17 GMT+03:00 Denis Magda :
> Alex G., Igniters,
>
> What’s a scope of expiration policy applicability in Ignite 2.0? Does it
> work for all the entries in the page memory or only for those tha
Agree, I overlooked this during the review. However, the changes to fix
this is pretty simple - we just move all mutator methods to MBean, like
Vladimir suggested and make MBean return the live data, while the public
API will return a serializable snapshot.
Agreed?
2017-04-24 19:33 GMT+03:00 Vlad
Igniters,
Since we moved to the PageMemory architecture, several ClusterMetrics
methods became questionable, so I would like to discuss this before the
release. Currently, ClusterMetrics contains the following methods:
getNonHeapMemoryCommitted(),
getNonHeapMemoryUsed(),
getNonHeapMemoryInitialize
can handle the documentation separately as a subtask of this umbrella
> >> ticket:
> >>> https://issues.apache.org/jira/browse/IGNITE-4960
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Apr 19, 2017, at 7:03 AM, Roman S
Guys,
First of all, great job on the contribution!
I took a brief look at the source of ML lib and have a comment regarding
the SparseDistributedMatrixStorage. It looks like it will create a new
cache for every new matrix. This sounds a little bit excessive to me,
because (at least in my understa
Sasha,
The idea behind the ticket was as follows: currently, the rebalanceDelay
property is set in CacheConfiguration, which is not very flexible. In
certain circumstances, a user might expect particularly large load on some
segments of the cluster and want to disable rebalancing for those
(existi
Denis,
Headers are updated, RAT check is passing now.
2017-05-16 2:37 GMT+03:00 Denis Magda :
> The receipt of the software grant (the persistent store) was acknowledged
> by Craig Russel.
>
> Now, we need to move on with this
>
> > In the meanwhile, I’ve prepared the IP Clearance page referring
Sure, those classes will be renamed to use Ignite* prefix.
Any other comments regarding Configuration or public API changes?
2017-05-16 17:12 GMT+03:00 Alexey Kuznetsov :
> Alexey Goncharuk,
>
> I take a look at source code and noticed classes with nam
Great news! Looking forward to getting rid of the unnecessary TC
configurations.
Once this is done, I think we should also work out if we can use build
once, run tests approach for RunAll configuration. Does anybody have a clue
if this is possible?
2017-05-17 20:46 GMT+03:00 Dmitry Pavlov :
> Hi
Hi Aleksey,
The main purpose of this method is to wait for all ongoing updates
(transactional and atomic), initiated on the previous topology version, to
finish to prevent inconsistencies during rebalancing and to prevent two
different simultaneous owners of the same lock.
We will be adding docum
Done!
2017-05-18 20:33 GMT+03:00 Denis Magda :
> Alex,
>
> Can you add this excellent explanation as a part of the method Javadoc?
> That will simplify a lot the life of future contributors.
>
> —
> Denis
>
> > On May 18, 2017, at 1:05 PM, Alexey Goncharuk <
&g
ired a lock and a new node is joining cluster, should it wait
> for
> > lock release?
> > May be it could proceed joining ?
> > The question comes from my ticket
> > https://issues.apache.org/jira/browse/IGNITE-2671
> >
> > чт, 18 мая 2017 г. в 20:05, Alexey Gonc
to do.
2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV :
> Now i see. So, may be i should drop the ticket and pick smth else ?
>
> пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk :
>
> > As I described before, one of the reasons behind the waiting is to switch
> > primary node
KUZNETSOV :
>
> > Ok, i pick it
> >
> > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk >:
> >
> >> Well,
> >>
> >> I don't have any clear plan for now on how to approach this issue, so
> if I
> >> were you, I would pick something
That's not entirely true, unfortunately. Note that there may be registered
a number of extensions, which may theoretically conflict with already
listed IDs. I think we should create some sort of lookup table and make
sure that there are no duplicates after all extensions are registered, this
will s
running tests with similar results in TC Run configs
> "Ignite 2.0 Tests" as it is in "Ignite Tests".
>
> Best regards,
> Dmitry Pavlov
>
> ср, 17 мая 2017 г. в 20:52, Alexey Goncharuk :
>
> > Great news! Looking forward to getting rid of the unneces
Guys,
As discussed, pushed the branch being stabilized to ignite-5267 (and
created the corresponding ticket).
2017-05-21 6:48 GMT+03:00 Denis Magda :
> Sounds good to me.
>
> To keep all of you in the loop, eventually, the *IP clearance vote* has
> been initiated on @incubator-general. Here is t
Igniters,
Since we removed OptimizedMarshaller in Ignite 2.0 from the PublicAPI, we
had a chance to remove several unnecessary test suites from the build plan
from Ignite 2.0. I pushed the changes for IGNITE-4947 ticket. From this
moment you should run tests from Ignite 2.0 project, which is 14 te
I think it makes sense to switch non-heap memory metrics to new page memory
semantics, this should show a clean picture in the node output and will
also protect us from ambiguous -1 output.
2017-05-24 18:45 GMT+03:00 Dmitry Pavlov :
> Igniters,
>
>
>
> On my jdk 1.8.0_131 there is negative amount
Guys, I think it makes little or no sense to keep blocks on-heap. If I
understand correctly, the eviction policy was used in combined modes where
partial data eviction is allowed. To make this work in the new PageMemory
architecture, we only need to make sure that IGFS block size equals to the
data
Hi Igor,
The current implementation assumes that compactFooters should be disabled,
we did not enforce this configuration yet. However, generally, you are
right, and we must have a local-only metadata storage which will keep
binary metadata.
2017-05-25 14:46 GMT+03:00 Seliverstov Igor :
> Hi guy
Aleksey,
Generally, this decision cannot be made on a single node because a
transaction may affect multiple nodes, and one node may have already
committed the transaction and the other - not. There is a dependant ticket
in the ticket you are currently working on which will cover all the caes.
Mea
I am fine with this javadoc change as long as there is no confusion between
Ignite page memory buffers and the OS Virtual Memory concept.
2017-06-01 2:07 GMT+03:00 Dmitriy Setrakyan :
> Igniters,
>
> With the newly donated persistence functionality in Ignite, I have been
> struggling a bit on how
Same think stays for the full-text indexes which are currently stored in
Lucene.
2017-05-24 21:56 GMT+03:00 Dmitriy Setrakyan :
> Sergi,
>
> While we are figuring this out, what happens to the GeoSpatial
> functionality in the mean time? Is it going to work at all? If not, should
> we throw some
I do not like this change - we intentionally separated a few properties in
AtomicConfiguration that make sense for Atomics, there is not need to get
back to cache configuration again. In my understanding, we only need to add
groupName to Atomics and Collection configuration.
Thoughts?
2017-06-01
Guys,
I merged recent changes from the master branch (SQL-related changes) to the
integration branch, we need another TC run to see if the merge broke
something.
2017-06-01 19:14 GMT+03:00 Dmitriy Setrakyan :
> BTW, can anyone explain to me why do we keep the new persistence code in a
> separate
soon". We never add suche messages without reference to JIRA issue, please
> fix.
>
> Thanks!
>
> On Thu, Jun 1, 2017 at 7:22 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > wrote:
>
> > Guys,
> >
> > I merged recent changes from the master
Dmitriy,
The original idea behind moving persistence to a separate module was
easiness of review and the fact that it is likely that in the future it
will have some external dependencies. I guess we can have those
dependencies as a separate module and move persistence to the core module.
2017-06-
Guyd,
I've extended the set of metrics a little bit and pushed my changes to
ignite-5375 branch. Can you please review the metrics and see if we are now
ok with the interfaces?
2017-06-01 21:04 GMT+03:00 Denis Magda :
> Sergey, thanks,
>
> You get a green light from my side. Please go ahead and
Hi Semyon,
Given that both ServiceDescriptors and service assignments are stored in
the system cache, services should survive the cluster restart, but this
needs to be double-checked because service assignments become obsolete and
need to be fully recalculated.
I will check this and give an updat
I am currently in the middle of the debugging - the issue does not look
related to the persistent store changes now.
2017-06-07 5:47 GMT+03:00 Dmitriy Setrakyan :
> On Tue, Jun 6, 2017 at 1:21 AM, Semyon Boikov
> wrote:
>
> > Does anybody monitor TeamCity for ignite-5267? I see suite 'Ignite PDS
Denis,
Thanks for the review. I addressed your comments and merged the changes to
ignite-5267 branch.
2017-06-06 22:56 GMT+03:00 Denis Magda :
> > On Jun 5, 2017, at 8:02 PM, Konstantin Boudnik wrote:
> >
> > On Mon, Jun 05, 2017 at 07:41PM, Dmitriy Setrakyan wrote:
> >> On Mon, Jun 5, 2017 at
Hi Alexey,
I've added you to the contributors' list. Please assign the issue to
yourself.
--AG
2017-06-07 14:47 GMT+03:00 Alexey Ivanov :
> Hi, everybody
>
> I'd like fix this issue:
>
> https://issues.apache.org/jira/browse/IGNITE-5432
>
> Alexey Ivanov (a1vanov)
>
>
Vladimir,
Your concerns sound reasonable to me. However, I have a feeling that there
was a specific reason why added CacheKeyConfiguration to the
IgniteConfiguration and not to the CacheConfiguration. Looks like indeed,
our original approach is not flexible enough anymore and I am +1 for the
sugge
still used and in particular we depend on it in
> IGFS inetrnals. It will require some time to refactor IGFS.
> Let's just throw an exception if both AffinityKeyMapper and affinity fields
> mappings are defined?
>
> On Thu, Jun 8, 2017 at 3:45 PM, Alexey Goncharuk <
Nikolay, I agree, a user should be able to disable both thread liveness
check and checkpoint read lock timeout check from config and a system
property.
пт, 28 сент. 2018 г. в 11:30, Nikolay Izhikov :
> Hello, Igniters.
>
> I found that this feature can't be disabled from config.
> The only way to
I think if a commit does not lead to any test failure in the current
master, there are no reasons to revert the commit. If there are valid
scenarios which are failing, corresponding tests should be added and the
root cause should be fixed under a separate issue.
пт, 28 сент. 2018 г. в 11:19, Dmitr
> > > > > > >
> > > > > > > > On Sat, Sep 8, 2018 at 2:09 PM, Saikat Maitra <
> > > >
> > > > saikat.mai...@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
Vyacheslav,
Thanks for investigating this. User code should never listen to system
custom events because this is an internal API and it's a subject to change.
If there is anything a user interested in, the corresponding public event
should be added.
Nullifying the event in this case looks ok for
Nikolay, both commits fixed a regression compared to ignite-2.6. First one
was mentioned by Anton Kalashnikov before (java-level deadlock during WAL
flush), another - by Andrey Kuznetsov (NPE during a concurrent WAL flush).
--AG
ср, 3 окт. 2018 г. в 13:38, Nikolay Izhikov :
> Hello, Igniters.
>
Dmitriy, to my knowledge, the test will be fixed by the ticket
https://issues.apache.org/jira/browse/IGNITE-9550, we expect it to be
merged by the end of this week.
ср, 3 окт. 2018 г. в 18:00, Dmitriy Pavlov :
> Hi Alexey,
>
> Could you please assist with fixing test?
>
> Sincerely,
> Dmitriy Pav
processed by SG.
>
> Could I exclude these messages from PME nullifying?
>
> On Wed, Oct 3, 2018 at 11:26 AM Alexey Goncharuk
> wrote:
> >
> > Vyacheslav,
> >
> > Thanks for investigating this. User code should never listen to system
> > custom event
ues.apache.org/jira/browse/IGNITE-9737
> >
> >
> > ср, 3 окт. 2018 г. в 14:02, Nikolay Izhikov :
> >
> >> Alexey.
> >>
> >> Sorry, I lost link to IGNITE-9760 in this thread :)
> >>
> >> Thanks, for a clarification.
> >>
&
-9834. The case is rare,
but it is quite an unpleasant UX. Should we include it to 2.7 as well?
чт, 11 окт. 2018 г. в 11:22, Nikolay Izhikov :
> Hello, Igniters.
>
> We made a good progress yesterday.
>
> Here is the list of remaining tickets(17) mapped to 2.7:
>
> Alexey Gonc
This is a flaky failure, can be ignored.
вт, 16 окт. 2018 г. в 8:40, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contrib
Last two runs are green, let's keep monitoring.
пн, 15 окт. 2018 г. в 3:25, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the
The test is flaky.
сб, 13 окт. 2018 г. в 23:10, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution to this project
Hi all,
We are working on the fix, it should be merged to master asap.
вт, 23 окт. 2018 г. в 11:18, Maxim Muzafarov :
> Hello,
>
> Are there any updates?
> The build constantly fails with `Execution timeout` in the master branch
> since October 20.
>
> The problem commit supposed to be related t
This can be ignored. I removed the test because it measured performance and
we should run performance tests in a verified environment.
вт, 23 окт. 2018 г. в 5:16, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your chang
All,
We had to revert the commit because the fix appeared to be more complex
than we expected. Tests should be ok now.
вт, 23 окт. 2018 г. в 11:20, Alexey Goncharuk :
> Hi all,
>
> We are working on the fix, it should be merged to master asap.
>
> вт, 23 окт. 2018 г. в 11:18,
gt; >
> > > > пт, 28 сент. 2018 г. в 13:15, Andrey Gura :
> > > >
> > > > > Guys,
> > > > >
> > > > > why we need both config option and system property? I believe one
> way
> > > is
> > > > > enough.
&g
Pushed a fix for the failed tests.
сб, 27 окт. 2018 г. в 5:40, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the contribution
27;ignite-2.7')
> > > > > -
> > > > >
> > > > >
> https://github.com/apache/ignite/commit/6e0ff06f8e309657a16c94da605348d9c3b804ad
> > > > >
> > > > > The most important part is the change introduced into
> GridDhtAtomicCache,
>
Hi, this is an intentionally failed test with a ticket, I've now muted it
on TC.
вт, 20 нояб. 2018 г. в 07:38, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful that
Hi David,
This is something we have also encountered recently and I was wondering how
this can be mitigated in a general case. Do you know if an application can
detect that it is being run in a docker container and add the corresponding
list of bridge IPs automatically on start? If so, I this we c
Looking into this, looks like it is related to 'set consistent ID in tests'
change.
ср, 21 нояб. 2018 г. в 09:38, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful th
Looking into this, looks like it is related to 'set consistent ID in tests'
change.
ср, 21 нояб. 2018 г. в 07:08, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful th
Looking into this, looks like it is related to 'set consistent ID in tests'
change.
ср, 21 нояб. 2018 г. в 08:23, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful th
The Apache Ignite Project Management Committee (PMC) has invited Pavel
Kovalenko to become a new committer and are happy to announce that he has
accepted.
Pavel was actively investigating and improving the speed of PME during node
join/leave scenarios and achieved great progress in these tasks.
P
le, once you know the
> bridge
> > > IPs.
> > >
> > > When the container starts, you get a list of IP addresses from the
> > > kernel. At that point it is impossible to know from inside the
> > container
> > > which of those addresses can be u
Denis,
It looks like the failing test is related to existing ATOMIC caches but it
was broken by the MVCC commit, so it is a regression. Let's wait for
Vladimir Ozerov or Igor Seliverstov to comment.
чт, 29 нояб. 2018 г. в 19:32, Nikolay Izhikov :
> Hello, Denis.
>
> Nothing blocks now.
> I prepa
Indeed, IGNITE-8926 was fixed in 2.7, but introduced a regression. The
regression was fixed in IGNITE-9794, but for some reason the last ticket
escaped the ignite-2.7 scope. Given that the regression prevents any new
type registration inside an entry processor, I think we should cherry-pick
the fix
Given that there is no option to stay on the old repository and
mass-migration is scheduled for Feb, 7th, I think it is better to prepare
and move the repository before the date.
As far as I understand, from developers standpoint we only need to change
the git remote entry. Petr, Sergey, can you a
aware of a
workaround.
чт, 25 окт. 2018 г. в 16:35, Alexey Goncharuk :
> Andrey,
>
> I still see that checkpoint read lock acquisition raises a CRITICAL_ERROR,
> which by default will shut down local node. As far as I remember, we
> decided that by default thread timeout should n
Hi Nikolay,
This is the issue I mentioned in "Critical worker threads liveness checking
drawbacks" topic which I was expecting to be included to Ignite 2.7, but it
was not. To workaround the issue, you should set
DataStorageConfiguration#setCheckpointReadLockTimeout to 0.
Should we somehow announ
uot; topic
>
> Thanks for the link, I will check it out.
>
> чт, 27 дек. 2018 г. в 12:24, Alexey Goncharuk >:
>
> > Hi Nikolay,
> >
> > This is the issue I mentioned in "Critical worker threads liveness
> checking
> > drawbacks" topic
Igniters,
I've recently stumbled across a situation when occasionally Ignite
transactions commit may take up to several seconds while in general most of
the transactions completed in a period of milliseconds.
After a few attempts to analyze this situation with logs, I realized that
this is a no-g
Agree,
Since we rely on cache start order during the node start, the same order
should be preserved during activation.
2017-07-21 15:24 GMT+03:00 Jokser :
> Hello Igniters,
>
> Currently order of cache starts/stops operations is not determined during
> cluster activation.
> Some of the cache com
Denis,
Added you to the contributors list.
2017-07-25 16:04 GMT+03:00 Denis Mekhanikov :
> My JIRA ID: dmekhanikov
>
> Thank you!
>
> вт, 25 июл. 2017 г. в 15:09, Dmitry Pavlov :
>
> > Hi Denis,
> >
> > Welcome to the Ignite community!
> >
> > If you need contributor access to Apache JIRA, could
Sergey,
Added you to the contributors list.
2017-07-28 18:02 GMT+03:00 Серега Дорожкин :
> Yes, I need contributor access to Apache JIRA.
> Link to my JIRA account:
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stalkxt
>
> 2017-07-28 17:41 GMT+03:00 Dmitry Pavlov :
>
> > Hi Serge
>
> Without knowing why, how can we make a decision?
>
> Alexey Goncharuk, was it you who made the decision about not using
> increments? Do know remember what was the reason?
>
>
> >
> > The very problem is that before being started once on production
> > e
I think we should be able to change the BT in the runtime, and a user
should have several ways to do this:
* programmatically via the API suggested by Sergey
* Using management tools (console visor on Web Console)
* Based on some sort of policies when the actual cluster topology differs
too muc
Do I understand correctly that this is not a multiplexed protocol? Are we
ok to have a separate connection for each thread? I would also add a
requestId field to allow multiple concurrent requests at a time.
2017-08-02 10:50 GMT+03:00 Vladimir Ozerov :
> Yakov,
>
> Yes, explicit protocol versioni
Vladimir,
Personally, I agree that we should put correctness over performance,
however (1) is not a correct statement for TRANSACTIONAL caches. A
transactional client always validates the result of an operation and throw
a correct exception if operation failed. (1) is true for ATOMIC caches,
thoug
My understanding of Baseline Topology is the set of nodes which are
*expected* to be in the cluster.
Let me go a little bit further because BT (or whatever name we choose) may
and will solve more issues than just auto-activation:
1) More graceful control over rebalancing than just rebalance delay.
Val,
I left a response in the ticket.
--AG
2017-08-03 22:13 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> Folks,
>
> One of the users reported an issue with near cache in 2.0:
> https://issues.apache.org/jira/browse/IGNITE-5926
>
> There is a reproducer attached, I don't see
Maybe the "crashed" word is a bit strong here, we can change it to "stop"
and add a message that this is valid if Ignite is stopped by "close()"
method.
2017-08-04 10:54 GMT+03:00 Ivan Rakov :
> Dmitriy,
>
> From my point of view, invoking stop(true) is correct behaviour.
>
> Stopping node in the
Denis,
This should be handled by the BT triggers. If I have 3 backups configured,
I actually won't care if my cluster will live 6 hours without an additional
backup. If for a partition there is only one backup left - a new BT should
be triggered automatically.
2017-08-10 0:33 GMT+03:00 Denis Magd
Aleksey,
GridCacheTxFinishSync is used in IgniteTxManager#awaitFinishAckAsync()
method (the wait is done before mapping Near or Colocated lock future, see
the call hierarchy).
--AG
2017-08-11 17:52 GMT+03:00 ALEKSEY KUZNETSOV :
> Hi!
> There is GridCacheTxFinishSync synchronizer, which used to
Igniters,
I am currently reviewing a change allowing to enable persistence on a
per-memory-policy basis (thanks to K. Dudkov!) and have a question
regarding the changes in configuration.
The suggested change is to add a flag "persistenceEnabled" (defaults to
true) to the memory policy configurati
2:28 PM, Vladimir Ozerov
> wrote:
>
> > As a user I would definitely prefer to control persistence through flag
> on
> > cache configuration. I do not even want to know what "memory policy" is.
> > E.g. CacheConfiguration.persistenceEnabled.
> >
> > On Tue,
user still can get exceptions.
2017-09-12 12:44 GMT+03:00 Vladimir Ozerov :
> Alex,
>
> Can we have two default memory policies - one for in-memory and another one
> for persistence cases?
>
> On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.c
e with persistence - reuse cloned policy
>
> etc etc.
>
> We can think of CacheConfiguration.persistenceEnabled as an override.
>
> On Tue, Sep 12, 2017 at 12:57 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > We surely can, but:
> > * we s
Vladimir,
Can you please clarify how the proposed API will work?
My opinion is that our query API is big piece of ... you know, especially
> ContinuousQuery. A lot of concepts and features are mixed in a single
> entity, what makes it hard to understand and use. Let's finally deprecate
> Continuo
Yakov,
The default=true will be used only if the PersistentStoreConfiguration is
set in the IgniteConfiguration, this is done only to maintain configuration
compatibility.
A user is allowed to use persisted and in-memory caches, he will be only
forced to put them into separate memory policies.
2
ryPolicy or
> > PersistentMemoryPolicy, but not both. By default, caches on startup are
> > associated with default MemoryPolicy. Users can always change it to some
> > PersistentMemoryPolicy, if persistence needs to be enabled.
> >
> > If we agree on the above, do we r
Vladimir,
The configuration would look like so:
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setMemoryConfiguration(new MemoryConfiguration()
.setMemoryPolicies(
new MemoryPolicyConfiguration().setName("InMemory").setMaxSize(...),
new
PersistentMemoryPolicyConfig
Vladimir,
I doubt it will be possible to add any meaningful guarantees to ATOMIC
caches with MVCC. Consider a case when a user does a putAll, not a single
put. In this case, updates received by multiple primary nodes are not
connected in any way. Moreover, whenever a primary node fails, the put fo
>
> I agree that we need coordinator nodes, but I do not understand why can't
> we reuse some cache nodes for it? Why do we need to ask user to start up
> yet another type of node?
>
Dmitriy,
My understanding is that Semyon does not deny a cache node to be used as a
coordinator. This property wil
I think the protocol should allow both, and the behavior should be either
configurable or enabled via a system property. Every web server known to me
allows exposing this information for debugging purposes.
2017-09-19 10:20 GMT+03:00 Vladimir Ozerov :
> Igniters,
>
> We had a discussion about how
301 - 400 of 1062 matches
Mail list logo
