Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

; it. > > — > Denis > > > On Apr 14, 2017, at 1:33 AM, ALEKSEY KUZNETSOV > wrote: > > > > Because expiry time is 10 seconds, while loop iterates every 5 seconds > > > > пт, 14 апр. 2017 г. в 11:32, ALEKSEY KUZNETSOV >: > > > >> No,

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 : > No, the bug is in SQL query, not key-value storage. > > пт, 14 апр. 2017 г. в 11:11, Vladislav Pyatkov : > >> Denis, Aleksey, >> >> It is co

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

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 the latest Ignite version. > > > > —

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

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

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

1ac19 > 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 > wrote: > > > > So what do u think about the issue ? > > > > ср, 12 апр. 201

incorrect work of IgniteLogger

Igniters! Suppose we have log4j-test.xml as following: ... ... Why damn IgniteLogger doesn't write info logs from TxOptimisticDeadlockDetectionTest class ?!? -- *Best Regards,* *Kuzn

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

So what do u think about the issue ? ср, 12 апр. 2017 г. в 10:42, ALEKSEY KUZNETSOV : > I have already attached simlified version. Shall i simplify it more ? > > вт, 11 апр. 2017 г. в 19:28, Denis Magda : > > Can you attach the simplified version? Just want to avoid a

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

I have already attached simlified version. Shall i simplify it more ? вт, 11 апр. 2017 г. в 19:28, Denis Magda : > Can you attach the simplified version? Just want to avoid any side effects. > > — > Denis > > > On Apr 11, 2017, at 9:14 AM, ALEKSEY KUZNETSOV > wrote: >

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

I took it from https://issues.apache.org/jira/browse/IGNITE-4401 and simplified . See in attached вт, 11 апр. 2017 г. в 19:03, Denis Magda : > Hello, > > Do you have sample code? > > — > Denis > > On Apr 11, 2017, at 2:45 AM, ALEKSEY KUZNETSOV > wrote: > >

transaction , waiting for prepare response

Igniters! If we started transaction, and in phase prepare the primary node doesnt receive GridDhtPrepareResponse then the transaction got stuck for a long time. Why don't we have got timer that causes rollback if transaction time on waiting has expired ? -- *Best Regards,* *Kuznetsov Aleksey*

TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

Hi, igniters! While doing https://issues.apache.org/jira/browse/IGNITE-4401 ticket i came across the fact that cache querying returns null , while cache still has got entry. Cache query : SELECT nameProp FROM EDUProp WHERE EDUId = 1 Cache get operation : ignite().cache("eduPropCache").get(new Affin

Re: one point optimisation

s. You should see the expected number of > messages with near cache disabled. > > 2017-04-05 15:09 GMT+03:00 ALEKSEY KUZNETSOV : > > > yes > > > > ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk >: > > > > > Do you have a near cache enabled? &g

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

how to TouchedExpiryPolicy should be work[1]. > > [1]: > > http://static.javadoc.io/javax.cache/cache-api/1.0.0/javax/cache/expiry/TouchedExpiryPolicy.html > > On Mon, Apr 10, 2017 at 5:48 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > wrote: > > > Fine. So

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

Ah, i see. After 1 round the entity got expired, but it should not пн, 10 апр. 2017 г. в 17:48, ALEKSEY KUZNETSOV : > Fine. So what is the point of this ticket? What is the correct behavior of > the policy? > > пн, 10 апр. 2017 г. в 17:45, Vladislav Pyatkov : > > Aleksey, &g

Re: TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

enteries will never expired in the example, because > its touching each 10 seconds. > > On Mon, Apr 10, 2017 at 5:23 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > wrote: > > > Hello igniters! > > Im fixing https://issues.apache.org/jira/br

TouchedExpiryPolicy works incorrect in some cases IGNITE-4401

