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 :
>
>> Alex, I have commented
Thanks! Do you think all test scenarios results, presented in table(in
ticket comments) , are acceptable ?
пт, 30 июн. 2017 г., 18:28 Yakov Zhdanov :
> Alex, I have commented in the ticket. Please take a look.
>
> Thanks!
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
Alex, I have commented in the ticket. Please take a look.
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
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 KUZNET
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 ?
>
> пн, 3 апр. 2017 г. в 9:47, ALE
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 :
>
>> sorry for misleading yo
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 has nothing to do with
> mul
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 has nothing to do with
> multiple coordinators :) Let me think a little bit about it.
>
> 2017-03-31 9:53 GMT+03:00 A
Well, now the scenario is more clear, but it has nothing to do with
multiple coordinators :) Let me think a little bit about it.
2017-03-31 9: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 cre
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
> We really need thi
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
We really need this feature
чт, 30 мар. 2017 г. в 11:31, Alexey Goncharuk :
> Aleksey,
>
> I doubt your appr
Aleksey,
I doubt your approach works as expected. Current transaction recovery
protocol heavily relies on the originating node ID in its internal logic.
For example, currently a transaction will be rolled back if you want to
transfer a transaction ownership to another node and original tx owner
fa
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 you r going to
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 you r going to restart transaction in order to commit it.
The mechanism behind it is obvious : we change t
Aleksey,
Do you have a ticket for this? Could you briefly list what exactly was done and
how the 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 transact
Hi, Igniters! I 've made implementation of transactions of non-single
coordinator. Here you can start transaction in one thread and commit it in
another thread.
Take a look on it. Give your thoughts on it.
https://github.com/voipp/ignite/pull/10/commits/3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45
пт
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
>
>1. perfomance issues when transfering data from temporary cache to
>permanent one. Keep in mind big deal of concure
we've discovered several problems regarding your "accumulation"
approach.These are
1. perfomance issues when transfering data from temporary cache to
permanent one. Keep in mind big deal of concurent transactions in Service
commiter
2. extreme memory load when keeping temporary cache i
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
2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV :
> hmm, If we have millions of entities, and millions of operations, would not
> this ap
hmm, If we have millions of entities, and millions of operations, would not
this approache lead to memory overflow and perfomance degradation
чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin :
> 1. Actually you have to check versions on all the values you have read
> during the tx.
>
> For example if
1. Actually you have to check versions on all the values you have read
during the tx.
For example if we have [k1 => v1, k2 => v2] and do:
put(k1, get(k2) + 5)
We have to remember the version for k2. This logic can be relatively easily
encapsulated in a framework atop of Ignite. You need to imple
Yeah, now i got it.
There are some doubts on this approach
1) During optimistic commit phase, when you assure no one altered the
original values, you must check versions of other dependent keys. How could
we obtain those keys(in an automative manner, of course) ?
2) How could we lock a key before s
Thank you very much for help. I will answer later.
ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin :
> All the services do not update key in place, but only generate new keys
> augmented by otx and store the updated value in the same cache + remember
> the keys and versions participating in the tra
All the services do not update key in place, but only generate new keys
augmented by otx and store the updated value in the same cache + remember
the keys and versions participating in the transaction in some separate
atomic cache.
Follow this sequence of changes applied to cache contents by each
- what do u mean by saying "
*in a single transaction checks value versions for all the old values
and replaces them with calculated new ones *"? Every time you change
value(in some service), you store it to *some special atomic cache* , so
when all services ceased working, Service com
Ok, here is what you actually need to implement at the application level.
Lets say we have to call 2 services in the following order:
- Service A: wants to update keys [k1 => v1, k2 => v2] to [k1 => v1a,
k2 => v2a]
- Service B: wants to update keys [k2 => v2a, k3 => v3] to [k2 => v2ab,
k
Okay, we are open for proposals on business task. I mean, we can make use
of some other thing, not distributed transaction. Not transaction yet.
ср, 15 мар. 2017 г. в 11:24, Vladimir Ozerov :
> IMO the use case makes sense. However, as Sergi already mentioned, the
> problem is far more complex, t
IMO the use case makes sense. However, as Sergi already mentioned, the
problem is far more complex, than simply passing TX state over a wire. Most
probably a kind of coordinator will be required still to manage all kinds
of failures. This task should be started with clean design proposal
explaining
Right
ср, 15 мар. 2017 г. в 10:35, Sergi Vladykin :
> Good! Basically your orchestrator just takes some predefined graph of
> distributed services to be invoked, calls them by some kind of RPC and
> passes the needed parameters between them, right?
>
> Sergi
>
> 2017-03-14 22:46 GMT+03:00 ALEKSEY
Good! Basically your orchestrator just takes some predefined graph of
distributed services to be invoked, calls them by some kind of RPC and
passes the needed parameters between them, right?
Sergi
2017-03-14 22:46 GMT+03:00 ALEKSEY KUZNETSOV :
> orchestrator is a custom thing. He is responsible
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
orchestrator is like bpmn engine.
вт, 14 Мар 2017 г., 18:56 Sergi Vladykin :
> What is
What 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 oriented graph (BPMN process) which controlled by
>
Fine. Let's say we've got multiple servers which fulfills custom logic.
This servers compound oriented graph (BPMN process) which controlled by
Orchestrator.
For instance, *server1 *creates *variable A *with value 1, persists it to
IGNITE cache and creates *variable B *and sends it to* server2. *T
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
> this transaction in another jvm node(or rollback it remot
The case is the following, One starts transaction in one node, and commit
this transaction in another jvm node(or rollback it remotely).
вт, 14 мар. 2017 г. в 16:30, Sergi Vladykin :
> Because even if you make it work for some simplistic scenario, get ready to
> write many fault tolerance tests a
Because even if you make it work for some simplistic scenario, get ready to
write many fault tolerance tests and make sure that you TXs work gracefully
in all modes in case of crashes. Also make sure that we do not have any
performance drops after all your changes in existing benchmarks. All in all
Why wrong ? You know the better solution?
вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin :
> Just serializing TX object and deserializing it on another node is
> meaningless, because other nodes participating in the TX have to know about
> the new coordinator. This will require protocol changes, we
Just serializing TX object and deserializing it on another node is
meaningless, because other nodes participating in the TX have to know about
the new coordinator. This will require protocol changes, we definitely will
have fault tolerance and performance issues. IMO the whole idea is wrong
and it
IgniteTransactionState implememntation contains IgniteTxEntry's which is
supposed to be transferable
пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan :
> It sounds a little scary to me that we are passing transaction objects
> around. Such object may contain all sorts of Ignite context. If some dat
It sounds a little scary to me that we are passing transaction objects
around. Such object may contain all sorts of Ignite context. 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 wrote:
> we
well, there a couple of issues preventing transaction proceeding.
At first, After transaction serialization and deserialization on the remote
server, there is no txState. So im going to put it in
writeExternal()\readExternal()
The last one is Deserialized transaction lacks of shared cache context
while starting and continuing transaction in different jvms in run into
serialization exception in writeExternalMeta :
@Override public void writeExternal(ObjectOutput out) throws IOException {
writeExternalMeta(out);
some meta is cannot be serialized.
пт, 10 мар. 2017 г. в 17:25, Alexey Gonc
- Its a draft test, in my next one i will try to serialize transaction
and send it across nodes
- thats where STOPPED status comes in handy.You cannot restart
transaction in another node unless it was stopped. And you cannot commit if
transaction status is STOPPED. Further tests shou
What about to send special message to random/choosen node when we start
transaction? And when rollback procedure begins - this second node will
check state of originating node and if it is down then second node became
originating?
2017-03-10 17:25 GMT+03:00 Alexey Goncharuk :
> Aleksey,
>
> I thi
Aleksey,
I think I am starting to get what you want, but I have a few concerns:
- What is the API for the proposed change? In your test, you pass an
instance of transaction created on ignite(0) to the ignite instance
ignite(1). This is obviously not possible in a truly distributed
(multi-jvm) env
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 KUZNETSOV :
> Im aiming to span transaction on multiple threads, nodes, jvms(soon).
Im aiming to span transaction on multiple threads, nodes, jvms(soon). So
every node is able to rollback, or commit common transaction.It turned up i
need to transfer tx between nodes in order to commit transaction in
different node(in the same jvm).
пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk :
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 GMT+03:00 ALEKSEY KUZNETSOV :
> Well. Consider tr
Well. Consider transaction started in one node, and continued in another
one.
The following test describes my idea:
Ignite ignite1 = ignite(0);
IgniteTransactions transactions = ignite1.transactions();
IgniteCache cache = ignite1.getOrCreateCache("testCache");
Transaction tx = transactions.txSt
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! Im designing distributed transaction which can be started at one
> node, and continued at other one. Has anybody thou
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*
50 matches
Mail list logo
