Re: waiting for partition release question

oh, i've found пт, 19 мая 2017 г. в 15:34, ALEKSEY KUZNETSOV : > Don't you remember the day the test last failed?) Im trying to find it in > history of TC. Locally it doesn't fail > > пт, 19 мая 2017 г. в 14:56, Alexey Goncharuk : > >> GridCacheContinuousQu

IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

Igntrs! Plz, review my changes https://issues.apache.org/jira/browse/IGNITE-1094 *https://github.com/apache/ignite/pull/1904 * (preferrably review here) http://reviews.ignite.apache.org/ignite/review/IGNT-CR-181 -- *Best Regards,* *Kuznetsov Aleksey*

transaction rollback on only node

Hi, Igntrs! Is it make sense transaction on cluster of only node to rollback? -- *Best Regards,* *Kuznetsov Aleksey*

Cache.getAll can return partially commited results. IGNITE-4809

Hi, Igntrs! When the first writer thread has commited values and cache entries are getting updated with this new values, another thread is getting partially assigned values through the cache.getAll(keys) should this method wait for all newly updated entries to finish , or should it throw the exce

Re: Cache.getAll can return partially commited results. IGNITE-4809

one possible solution is to lock entry reading section while userCommit() method is executing. ср, 31 мая 2017 г., 16:52 ALEKSEY KUZNETSOV : > Hi, Igntrs! > When the first writer thread has commited values and cache entries are > getting updated with this new values, another thread i

Re: Cache.getAll can return partially commited results. IGNITE-4809

; throw OptimisticException if you happen to read an inconsistent set of > values. > > 2017-05-31 19:57 GMT+03:00 ALEKSEY KUZNETSOV : > > > one possible solution is to lock entry reading section while userCommit() > > method is executing. > > > > ср, 31 мая 2017

Configuration inconsistency IGNITE-896

Will start working on the ticket if nobody mind -- *Best Regards,* *Kuznetsov Aleksey*

Optimize transaction prepare step when store is enabled IGNITE-1553

Will start working on ticket https://issues.apache.org/jira/browse/IGNITE-1553 if nobody mind -- *Best Regards,* *Kuznetsov Aleksey*

Optimize transaction prepare step when store is enabled IGNITE-1553

Hi, Igntrs! Feel free to reviewing the ticket https://issues.apache.org/jira/browse/IGNITE-1553 https://github.com/apache/ignite/pull/2091 -- *Best Regards,* *Kuznetsov Aleksey*

Re: [DISCUSS] Webinar for Ignite Persistent Store walk-through

plus one вт, 13 июн. 2017 г. в 14:26, Anton Vinogradov : > +1 > > On Tue, Jun 13, 2017 at 2:21 PM, Kozlov Maxim > wrote: > > > +1 > > > > > 13 июня 2017 г., в 14:14, Vyacheslav Daradur > > написал(а): > > > > > > +1 (I will attend) > > > > > > 2017-06-13 6:35 GMT+03:00 Roman Shtykh : > > > > >

IGNITE-9 Need to implement IngniteReentrantReadWriteLock

Hello Igntrs! I would like to start working on *https://issues.apache.org/jira/browse/IGNITE-9 * if you don't mind. -- *Best Regards,* *Kuznetsov Aleksey*

cannot build ignite 2.1.0