Hello igniters! Im fixing https://issues.apache.org/jira/browse/IGNITE-4401 In configuration of cache with name defaultNameEDUPropCache in initializeCache() there is ExpiryPolicyFactory with duration 20 seconds. In main test method after sleeping 10 seconds the entity must not be expired. So my qu

IGNITE-4401 TouchedExpiryPolicy works incorrect in some cases

Hi, Igniters! I will take https://issues.apache.org/jira/browse/IGNITE-4401 if you dont mind -- *Best Regards,* *Kuznetsov Aleksey* -- *Best Regards,* *Kuznetsov Aleksey*

IGNITE-4401

Hi, Igniters! I will take https://issues.apache.org/jira/browse/IGNITE-4401 if you dont mind -- *Best Regards,* *Kuznetsov Aleksey*

IGNITE-4648

Hi, Igniters! I will take https://issues.apache.org/jira/browse/IGNITE-4648 if you dont mind -- *Best Regards,* *Kuznetsov Aleksey*

ask for a ticket

Igniters! Do smbd has got transaction related issue to do ? -- *Best Regards,* *Kuznetsov Aleksey*

IGNITE-4809

Hi, Igniters! I will take IGNITE-4809 if you dont mind -- *Best Regards,* *Kuznetsov Aleksey*

Re: one point optimisation

would like to add 1 phase optimisation isn't gonna work if write through is enabled. ср, 5 апр. 2017 г. в 15:23, Антон Чураев : > Maybe it will be useful to update the documentation? > > 2017-04-05 15:15 GMT+03:00 ALEKSEY KUZNETSOV : > > > Thank you for help! > > &

Re: one point optimisation

T+03:00 ALEKSEY KUZNETSOV : > > > yes > > > > ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk >: > > > > > Do you have a near cache enabled? > > > > > > 2017-04-05 15:00 GMT+03:00 ALEKSEY KUZNETSOV >: > > > > > > > The

Re: one point optimisation

yes ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk : > Do you have a near cache enabled? > > 2017-04-05 15:00 GMT+03:00 ALEKSEY KUZNETSOV : > > > The test shows as follows: > > assertMessageCount(GridNearTxPrepareRequest.class, 1); > >

Re: one point optimisation

the extra messages you observe? > > --AG > > 2017-04-04 14:17 GMT+03:00 ALEKSEY KUZNETSOV : > > > any thoughts on one phase commit realization ? > > > > пн, 3 апр. 2017 г. в 19:35, ALEKSEY KUZNETSOV >: > > > > > I've attached test that pr

Re: NearCache transaction qeustion

sorry, but what is sync/async policy ? пт, 31 мар. 2017 г. в 19:26, Dmitriy Setrakyan : > On Fri, Mar 31, 2017 at 6:29 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > wrote: > > > Hi all! > > Consider we have 4 nodes. Node1 contains key1, Node2 contains key

readyNearLocks()! wat?

Igniters! What is the purpose of calling GridNearTxLocal#readyNearLocks() After we received prepare response at primary node ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: one point optimisation

any thoughts on one phase commit realization ? пн, 3 апр. 2017 г. в 19:35, ALEKSEY KUZNETSOV : > I've attached test that prints messages exchange . Which shows us that > there are more messages then you declared in article. Perhaps, > implementation has changed. > I crea

Re: one point optimisation

> The blog describes the 1-phase commit at a high level, but I am still > curious about the differences you found. Can you share them here? > > D. > > On Mon, Apr 3, 2017 at 2:11 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> > wrote: > > > Regarding IgniteOn

Support for starting transaction in another thread

Hi, Igniters! This is a subtask for "distributed transaction of non-single coordinator" task. Will appreciate your thoughts on it. ticket : https://issues.apache.org/jira/browse/IGNITE-4887 and a commit : https://github.com/voipp/ignite/commit/aa3487bd9c203394f534c605f84e06436b638e5c -- *Best Reg

Re: one point optimisation

