I've done it, but from time to time transaction doesn't roll back. Perhaps,
its a known bug
пт, 10 мар. 2017 г. в 9:31, Alexey Goncharuk :
> Hi Aleksey,
>
> In order to ensure that a transaction is rolled back during a node failure,
> you need to orchestrate messages in such a way that at least o
As for the multi-jvm tests, please see isMultiJvm() method and it's
overrides in GridAbstractTest. We have some basic functionality to support
that kind of tests.
--AG
2017-03-09 20:09 GMT+03:00 ALEKSEY KUZNETSOV :
> Hi all! Is it possible to test on multiple jvm's ? Let's say, to have
> multipl
Hi Aleksey,
In order to ensure that a transaction is rolled back during a node failure,
you need to orchestrate messages in such 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.dh
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*
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*
DHT refers to server side cache. Near cache is a part of distributed cache,
but not a part of DHT.
-Val
On Thu, Mar 9, 2017 at 3:39 PM, Alexander Fedotov <
alexander.fedot...@gmail.com> wrote:
> Probably, the reasoning for it is that near entries have distributed form,
> i.e. they are kept in sy
Probably, the reasoning for it is that near entries have distributed form,
i.e. they are kept in sync with the
changes, but actually, they aren't true DHT entries. So
GridDistributedCacheEntry is the parent for
GridNearCacheEntry and GridDhtCacheEntry and reflects the distributed
common nature
of i
it looks strange. Because, DHT = distributed
чт, 9 мар. 2017 г. в 14:26, Alexander Fedotov :
> I suppose, GridDistributedCacheEntry contains common logic for Near and DHT
> entries, while
> GridDhtCacheEntry is it's subclass and contains common logic for DHT
> entries.
> For more details check th
I suppose, GridDistributedCacheEntry contains common logic for Near and DHT
entries, while
GridDhtCacheEntry is it's subclass and contains common logic for DHT
entries.
For more details check the class hierarchy.
On Tue, Mar 7, 2017 at 3:07 PM, ALEKSEY KUZNETSOV
wrote:
> I've found GridDhtCacheE
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...@gmail.com>
> wrote:
>
> >
Big thanx!
пн, 6 мар. 2017 г. в 17:37, Andrey Gura :
> You always can use opposite direct during finding solution:
>
> ignite.cluster().forDataNodes(C1.getName()).nodes().contains(N1)
>
> On Mon, Mar 6, 2017 at 5:01 PM, ALEKSEY KUZNETSOV
> wrote:
> > Again. My question was "How could we list all
You always can use opposite direct during finding solution:
ignite.cluster().forDataNodes(C1.getName()).nodes().contains(N1)
On Mon, Mar 6, 2017 at 5:01 PM, ALEKSEY KUZNETSOV
wrote:
> Again. My question was "How could we list all caches, residing on a
> certain Ignite instance?". In other words,
Again. My question was "How could we list all caches, residing on a
certain Ignite instance?". In other words, i want to make sure N1 doesn't
contain C1 cache. Is there a function F() as following : F (N1) = null ,
F(N2) = C1.
пн, 6 мар. 2017 г. в 16:54, Andrey Gura :
> Aleksey,
>
> node N1 must
Aleksey,
node N1 must not contain C1 cache data (must not be affinity node for
cache C1), but N1 node must to know about C1 cache (must jave C1 cache
descriptor) in order to provide access to C1 cache from this node.
On Mon, Mar 6, 2017 at 4:36 PM, ALEKSEY KUZNETSOV
wrote:
> Consider we've got
Consider we've got N1 and N2 nodes.Configure cache context C1 with node
filter, which filters out N1. Now, if you call cacheNames on either of
ignite instances you get C1. But N1 node must not contain C1 cache.
пн, 6 мар. 2017 г. в 16:32, Sergey Kozlov :
> Hi Aleksey
>
>
> https://ignite.apache.o
Hi Aleksey
https://ignite.apache.org/releases/1.8.0/javadoc/org/apache/ignite/Ignite.html#cacheNames()
On Mon, Mar 6, 2017 at 3:52 PM, ALEKSEY KUZNETSOV
wrote:
> Hi all ! How could we list all caches, residing on a certain Ignite
> instance?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
Hi all ! How could we list all caches, residing on a certain Ignite
instance?
--
*Best Regards,*
*Kuznetsov Aleksey*
Yes, DHT stands for distributed hash table.
On Fri, Mar 3, 2017 at 3:01 PM, ALEKSEY KUZNETSOV
wrote:
> Thank you so much! And the last one. I cannot find definition of DHT. Does
> it stand for distributed ? In contrary to Local
>
> пт, 3 мар. 2017 г. в 13:51, Alexander Fedotov <
> alexander.fedo
Thank you so much! And the last one. I cannot find definition of DHT. Does
it stand for distributed ? In contrary to Local
пт, 3 мар. 2017 г. в 13:51, Alexander Fedotov :
> Probably, IgniteTxHandler#processDhtTxPrepareRequest is what you are
> looking for.
> Check the data flow from GridDhtTxPrep
Probably, IgniteTxHandler#processDhtTxPrepareRequest is what you are
looking for.
Check the data flow from GridDhtTxPrepareRequest#nearWrites
On Fri, Mar 3, 2017 at 1:19 PM, ALEKSEY KUZNETSOV
wrote:
> Ah, thanks! Which class is responsible for near cache synchronization ?
>
> пт, 3 мар. 2017 г.
Ah, thanks! Which class is responsible for near cache synchronization ?
пт, 3 мар. 2017 г. в 13:15, Alexander Fedotov :
> Hi Aleksey,
>
> Local cache pertains only to the node where it's created and no data is
> distributed to
> or synchronized with other nodes, while near cache serves as a front
Hi Aleksey,
Local cache pertains only to the node where it's created and no data is
distributed to
or synchronized with other nodes, while near cache serves as a front end
for a partitioned cache, storing recently requested data which is
synchronized when it's changed on
other nodes.
On Fri, Mar
Hi all ! What is the difference between local and near transactions
--
*Best Regards,*
*Kuznetsov Aleksey*
Hi,
What exactly do you observe and how do you configure it? As I understand the
SPI should be called even if the peer-class-loading is disabled. I would
suggest turning on logger’s debug mode for this implementation.
—
Denis
> On Feb 20, 2017, at 7:48 AM, ALEKSEY KUZNETSOV
> wrote:
>
> Hi!
Hi! Why local deployment SPI is ignored, if peer class loading is disabled,
and local deployment spi is enabled ?
--
*Best Regards,*
*Kuznetsov Aleksey*
Hi Alexey,
See how
org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.meta()
is used by,
e.g. org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy.touch()
method that is calling when entry accessed.
On Wed, Feb 15, 2017 at 6:10 PM, ALEKSEY KUZNETSOV wrote:
> hmm, why and
hmm, why and how EvictionManager tracks an entry ?
вт, 14 февр. 2017 г. в 23:07, Andrey Mashenkov :
> Hi Aleksey,
>
> EvictableEntry.meta is used by EvictionManager to track entry.
> Actually it may contains Node of EvictionPolicy queue to manupulate queue
> items in more efficient way.
>
> On Tu
Hi Aleksey,
EvictableEntry.meta is used by EvictionManager to track entry.
Actually it may contains Node of EvictionPolicy queue to manupulate queue
items in more efficient way.
On Tue, Feb 14, 2017 at 4:26 PM, ALEKSEY KUZNETSOV wrote:
> need help. What is the use of EvictableEntry.meta ? Why
need help. What is the use of EvictableEntry.meta ? Why do we need to ship
some meta to entry ?
--
*Best Regards,*
*Kuznetsov Aleksey*
gt;
> > >
> > >
> > > --
> > > View this message in context: http://apache-ignite-
> > > developers.2346864.n4.nabble.com/general-question-tp14522.html
> > > Sent from the Apache Ignite Developers mailing list archive at
> > Nabble.com.
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
> --AG
>
> 2017-02-13 12:42 GMT+03:00 voipp :
>
> > Hi, all ! What is the use of GridResourceProcessor ? And its inject()
> > method
> >
> >
> >
> > --
> > View this message in context: http://apache-ignite-
> > developers.2346864.n4.nabbl
ect()
> method
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/general-question-tp14522.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>
Hi, all ! What is the use of GridResourceProcessor ? And its inject() method
--
View this message in context:
http://apache-ignite-developers.2346864.n4.nabble.com/general-question-tp14522.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
Please have a look at BinarySchema and it's usages. Essentially this is a
fingerprint of object fields in the order they were serialized, represented
as [field name] -> [position] hash map. Consider and object with 3 fields -
A, B, C. There could be 6 different schemas for it: [A, B, C], [A, C, B],
What is schema in your context?
пн, 13 февр. 2017 г. в 10:50, Vladimir Ozerov :
> Alex,
>
> FieldAccessor stores field positions for the given schema to allow for fast
> field value lookup.
>
> On Fri, Feb 10, 2017 at 7:06 PM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > wrote:
>
> > Guys,
Alex,
FieldAccessor stores field positions for the given schema to allow for fast
field value lookup.
On Fri, Feb 10, 2017 at 7:06 PM, ALEKSEY KUZNETSOV wrote:
> Guys, i have a question.Why do we store fields position information in
> FieldAccessor before hashcode evaluation? Test example is in
Guys, i have a question.Why do we store fields position information in
FieldAccessor before hashcode evaluation? Test example is in
:
org.apache.ignite.internal.binary.BinaryFieldIdentityResolverSelfTest#testHashCode
--
*Best Regards,*
*Kuznetsov Aleksey*
37 matches
Mail list logo