Cannot build apache ignite 2.1.0 package. Build fails on ignite-hadoop module : Could not find artifact org.apache.ignite:ignite-core:jar:2.1.0-SNAPSHOT in h2database.com (http://h2database.com/m2-repo) http://h2database.com/m2-repo/org/apache/ignite/ignite-core/2.1.0-SNAPSHOT/ignite-core-2.1.0-SN

Re: Optimize transaction prepare step when store is enabled IGNITE-1553

t; Dmitry Pavlov > > > > ср, 7 июн. 2017 г. в 17:03, ALEKSEY KUZNETSOV : > > > Hi, Igntrs! > > Feel free to reviewing the ticket > > https://issues.apache.org/jira/browse/IGNITE-1553 > > https://github.com/apache/ignite/pull/2091 > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > -- *Best Regards,* *Kuznetsov Aleksey*

Re: Optimize transaction prepare step when store is enabled IGNITE-1553

Dmitry Pavlov > > пт, 23 июн. 2017 г. в 22:17, ALEKSEY KUZNETSOV : > > > Yeah, it can be set "Patch available" because I need smbd to review it > > > > пт, 23 июн. 2017 г., 21:06 Dmitry Pavlov : > > > > > Hi Alexey, > > > > >

Re: distributed transaction of non-single coordinator

Igntrs. Im rewieving all usages of threadId of transaction.(IgniteTxAdapter#threadID). What is the point of usage threadId in mvcc entry ? пн, 3 апр. 2017 г. в 9:47, ALEKSEY KUZNETSOV : > so what do u think on my idea? > > пт, 31 Мар 2017 г., 11:05 ALEKSEY KUZNETSOV : > >> so

Re: distributed transaction of non-single coordinator

I've attached HangTest. I suppose it should not hang, am i right ? чт, 29 июн. 2017 г. в 14:54, ALEKSEY KUZNETSOV : > Igntrs. > Im rewieving all usages of threadId of > transaction.(IgniteTxAdapter#threadID). What is the point of usage threadId > in mvcc entry ? > > пн

Re: distributed transaction of non-single coordinator

ms* > www.gridgain.com > > 2017-06-29 17:27 GMT+03:00 ALEKSEY KUZNETSOV : > > > I've attached HangTest. I suppose it should not hang, am i right ? > > > > чт, 29 июн. 2017 г. в 14:54, ALEKSEY KUZNETSOV >: > > > > > Igntrs. > > > Im rewie

Support for starting transaction in another thread IGNITE-4887

lead to exception. So, there is no locking sections (mutex) here -- Forwarded message - From: Yakov Zhdanov Date: пн, 3 июл. 2017 г. в 14:16 Subject: Re: Support for starting transaction in another thread IGNITE-4887 To: ALEKSEY KUZNETSOV Alex, what do you mean by "mult

Re: distributed transaction of non-single coordinator

Yakov, I have couple of questions regarding tests proposal.Thx пт, 30 июн. 2017 г. в 19:17, ALEKSEY KUZNETSOV : > Thanks! Do you think all test scenarios results, presented in table(in > ticket comments) , are acceptable ? > > пт, 30 июн. 2017 г., 18:28 Yakov Zhdanov : >

abbrevation rules plugin

Igntrs! There is a plugin , mentioned in Abbreviation Rules page that performs on-the-fly check.Is somebody going to add it some day? -- *Best Regards,* *Kuznetsov Aleksey*

Re: Support for starting transaction in another thread IGNITE-4887

Lock is put by cache adapter. Now its clear пн, 3 июл. 2017 г. в 15:14, ALEKSEY KUZNETSOV : > Consider thread *Th1* started transaction *Tx1*, done some actions, and > is calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And > concurrently thread *Th2 *is calling the

Re: Support for starting transaction in another thread IGNITE-4887

I've go a test, which illustrates transaction commit fail when multiple threads try to commit. As i said, it happenes in mvcc stage. So we should create a special lock mechanism for all transaction methods. In a separate ticket. пн, 3 июл. 2017 г. в 16:26, Yakov Zhdanov : > >Consider thread *Th1

Re: Support for starting transaction in another thread IGNITE-4887

e of the > original one. > > --Yakov > > 2017-07-03 16:39 GMT+03:00 ALEKSEY KUZNETSOV : > > > I've go a test, which illustrates transaction commit fail when multiple > > threads try to commit. As i said, it happenes in mvcc stage. > > > > So we sho

Re: Support for starting transaction in another thread IGNITE-4887

So i need to put new lock mechanism to* all* transaction operations ? If so, don't we need additional ticket for this ?(for example sub ticket for my original one) пн, 3 июл. 2017 г. в 16:59, Yakov Zhdanov : > Disagree. Currently transaction is bound to a thread and if user tries to > pass it ove

Re: Support for starting transaction in another thread IGNITE-4887

So, desired behavior is the following: when some thread evaluates tx operation's secured scope, other threads should be locked and then released with return after first thread has finished evaluating secured scope ? пн, 3 июл. 2017 г. в 17:12, Yakov Zhdanov : > Yes, feel free to file a sub-ticket

Re: abbrevation rules plugin

ase. > Thoughts? > > Sincerely, > Dmitriy Pavlov > > вт, 4 июл. 2017 г. в 1:29, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > The plugin actually exists, not sure why it's not attached. Does anyone > has > > it? > > > > -Val > > &

delete upsource review

Igntrs! Do smbd know how to delete upsource review ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: delete upsource review

if request is pollutted by comments, and i just want to get rid of them. пт, 14 июл. 2017 г. в 16:40, Igor Sapego : > Why would you like to delete it? > > You can close it if it's not actual. > > Best Regards, > Igor > > On Fri, Jul 14, 2017 at 11:52 AM, ALEK

IGNITE-5714 Context switching for pessimistic transactions

Hi, Igntrs! Currently we have context switching implemented for optimistic transactions : https://issues.apache.org/jira/browse/IGNITE-5712. So, the next step is to implement it for pessimistic transactions : https://issues.apache.org/jira/browse/IGNITE-5714 The problem with them lies in *Ig

Re: IGNITE-5714 Context switching for pessimistic transactions

s the synchronizer is useless. Do we really need to keep GridCacheTxFinishSync in a project? ср, 9 авг. 2017 г. в 17:13, ALEKSEY KUZNETSOV : > Hi, Igntrs! > > Currently we have context switching implemented for optimistic > transactions : https://issues.apache.org/jira/browse/IGNITE-5712

The reason behind locking backup copy

Hi, Igntrs! Consider primary node P, backup node B for some key1. When we create lock on this key (at primary node) : IgniteCache primaryCache = primaryIgnite.cache(DEFAULT_CACHE_NAME); primaryCache.lock("key1").lock() After lock acquired on primary node, the GridCacheMvccCandidate would be crea

Re: IGNITE-5714 Context switching for pessimistic transactions

ridCacheTxFinishSync uses the synchronizer(but doesn't > > wait on it somehow). And it seems the synchronizer is useless. Do we > really > > need to keep GridCacheTxFinishSync in a project? > > > > > > > > ср, 9 авг. 2017 г. в 17:13, ALEKSEY

Re: IGNITE-5714 Context switching for pessimistic transactions

The problem is that GridCacheTxFinishSync stores thread id. When we call suspend on transaction, old thread id becames incorrect. So if this sync class is useless, we can eliminate thread id storage and this class. чт, 17 авг. 2017 г. в 15:47, ALEKSEY KUZNETSOV : > I cannot find\create

HOLE query entry in CacheContinuousQueryPartitionRecovery

Hi, Ignters! We have a strange field HOLE in CacheContinuousQueryPartitionRecovery which compared to pending events in CacheContinuousQueryPartitionRecovery#collectEntries. And it is never equals any entry. Do we need it ? Or it can be removed. -- *Best Regards,* *Kuznetsov Aleksey*

Re: HOLE query entry in CacheContinuousQueryPartitionRecovery

, Denis Magda : > I like the name. "Black holes" pop up first in my head :) The hole can > absorb events and confine and digest them for billions of year. Sorry for > off topic. > > — > Denis > > > > On Sep 15, 2017, at 10:14 AM, ALEKSEY KUZNETSOV < &g

Re: Ignite Enhancement Proposal process

great suggestion вт, 19 сент. 2017 г. в 14:31, Yakov Zhdanov : > Vladimir, I like the suggestion. We should definitely try it. > > --Yakov > -- *Best Regards,* *Kuznetsov Aleksey*

Context switching for pessimistic transactions

Hi, Igntrs! I’m working on a ticket "Context switching for pessimistic transactions" [1]. Goal of the ticket is to support transaction suspend()\resume() operations for pessimistic transactions. Resume can be called in another thread. Imagine, we started pessimistic transaction in thread T1 and

Re: Context switching for pessimistic transactions

> Perhaps it is best to summarize your thoughts in the ticket, before you > start the implementation. If no one in the community has any feedback, then > you can take a first crack at the code and submit a pull request. > > D. > > > On Mon, Oct 2, 2017 at 3:49 PM, ALEKSEY

Re: Context switching for pessimistic transactions

changing (e.g. start new node in the same thread) would wait transaction to be resumed and finished. Do you think it’s an appropriate behavior? пт, 13 окт. 2017 г. в 5:06, Dmitriy Setrakyan : > On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > >

Re: Context switching for pessimistic transactions

n logic on nodes. I prefer 1 option. Thoughts ? [1] https://issues.apache.org/jira/browse/IGNITE-5714 пн, 23 окт. 2017 г. в 15:35, ALEKSEY KUZNETSOV : > Hi, Igntrs! > > I would like to implement suspend\resume methods of a pessimistic > transaction as following: > > if tra

Incorrect transaction state when client node reconnects

Hi, Igntrs! Client reconnect cause transactions rollback in IgniteTxManager#onDisconnected. But it doesn’t change transaction state to ROLLING_BACK and ROLLED_BACK. Thus every transaction, after client node reconnects, has got ACTIVE status, which seems incorrect. I added PR where you can find

Re: Context switching for pessimistic transactions

<https://issues.apache.org/jira/browse/IGNITE-5714>* [2] *https://github.com/apache/ignite/pull/2789 <https://github.com/apache/ignite/pull/2789>* ср, 1 нояб. 2017 г. в 14:53, ALEKSEY KUZNETSOV : > Hi, Igntrs! > > I’m working on a ticket "Context switching for pess

Entries are not loaded into cache during cache store loading

Hi, Igniters! During test bug fixing [1], I stumbled on the following issue: When we perform cache store loading and start several nodes simulateneously, some entries might not be loaded into cache. Entry is loaded in `GridDhtCacheAdapter#loadEntry`, but it fails on `ctx.group().topology().localP

Re: Entries are not loaded into cache during cache store loading

Hi, Nikolay. Yes. вт, 19 июн. 2018 г. в 13:18, Nikolay Izhikov : > Hello, Aleksey. > > By "cache store" you mean 3-d party cache store [1] ? > > https://apacheignite.readme.io/docs/3rd-party-store > > В Вт, 19/06/2018 в 13:10 +0300, Aleksey Kuznetsov пишет: > &

Re: Optimistic mode with serializable vs read_committed

All optimistic transactions on prepare phase (step 11) create tx instance GridDhtTxLocal. Try to lock keys on this step and if succeed then prepare phase is continued. On this step transaction context got created and keys are put into it for futher committing. Additionally, cluster version is cheke

Re: iep-6 metrics ticket review

my plate, will try to take a look this week. > > -Val > > On Mon, Apr 9, 2018 at 10:28 AM, Denis Magda wrote: > > > Val, > > > > As an initial reviewer and reporter, could you have a look and sign the > > contribution off? > > > > -- > >

Re: iep-6 metrics ticket review

agreed change is good, but we'd like to be absolutely sure there > >>> is no performance drop. Dmitriy G. was one from reviewer, so I hope he > >>> would provide any additional info about change. > >>> > >>> Could you please assist here? > >&

Re: Transaction classes naming

for renaming +1 > 21 дек. 2017 г., в 5:25, Dmitriy Setrakyan написал(а): > > Will this renaming introduce any issues with supporting previous versions? > >> On Wed, Dec 20, 2017 at 9:10 AM, Yakov Zhdanov wrote: >> >> How about we explain it in javadocs and properly document on wiki? Guys, I

Re: How to handle CacheLocalStore on clients node?

CacheLocalStore annotation means CacheStore is not "global" database, but each node has its independent db. If CacheStore isn't annotated with CacheLocalStore, then you can observe situation when data is persisted by node, which is neither primary, nor backup for the key.(i.e. we have transactional

Re: Scala 2.10 support

+1 ср, 10 янв. 2018 г. в 17:28, Alexey Kuznetsov : > +1 > > On Wed, Jan 10, 2018 at 7:27 PM, Nikolay Izhikov > wrote: > > > +1 from me. > > > > В Ср, 10/01/2018 в 05:24 -0700, vveider пишет: > > > Hi, Igniters! > > > > > > > > > While working on Java 9 support adaptation, came to a problem with

review Rework exception handling in suspend()\resume() methods

Hello, Igntrs! Could you plz review the ticket [1], upsource : [2] [1]: https://issues.apache.org/jira/browse/IGNITE-7409 [2]: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-463 -- *Best Regards,* *Kuznetsov Aleksey*

cache operation failed after transaction rolled back due to deadlock

Hi, Igntrs! When you have your transaction rolled back due to detected deadlock, you are unabled to perform cache operations (in thread where tx was started and rolled back), because it leads to TransactionTimeoutException. The reason of such behavior is that tx thread map (txManager#threadMa

Re: cache operation failed after transaction rolled back due to deadlock

> 19 янв. 2018 г. 3:55 PM пользователь "ALEKSEY KUZNETSOV" < > alkuznetsov...@gmail.com> написал: > > > Hi, Igntrs! > > > > > > > > When you have your transaction rolled back due to detected deadlock, you > > are unabled to perform cache

Re: cache operation failed after transaction rolled back due to deadlock

t; --Yakov > > 2018-01-22 2:02 GMT-08:00 ALEKSEY KUZNETSOV : > >> Sure >> >> пн, 22 янв. 2018 г. в 12:25, Andrey Gura : >> >>> It seems that problem isn't related with deadlock detection and should be >>> reproducible when deadlock det

Backup node crash causes incorrect transaction failover recovery

Hi, Igntrs! While testing transaction failover recovery mechanisms I came across a bug. When we have multiple consequent transactions changing the same key and backup node crashes during prepare phase, not all changes are applied. This bug is flaky and arises only if there are 2 or more conseq

IGNITE-7409 Rework exception handling in suspend()\resume() methods

Hi, Igntrs! When user misuses transactions, one could get assertion error. Currently, when we start optimistic transaction, do some work within it and try to resume it(which is incorrect behavior) assertion error is thrown. It looks weird. On the contrary more descriptive exception should be throw

IGNITE-5714 Context switching for pessimistic transactions

Hi, Igniters! Currently we have context switching implemented for optimistic transactions [1]. Goal of the current ticket is to support transaction suspend()\resume() operations for pessimistic transactions. The essential problem with them lies in *IgniteTxAdapter#threadId*. Thread id is se

Re: IGNITE-5714 Context switching for pessimistic transactions

e little more about your implementation > > 1. Design of implementation. > > 2. Advantages of you implementation in compare with other ways? > > 3. Transactions performance penalties/improvements? > > В Вт, 13/02/2018 в 14:17 +, ALEKSEY KUZNETSOV пишет: > > Hi, Igniters! > &

[IGNITE-5714] Design proposal of suspend/resume for pessimistic tx

Hello Igniters! Currently we have suspension/resuming implemented for optimistic transactions [1]. Unless suspend/resume isn't supported for pessimistic tx JTA isn't fully supported [4]. I’m working on a ticket "Suspension/resuming for pessimistic transactions" [2]. Goal of the ticket is to suppo

Re: [IGNITE-5714] Design proposal of suspend/resume for pessimistic tx

9655&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16069655 > > В Пн, 26/02/2018 в 10:59 +, Aleksey Kuznetsov пишет: > > Hello Igniters! > > > > Currently we have suspension/resuming implemented for optimistic > > transaction

Re: [IGNITE-5714] Design proposal of suspend/resume for pessimistic tx

at if user suspends transaction and forgets to resume it, > > transaction would be rolled back once timeout has occurred. > > Do we have tests for this feature? > > В Ср, 28/02/2018 в 10:29 +, Aleksey Kuznetsov пишет: > > Thanx for the answer! > > > > > Can we remo

Re: Server stores cache data on-heap if client has near cache - IGNITE-4662

When client node performs get it stores information about itself on server node, so-called 'reader'. If another node updates cache entry, server node uses 'reader' info(because it tracks client info) to find client and update cache entry in client's near cache. PS. obviously, there may be plent

Near cache entry removal

Hi, Igniters! Currently, in atomic cache after we perform remove , GridNearCacheEntry still exists on 'reader' nodes. Why don't we remove it ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: Near cache entry removal

Implemented for atomic cache > 28 марта 2018 г., в 20:24, Dmitry Pavlov написал(а): > > Hi, is this removal implemented for transactional cache? > > ср, 28 мар. 2018 г. в 19:49, Aleksey Kuznetsov : > >> Hi, Igniters! >> >> Currently, in

iep-6 metrics ticket review

Hi ,Igniters! Do we still need this ticket, about invoke metrics : [1] ? If yes, than could somebody review it ? If no, should we close this ticket ? [1] : https://issues.apache.org/jira/browse/IGNITE-6846 -- *Best Regards,* *Kuznetsov Aleksey*

<    1   2   3