ition is always allocated to a specific node and > does not span nodes. Ignite has default 1024 partitions on start that are > split equally across nodes. > > > On 3 Apr 2017, at 08:10, ALEKSEY KUZNETSOV > wrote: > > > > in ur blog u texted belonging to the same

Re: one point optimisation

in ur blog u texted belonging to the same partition is nessesary for 1 phase commit. But its not guarantee belonging to the same node. Partition may span many nodes вс, 2 Апр 2017 г., 13:46 ALEKSEY KUZNETSOV : > thank u ! > > пт, 31 Мар 2017 г., 21:06 Denis Magda : > > Here is a

Re: distributed transaction of non-single coordinator

so what do u think on my idea? пт, 31 Мар 2017 г., 11:05 ALEKSEY KUZNETSOV : > sorry for misleading you. We planned to support multi-node transactions, > but failed. > > пт, 31 мар. 2017 г. в 10:51, Alexey Goncharuk >: > > Well, now the scenario is more clear, but it h

Re: one point optimisation

> > > On Mar 31, 2017, at 12:27 PM, Dmitriy Setrakyan > wrote: > > > > On Fri, Mar 31, 2017 at 9:25 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > >> wrote: > > > >> Igniters! What is the point of one phase optimisation? > >> > > > > Performance > > -- *Best Regards,* *Kuznetsov Aleksey*

one point optimisation

Igniters! What is the point of one phase optimisation? -- *Best Regards,* *Kuznetsov Aleksey*

NearCache transaction qeustion

Hi all! Consider we have 4 nodes. Node1 contains key1, Node2 contains key1 backup, and Node3 near-contains (contains in near cache) key1. Now we commit key1 value change like the following : Node4Cache.put(key1, updatedValue); >From my point of view Node1 receives prepare request and send DhtTxPre

Re: distributed transaction of non-single coordinator

53 GMT+03:00 ALEKSEY KUZNETSOV : > > > so what do u think on the issue ? > > > > чт, 30 Мар 2017 г., 17:49 ALEKSEY KUZNETSOV : > > > > > Hi ! Thanks for help. I've created ticket : > > > https://issues.apache.org/jira/browse/IGNITE-4887 >

Re: distributed transaction of non-single coordinator

so what do u think on the issue ? чт, 30 Мар 2017 г., 17:49 ALEKSEY KUZNETSOV : > Hi ! Thanks for help. I've created ticket : > https://issues.apache.org/jira/browse/IGNITE-4887 > and a commit : > https://github.com/voipp/ignite/commit/aa3487bd9c203394f534c605f84e06436b638e5c

usimg of other JTA implementation

Igniters! Why havent u made use of some open JTA implementation for distributed transactions instead of implementing own one -- *Best Regards,* *Kuznetsov Aleksey*

Re: putting entity into cache while commiting.Why!?

it will hang because doInTrasaction > starts a pessimistic transaction which acquires a lock on key1, and then > you put it to infinite sleep. The lock prevents the transaction from > the main thread to commit. > > 2017-03-30 15:44 GMT+03:00 ALEKSEY KUZNETSOV : > > > I'

Re: distributed transaction of non-single coordinator

and how they are supposed to work. > > --AG > > 2017-03-30 10:43 GMT+03:00 ALEKSEY KUZNETSOV : > > > So, what do u think on my idea ? > > > > ср, 29 мар. 2017 г. в 10:35, ALEKSEY KUZNETSOV >: > > > > > Hi! No, i dont have ticket for this. > &

Re: putting entity into cache while commiting.Why!?

gt; monitor.wait(); > System.out.println("continue first transaction"); > return null; > } > }); > } > return null; > } > }); > > Transaction tx = >

Re: putting entity into cache while commiting.Why!?

your test the result of method atomicityMode() is not used > because you do getOrCreateCache() without the configuration argument, which > will create a cache with a default configuration, which is ATOMIC. > > 2017-03-30 12:06 GMT+03:00 ALEKSEY KUZNETSOV : > > >

