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: 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: 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: 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 пишет: > &

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

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*

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

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: 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

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: [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

[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 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 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

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

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

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

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

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

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*

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

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: 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: 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

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

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

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

> 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

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: 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*

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

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: 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

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

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

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

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: 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

delete upsource review

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

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 > > &

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: 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

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

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

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

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: 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 : >

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

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

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

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: 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: 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*

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

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*

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 : > > > > >

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*

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*

Configuration inconsistency IGNITE-896

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

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

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

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

transaction rollback on only node

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

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*

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

Re: waiting for partition release question

cally to see how easy it is to > reproduce this. > > 2017-05-19 14:54 GMT+03:00 ALEKSEY KUZNETSOV : > > > How could i reproduce the issue ? > > > > пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV >: > > > > > Ok, i pick it > > > > >

Re: waiting for partition release question

How could i reproduce the issue ? пт, 19 мая 2017 г. в 14:52, ALEKSEY 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,

Re: waiting for partition release question

This > issue bugs us on TC, it is pretty important and there is quite enough > understanding on what 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

Re: waiting for partition release question

gt; > May be let second node to finish join and enter the ring, but start > > rebalance after all lock will be released. > > > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV : > > > > > If we acquired a lock and a new node is joining cluster, should it wait > &g

Re: waiting for partition release question

entation pages on Apache Ignite wiki which will > explain transactions mechanics in greater detail. > > Hope this helps, > AG > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV : > > > Hi Igntrs! > > What is the point of waiting partition release in the end of > &

waiting for partition release question

Hi Igntrs! What is the point of waiting partition release in the end of GridDhtPartitionsExchangeFuture#init() method ? In what scenarious do we need it ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: Minimize amount of inner classes, predicates, tuples, etc

yeah, good proposal! In addition i would suggest start adding more javadocs on current code ср, 17 мая 2017 г. в 11:08, Vladimir Ozerov : > Vyacheslav, > > When you analyze code full of generic stuff like tuples and closures, it is > much harder to understand what is going on and navigate the cod

IGNITE-2671 Node cannot join topology when cache lock is held.

Hi, Igntrs! Im working on https://issues.apache.org/jira/browse/IGNITE-2671 . What is desirable behaviour ? When new node joins topology, it got changed, so should we ignore key lock in this scenario? -- *Best Regards,* *Kuznetsov Aleksey*

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 * -- *Best Regards,* *Kuznetsov Aleksey* -- *Best Regards,* *Kuznetsov Aleksey*

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 * -- *Best Regards,* *Kuznetsov Aleksey* -- *Best Regards,* *Kuznetsov Aleksey*

Re: IGNITE-1401 Introduce special local node discovery events

gt; > I'll close the ticket as "Won't Fix". > > On Fri, May 5, 2017 at 2:44 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> > wrote: > > > Hello Igntrs! > > I would like to start working on > > https://issues.apache.org/jira/bro

IGNITE-2671 Node cannot join topology when cache lock is held.

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

IGNITE-1401 Introduce special local node discovery events

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

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 * -- *Best Regards,* *Kuznetsov Aleksey*

Re: dynamic cache creation question

Well, for me its not obvious. The point is - why do we need to send it ? чт, 4 мая 2017 г. в 18:54, Dmitriy Setrakyan : > Alexey, > > I am not sure I understand the question. This message is obviously > necessary. Can you clarify? > > D. > > On Thu, May 4, 2017 at 2:

Re: partitions exchange protocol details question

GridDhtPartitionsSingleMessage with the same exchangeId? What is the scenario of this situation чт, 4 мая 2017 г. в 14:45, ALEKSEY KUZNETSOV : > Thank you! > > чт, 4 мая 2017 г. в 12:25, Dmitry Pavlov : > >> Thank you for clarification. >> >> All Single Message will have same exchange

Re: partitions exchange protocol details question

caused this exchange (e.g. node left, node joined, node > failed) for current topology version. > > > чт, 4 мая 2017 г. в 11:32, ALEKSEY KUZNETSOV : > > > I know this. > > But the question was as follows. > > Imagine, remaining set contains 2 nodes. It implies that bot

dynamic cache creation question

Hello, Igntrs! When node dinamically creates new cache it sends GridDhtPartitionsSingleMessage to coordinator so partition maps got redone. Why it sends the message after cache creation? -- *Best Regards,* *Kuznetsov Aleksey*

Re: partitions exchange protocol details question

single partition message ( > GridDhtPartitionsSingleMessage), it removes one node from remaining set. > The same is true for node left message. > > Best Regards, > Dmitry Pavlov > > ср, 3 мая 2017 г. в 19:10, ALEKSEY KUZNETSOV : > > > Hi, Igntrs! When processing single par

partitions exchange protocol details question

Hi, Igntrs! When processing single partitions message in GridDhtPartitionsExchangeFuture#processMessage() then , coordinator could answer with GridDhtPartitionsFullMessage from sendAllPartitions. But the field GridDhtPartitionsExchangeFuture#remaining must be empty in this case. I wounder, how cou

Re: Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization Ignite-1049

So, any thoughts? пт, 28 апр. 2017 г. в 16:54, ALEKSEY KUZNETSOV : > validation must have involve calling StoreFactory.create() . So we create > store at first? > > If so, should we notify coordinator and other nodes about bad cache ? > Perhaps, initiating node should thro

Re: Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization Ignite-1049

ex G., Semen, > What do you think? > > On Fri, Apr 28, 2017 at 12:36 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> wrote: > > > Hi, Igntrs! > > https://issues.apache.org/jira/browse/IGNITE-1094 > > > > I've come up with solution. Put exception

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

Hi, Igntrs! https://issues.apache.org/jira/browse/IGNITE-1094 I've come up with solution. Put exception into GridDhtPartitionsSingleMessage indicating cache creation failed on local node. Send it to coordinator. Coordinator's GridCachePartitionExchangeManager while processing would extract exchang

New node verification

hi, Igntrs! when coordinator receives TcpDiscoveryNodeAddedMessage, it mark message as verified. What for ? -- *Best Regards,* *Kuznetsov Aleksey*

joining exchange

Hi, Igntrs! When new node joins topology, it sends join TcpDiscoveryJoinRequestMessage to arbitrary node N1. If N1 is not coordinator, then it will resend to all nodes. Why doesn't N1 send the message directly to coordinator ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: "Apache Ignite University”

great idea пт, 21 апр. 2017 г. в 2:20, Denis Magda : > Sounds good to me. > > — > Denis > > > On Apr 20, 2017, at 1:35 PM, Tom Diederich > wrote: > > > > I’d also like to propose an enhancement to the community that I believe > would be helpful to new and experienced Igniters alike: "Apache Igni

Re: need new ticket

5037 > > — > Denis > > > On Apr 19, 2017, at 4:01 PM, Denis Magda wrote: > > > > Hi Aleksey, > > > > This is what I could select quickly: > > https://issues.apache.org/jira/browse/IGNITE-2092 > > https://issues.apache.org/jira/browse/IGNITE-4763 >

tcp discovery message exchange

Hi, Igniters! I have a question. What is the purpoise of coordinator sending TcpDiscoveryNodeAddedMessage to every node? We could have just sent TcpDiscoveryNodeAddFinishedMessage instead. -- *Best Regards,* *Kuznetsov Aleksey*

need new ticket

Hello, Igniters! Are there any non-complicated ticket ? Regarding transactions, prefferebly. -- *Best Regards,* *Kuznetsov Aleksey*

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

I wonder if "SELECT" clause should *touch *an entry? For instance, cache.contains() doesn't *touch*. вт, 18 апр. 2017 г. в 12:21, ALEKSEY KUZNETSOV : > Yeah. I've already run the test with two caches. Definately, the bug > hidden in cache.query() method. cache.query(

Re: cache query operations

ted right away by H2 while DML are > eventually converted to key-value operations. > > — > Denis > > > On Apr 18, 2017, at 1:29 AM, ALEKSEY KUZNETSOV > wrote: > > > > if executing sql "select" clause then no cache key-value operations would > >

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

mputations and other redundant stuff. > Would you like to work on this? > > — > Denis > > > On Apr 17, 2017, at 12:44 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> wrote: > > > > Why do u think so. > > First of all, the output above is not correct

Re: cache query operations

if executing sql "select" clause then no cache key-value operations would be called. Debbuging cache.query(...) leads to org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#executeSqlQuery which doesnt call cache key-value ops вт, 18 апр. 2017 г. в 10:49, ALEKSEY KUZNETSOV

Re: cache query operations

#dml-operations> > > — > Denis > > > On Apr 17, 2017, at 7:20 AM, ALEKSEY KUZNETSOV > wrote: > > > > Hi, Igniters! When one fires query like this : ignite().cache(null > > ).query(...) > > The query would be executed against the schema. I wonder, how

cache query operations

Hi, Igniters! When one fires query like this : ignite().cache(null ).query(...) The query would be executed against the schema. I wonder, how the schema is synchronized with cache, with cache entries? What i mean is , cache.query(...update operation...) must eventually update the cache entry in ca

  1   2   3   >