Re: iep-6 metrics ticket review

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? > >>> > >>> Sincerely, > >>> Dmitriy Pavlov > >>> >

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

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

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 <dpavlov@gmail.com> написал(а): > > Hi, is this removal implemented for transactional cache? > > ср, 28 мар. 2018 г. в 19:49, Aleksey Kuznetsov <alkuznetsov...@gmail.com>: > >

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

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

> Note, that 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! > > > &

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

usedCommentId=16069655=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 > > transa

[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

Re: IGNITE-5714 Context switching for pessimistic transactions

ite 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,

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

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

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

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

Alexey first. > > --Yakov > > 2018-01-22 2:02 GMT-08:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > >> Sure >> >> пн, 22 янв. 2018 г. в 12:25, Andrey Gura <ag...@apache.org>: >> >>> It seems that problem isn't related with dea

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

al reproducer? > > 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 unab

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

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

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

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

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 <alkuznetsov...@gmail.com>: > Hi, Igntrs! > > I’m working on

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

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

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 <dsetrak...@apache.org>: > On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV < > alkuznets

Re: Context switching for pessimistic transactions

of > the code internals. > > 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

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 <dma...@apache.org>: > 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

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 <alkuznetsov...@gmail.com>

Re: IGNITE-5714 Context switching for pessimistic transactions

t; > --AG > > 2017-08-11 17:52 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > Hi! > > There is GridCacheTxFinishSync synchronizer, which used to notify threads > > (waiting on GridCacheTxFinishSync.TxFinishSync#pendingFut) > >

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

Re: IGNITE-5714 Context switching for pessimistic transactions

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

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

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 <isap...@gridgain.com>: > Why would you like to delete it? > > You can close it if it's not actual. > > Best Regards, > Igor > > On Fri, Jul 14, 2017

delete upsource review

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

Re: abbrevation rules plugin

ns) into AI code base. > 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? >

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

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

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

? I think this is the scope of the > original one. > > --Yakov > > 2017-07-03 16:39 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > I've go a test, which illustrates transaction commit fail when multiple > > threads try to commit. As i said, it happen

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

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 <alkuznetsov...@gmail.com>: > Consider thread *Th1* started transaction *Tx1*, done some actions, and > is calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And > concur

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 <alkuznetsov...@gmail.com>: > Thanks! Do you think all test scenarios results, presented in table(in > ticket comments) , are acceptable ? > > пт, 30 июн. 2017 г., 1

Support for starting transaction in another thread IGNITE-4887

hich would lead to exception. So, there is no locking sections (mutex) here -- Forwarded message - From: Yakov Zhdanov <yzhda...@apache.org> Date: пн, 3 июл. 2017 г. в 14:16 Subject: Re: Support for starting transaction in another thread IGNITE-4887 To: ALEKSEY KUZNETSOV <alkuznet

Re: distributed transaction of non-single coordinator

irector R > *GridGain Systems* > www.gridgain.com > > 2017-06-29 17:27 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > I've attached HangTest. I suppose it should not hang, am i right ? > > > > чт, 29 июн. 2017 г. в 14:54, ALEKSEY KUZNETSOV <alkuzne

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 <alkuznetsov...@gmail.com>: > Igntrs. > Im rewieving all usages of threadId of > transaction.(IgniteTxAdapter#threadID). What is the point of usage threadId > in m

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 <alkuznetsov...@gmail.com>: > so what do u think on my idea? > > пт, 31 Мар 2017 г., 11:05 AL

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

> Best Regards, > Dmitry Pavlov > > пт, 23 июн. 2017 г. в 22:17, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > Yeah, it can be set "Patch available" because I need smbd to review it > > > > пт, 23 июн. 2017 г., 21:06 Dmitry Pavlov <dpavlov.

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

cerely, > Dmitry Pavlov > > > > ср, 7 июн. 2017 г. в 17:03, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > Hi, Igntrs! > > Feel free to reviewing the ticket > > https://issues.apache.org/jira/browse/IGNITE-1553 > > https://github.com

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)

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

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

d commit it after reads. A commit will > throw OptimisticException if you happen to read an inconsistent set of > values. > > 2017-05-31 19:57 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > one possible solution is to lock entry reading section while userCommit(

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 <alkuznetsov...@gmail.com>: > Hi, Igntrs! > When the first writer thread has commited values and cache entries are > getting updated with

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

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 <alkuznetsov...@gmail.com>: > 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 <alexe

Re: waiting for partition release question

un this test on repeat locally to see how easy it is to > reproduce this. > > 2017-05-19 14:54 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > How could i reproduce the issue ? > > > > пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <alkuznetsov...@gm

Re: waiting for partition release question

How could i reproduce the issue ? пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > Ok, i pick it > > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <alexey.goncha...@gmail.com>: > >> Well, >> >> I don't have any clear plan for

Re: waiting for partition release question

5-19 12:52 GMT+03:00 Дмитрий Рябов <somefire...@gmail.com>: > > > 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 <alkuznetsov...@gmail.com>: >

Re: waiting for partition release question

k. > > We will be adding documentation 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 <alkuznetsov...@gmail.com>: > > > Hi Igntrs

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

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*

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

On Thu, May 4, 2017 at 2:19 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> > wrote: > > > Hello, Igntrs! > > When node dinamically creates new cache it sends > > GridDhtPartitionsSingleMessage to coordinator so partition maps got > redone. > > Why

Re: partitions exchange protocol details question

GridDhtPartitionsSingleMessage with the same exchangeId? What is the scenario of this situation чт, 4 мая 2017 г. в 14:45, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > Thank you! > > чт, 4 мая 2017 г. в 12:25, Dmitry Pavlov <dpavlov@gmail.com>: > >> Thank you for clarifica

Re: partitions exchange protocol details question

s determined by > original event caused this exchange (e.g. node left, node joined, node > failed) for current topology version. > > > чт, 4 мая 2017 г. в 11:32, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > I know this. > > But the question was as follows. > >

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

en coordinator receives 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 <alkuznetsov...@gmail.com

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

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

gistered. > > Alex 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 solut

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

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

Re: need new ticket

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

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 <alkuznetsov...@gmail.com>: > Yeah. I've already run the test with two caches. Definately, the bug > hidden in cache.query

Re: cache query operations

e, SELECT queries are executed right away by H2 while DML are > eventually converted to key-value operations. > > — > Denis > > > On Apr 18, 2017, at 1:29 AM, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com> > wrote: > > > > if executing sql "select"

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

the following without computations 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 outp

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

Re: cache query operations

ignite.readme.io/docs/dml#dml-operations> > > — > Denis > > > On Apr 17, 2017, at 7:20 AM, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com> > wrote: > > > > Hi, Igniters! When one fires query like this : ignite().cache(null > > ).query(...) > &g

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

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

while someone else fixes > it. > > — > Denis > > > On Apr 14, 2017, at 1:33 AM, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com> > wrote: > > > > Because expiry time is 10 seconds, while loop iterates every 5 seconds > > > > пт, 14 апр. 2017 г. в 11:

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

Because expiry time is 10 seconds, while loop iterates every 5 seconds пт, 14 апр. 2017 г. в 11:32, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > No, the bug is in SQL query, not key-value storage. > > пт, 14 апр. 2017 г. в 11:11, Vladislav Pyatkov <vldpyat...@gmail.com>

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

queries return an empty result set as expected > but > > something doesn’t work well with key-value operations. > > > > *Denis K*, *Vlad P.*, as creators of the ticket please confirm that this > > is the case. > > > > Please keep debugging this and switch to

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

any feedback? чт, 13 апр. 2017 г. в 11:51, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > You should run ExpiryPolicyTest. The output should contain strings like > contains? new AffinityKey("1", "1"): and contains?2 new AffinityKey("1", " >

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

gnite.test.EDU@7cd1ac19 > SQL res: [] > 0 > Op consume: 5 > > Please be more specific, there are too many files in the code. > > — > Denis > > > On Apr 12, 2017, at 4:50 AM, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com> > wrote: > > > > So what do u thin

  1   2   3   >