Re: putting entity into cache while commiting.Why!?

. 2017 г. в 11:55, Alexey Goncharuk : > Can you please paste the full example? > > 2017-03-30 11:50 GMT+03:00 ALEKSEY KUZNETSOV : > > > But i managed to read dirty. That is my example : > > > > Ignite ignite0 = ignite(0); > > IgniteTransactions

Re: putting entity into cache while commiting.Why!?

Aleksey, No, the enlisted entry won't be visible for other transactions. Dirty reads are not allowed in Ignite. Kind regards, Alex 29 марта 2017 г. 7:36 PM пользователь "ALEKSEY KUZNETSOV" < alkuznetsov...@gmail.com> написал: Hello, Igniters! I have one more question to you. W

Re: distributed transaction of non-single coordinator

So, what do u think on my idea ? ср, 29 мар. 2017 г. в 10:35, ALEKSEY KUZNETSOV : > Hi! No, i dont have ticket for this. > In the ticket i have implemented methods that change transaction status to > STOP, thus letting it to commit transaction in another thread. In another > thread

putting entity into cache while commiting.Why!?

Hello, Igniters! I have one more question to you. Will appreciate any help. Consider cache with near , dht configured not null. When we start commit transaction , in method *org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#enlistWriteEntry* we put newly created entry int

serializable tx prepare future

Hi all ! In GridNearTxLocal while preparing phase in optimistic mode : *org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#prepareNearTxLocal* we check serializable() and create GridNearOptimisticSerializableTxPrepareFuture What is the point of serializable future ? --

Re: distributed transaction of non-single coordinator

things work. > > — > Denis > > > On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV > wrote: > > > > Hi, Igniters! I 've made implementation of transactions of non-single > > coordinator. Here you can start transaction in one thread and commit it > in &g

Re: distributed transaction of non-single coordinator

5ef45 пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin : > You know better, go ahead! :) > > Sergi > > 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV : > > > we've discovered several problems regarding your "accumulation" > > approach.These are > > > >

question about peeking entry from cache

Hi all! There is method that peek cache entry from a cache org.apache.ignite.internal.processors.cache.GridCacheAdapter#peekEx(java.lang.Object) And there is another method: org.apache.ignite.internal.processors.cache.GridCacheMapEntry#peek(boolean, boolean, boolean, org.apache.ignite.internal.pr

remap response during prepare phase

Hi, igniters! My questions is the following. what is "remap response" GridNearTxPrepareResponse in processNearTxPrepareRequest? -- *Best Regards,* *Kuznetsov Aleksey*

cache entry invalidating

hi all ! why do we need to invalidate cache entry in org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareRequest#invalidateNearEntry(int, boolean) -- *Best Regards,* *Kuznetsov Aleksey*

strange GridCacheReturn

Hi all! what is the use of GridCacheReturn ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: strange cacheEntry field

nodes. > > See GridCacheContext#dhtMap(UUID, AffinityTopologyVersion, > GridDhtCacheEntry, GridCacheVersion, IgniteLogger, > Map>, > Map>) > > --AG > > 2017-03-22 18:03 GMT+03:00 ALEKSEY KUZNETSOV : > > > Hi all! There is a field rdrs in class GridDhtCacheEntr

Re: prepare phase messages handlers question

017-03-22 20:26 GMT+03:00 ALEKSEY KUZNETSOV : > > > correct me if im wrong. Consider node1 called cache.put(key1, val1); > > So node1 creates cacheEntry1. If Affinity function decides node2 holds > key1 > > then cacheEntry1 will be detached, otherwise cacheEntry isnt deta

Re: prepare phase messages handlers question

an entry locked by an optimistic transaction is > locked on a primary or backup node. Like you said, if an entry is detached, > it means that it is created by a node to which this entry does not belong, > and thus must not be locked. > > --AG > > 2017-03-22 18:37 GMT+03:00 ALEKSE

Re: prepare phase messages handlers question

rotocol. > They are sent from a primary node to backup nodes. > > > On Mon, Mar 20, 2017 at 7:41 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > wrote: > > > Hi all! > > What is the point of sending GridDhtTxPrepareRequest and >

strange cacheEntry field

Hi all! There is a field rdrs in class GridDhtCacheEntry. Why do we need it ? -- *Best Regards,* *Kuznetsov Aleksey*

optimistic transaction caching

Hi all ! Optimistic transaction of READ_COMMITTED mode is never cached in transaction, as it stated in documenattion. I cannot find the point in code where it is checked. -- *Best Regards,* *Kuznetsov Aleksey*

prepare phase messages handlers question

Hi all! What is the point of sending GridDhtTxPrepareRequest and GridDhtTxPrepareResponse messages? What is the logic behind processDhtTxFinishRequest and processDhtTxPrepareResponse ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: transactions classes usage

he same time, then only GridDhtTx*Request > is sent. > > > On Fri, Mar 17, 2017 at 4:48 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > wrote: > > > Hi all! We've got a group of GridDhtTx*Request classes, how do they > relate > > to GridNearTx*R

transactions classes usage

Hi all! We've got a group of GridDhtTx*Request classes, how do they relate to GridNearTx*Request classes? -- *Best Regards,* *Kuznetsov Aleksey*

Re: distributed transaction of non-single coordinator

until we realize how to solve difficulties above . чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin : > The problem "How to run millions of entities, and millions of operations on > a single Pentium3" is out of scope here. Do the math, plan capacity > reasonably. > > Sergi >

Re: distributed transaction of non-single coordinator

ide of all Services must be optimistic here to be able to > read this locked key. > > But again I do not recommend you using this approach until you have a > reliable deadlock avoidance scheme. > > Sergi > > > > > > > > 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETS

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

It still unclear , how could i notify coordinator that cache creation failed чт, 9 мар. 2017 г. в 17:46, Yakov Zhdanov : Alexey, you should understand how caches startup and partition map exchange work. I would suggest you start couple of nodes in single VM and simply do step-by-step debug in y

Re: Unused argument in DirectMessageWriter

watch him, he is gonna remove all the messages he doesn't like :) чт, 16 мар. 2017 г. в 14:56, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Hi, > > These classes are part of plugin framework. Even though 'name' argument is > not used by Ignite implementations, it can be used by others.

Re: distributed transaction of non-single coordinator

some Service A introduce changes? So no other service is allowed to change this key-value?(sort of pessimistic blocking) May be you know some implementations of such approach ? ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV : > Thank you very much for help. I will answer later. > > с

Re: distributed transaction of non-single coordinator

of any other keys end > result depends on. > > After that Committer Service has to do a cleanup (may be outside of the > committing tx) to come to the following final state: > > [k1 => v1a] > [k2 => v2ab] > [k3 => v3b] > >

Re: distributed transaction of non-single coordinator

> to Orchestrator to restart the job with new `otx` > > PROFIT!! > > This approach even allows you to run independent parts of the graph in > parallel (with TX transfer you will always run only one at a time). Also it > does not require inventing any special fault toleran

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

Its not simple as you say) Im confused with numerous sender\listener etc. methods. It looks like, coordinator node sends DynamicCacheChangeBatch message, with cache create request over cacheProcessor to smbd. But i cannot trace cache startup flow from this point. чт, 9 мар. 2017 г. в 17:46, Yakov

Re: distributed transaction of non-single coordinator

we understand all implications, we should move to development stage. > > On Wed, Mar 15, 2017 at 10:38 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> wrote: > > > Right > > > > ср, 15 мар. 2017 г. в 10:35, Sergi Vladykin : > > > > > Good! Basically yo

Re: distributed transaction of non-single coordinator

03-14 22:46 GMT+03:00 ALEKSEY KUZNETSOV : > > > orchestrator is a custom thing. He is responsible for managing business > > scenarios flows. Many nodes are involved in scenarios. They exchange data > > and folow one another. If you acquinted with BPMN framework, so > > orchestra

Re: distributed transaction of non-single coordinator

is Orchestrator for you? Is it a thing from Microsoft or your custom > in-house software? > > Sergi > > 2017-03-14 18:00 GMT+03:00 ALEKSEY KUZNETSOV : > > > Fine. Let's say we've got multiple servers which fulfills custom logic. > > This servers compound ori

Re: distributed transaction of non-single coordinator

i Vladykin : > Ok, it is not a business case, it is your wrong solution for it. > Lets try again, what is the business case? > > Sergi > > 2017-03-14 16:42 GMT+03:00 ALEKSEY KUZNETSOV : > > > The case is the following, One starts transaction in one node, and commit > &

Re: distributed transaction of non-single coordinator

l. > > Sergi > > 2017-03-14 16:03 GMT+03:00 ALEKSEY KUZNETSOV : > > > Why wrong ? You know the better solution? > > > > вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin : > > > > > Just serializing TX object and deserializing it on another node is > >

Re: distributed transaction of non-single coordinator

anges, we definitely will > have fault tolerance and performance issues. IMO the whole idea is wrong > and it makes no sense to waste time on it. > > Sergi > > 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV : > > > IgniteTransactionState implememntation contains IgniteT

question regarding EntryProcessor

Hi all! When we invoke EntryProcessor with a given key would it be executed on a separate node, where the key resides? What if there is no key mapping. -- *Best Regards,* *Kuznetsov Aleksey*

Re: distributed transaction of non-single coordinator

xt. If some data > needs to be passed across, we should create a special transfer object in > this case. > > D. > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > wrote: > > > well, there a couple of issues preventing tr

Re: distributed transaction of non-single coordinator

field at TransactionProxyImpl. Perhaps, it must be injected by GridResourceProcessor ? пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV : > while starting and continuing transaction in different jvms in run into > serialization exception in writeExternalMeta : > > @Override

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

Thanks! пн, 13 мар. 2017 г. в 17:24, Alexey Goncharuk : > Aleksey, > > Thanks, I merged your changes to master. Please resolve the ticket. > > 2017-03-13 12:33 GMT+03:00 ALEKSEY KUZNETSOV : > > > I've fixed all your remarks. Plz, review them > > > > пн,

Re: distributed transaction of non-single coordinator

x > > ownership from one node to another will be happened automatically when > > originating node is gone down. > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV : > > > > > Im aiming to span transaction on multiple threads, nodes, jvms(soon). > So > > &g

starting grids in tests

Hi All! When would you call startGridsMultiThreaded instead of startGrids. I wonder why would one start grids multithreaded ? -- *Best Regards,* *Kuznetsov Aleksey*

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

I've fixed all your remarks. Plz, review them пн, 13 мар. 2017 г. в 11:17, Alexey Goncharuk : > My apologies, the comments were not committed to GitHub. They are there > now. > > 2017-03-13 11:13 GMT+03:00 ALEKSEY KUZNETSOV : > > > Hi! This is my PR link : https://git

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

Hi! This is my PR link : https://github.com/apache/ignite/pull/1517. You must have mixed it up, for there is *no* comments to address. пт, 10 мар. 2017 г. в 20:10, Alexey Goncharuk : > Yes, but I have added a few more today :) > > 2017-03-10 19:03 GMT+03:00 ALEKSEY KUZNETSOV : > >

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

Hmm, i have fixed all your remarks more than 20 days ago. пт, 10 мар. 2017 г. в 15:12, Alexey Goncharuk : > Alexey, > > Looks good. I've left my comments in the PR, please address them and I will > merge it. > > 2017-03-10 10:24 GMT+03:00 ALEKSEY KUZNETSOV : > &

Re: distributed transaction of non-single coordinator

+03:00 Дмитрий Рябов : > > > Alexey Goncharuk, heh, my initial understanding was that transferring of > tx > > ownership from one node to another will be happened automatically when > > originating node is gone down. > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZ

Re: general question

ch a way that at least one > participating node does not receive a prepare request. As an example, you > can look > at > org.apache.ignite.internal.processors.cache.distributed.dht.IgniteCachePrimaryNodeFailureRecoveryAbstractTest. > > --AG > > 2017-03-09 20:09 GMT+03:00 ALEKS

Re: distributed transaction of non-single coordinator

: > Aleksey, > > Do you mean that you want a concept of transferring of tx ownership from > one node to another? My initial understanding was that you want to be able > to update keys in a transaction from multiple threads in parallel. > > --AG > > 2017-03-10 15:01

Re: distributed transaction of non-single coordinator

. 2017 г. в 22:38, Denis Magda : > Hi Alexey, > > Please share the rational behind this and the thoughts, design ideas you > have in mind. > > — > Denis > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV > wrote: > > > > Hi all! I

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

plz review ticket again чт, 9 мар. 2017 г. в 10:28, ALEKSEY KUZNETSOV : > plz review ticket again > > вт, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV >: > > plz review ticket again > > пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk >: > > Thanks, Aleksey,

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

Hi! Can u plz review ticket once more вт, 7 мар. 2017 г. в 18:52, Andrey Gura : > Aleksey, thanks a lot! > > Answered in JIRA ticket. > > On Tue, Mar 7, 2017 at 1:27 PM, ALEKSEY KUZNETSOV > wrote: > > Hi! I have fixed all sources. Plz, review it again > > > >

general question

Hi all! Is it possible to test on multiple jvm's ? Let's say, to have multiple ignite instances deployed on different jvms ? If yes, how can i create them and address them in code ? -- *Best Regards,* *Kuznetsov Aleksey*

general question

Hi all! Consider we've got local transaction. How can i simulate node breakage in tests so that transaction will be in ROLLED_BACK state? -- *Best Regards,* *Kuznetsov Aleksey*

Re: general question

r more details check the class hierarchy. > > On Tue, Mar 7, 2017 at 3:07 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> > wrote: > > > I've found GridDhtCacheEntry and GridDistributedCacheEntry, so they > > must have been of the same logic ?

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

Regarding your comment in ticket. Do you mean broken factory node ought to send notifications to cache nodes through sharedCtx.io().send(...) ? вт, 7 мар. 2017 г. в 14:23, ALEKSEY KUZNETSOV : > Regarding your comment in ticket. Do you mean broken factory node ought to > send notificati

Re: PR IGNITE-1178 fix for NPE in GridCacheProcessor.onKernalStop()

plz review ticket again вт, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV : > plz review ticket again > > пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk >: > > Thanks, Aleksey, > > I will take a look this week. > > --AG > > 2017-02-20 10:25 GMT+03:00 ALEKSE

Re: general question

I've found GridDhtCacheEntry and GridDistributedCacheEntry, so they must have been of the same logic ? пт, 3 мар. 2017 г. в 15:03, Alexander Fedotov : > Yes, DHT stands for distributed hash table. > > On Fri, Mar 3, 2017 at 3:01 PM, ALEKSEY KUZNETSOV < > alkuznetsov..

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

v, Director R&D > *GridGain Systems* > www.gridgain.com > > 2017-03-01 12:15 GMT+03:00 Yakov Zhdanov : > > > Alexey, I will take a look at this in couple of days. > > > > --Yakov > > > > 2017-03-01 11:25 GMT+03:00 ALEKSEY KUZNETSOV : > > > &g

distributed transaction of non-single coordinator

Hi all! Im designing distributed transaction which can be started at one node, and continued at other one. Has anybody thoughts on it ? -- *Best Regards,* *Kuznetsov Aleksey*

<    1   2   3   >