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

on config = cache.getConfiguration( > CacheConfiguration.class); > System.out.println(config.getAtomicityMode());//TRANSACTIONAL > > So, atomicity is transactional > > чт, 30 мар. 2017 г. в 12:43, Alexey Goncharuk >: > > > Aleksey, > > > > It looks like in your test the result

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

lation.READ_COMMITTED); > cache.put("key1", "val1"); > cache.put("key2", "val2"); > cache.put("key3", "val3"); > tx.commit(); > > } > } > > > чт, 30 мар. 2017 г. в 11

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

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 transactions = ignite0.transactions(); > IgniteCache cache = ignite0.getOrCreateCache("testCache"); > Obje

Re: distributed transaction of non-single coordinator

;> design > > >>>>>>> proposal > > >>>>>>>>>>>> explaining how we handle all these concurrent events. > > >> And > > >>>>> only > > >>>>>>>> then, > > >>>>

Stable binary key representation

Guys, I stumbled across this ticket [1] and it seems to me that the whole approach of identity resolvers is error-prone. If a key contains some data that does not participate in equals() calculation, these fields may be as well moved to the value object. Even with binary objects, key mutation look

[jira] [Created] (IGNITE-4876) Tests: node stop should wait for cluster to see actual topology version

Alexey Goncharuk created IGNITE-4876: Summary: Tests: node stop should wait for cluster to see actual topology version Key: IGNITE-4876 URL: https://issues.apache.org/jira/browse/IGNITE-4876

Re: IgniteFuture adapters

Sergei, Why should this method be a part of the future API? The only implementation will do "return func(this);" I can achieve the same result the following way: rx(compute.runAsync(runnable)).timeout(5_000).subscribe(); 2017-03-27 15:54 GMT+03:00 Sergei Egorov : > Take a look at my initial c

Re: Question about OBJ binary representation

-24 12:02 GMT+03:00 Vyacheslav Daradur : > Alexey, one more question. > > In which cases, classLoader won't find Class by class-name? > > 2017-03-24 10:00 GMT+03:00 Alexey Goncharuk : > > > Vyacheslav, > > > > As for the real scenarios for a class name no

[jira] [Created] (IGNITE-4861) Export rebalance metrics and state as MBeans

Alexey Goncharuk created IGNITE-4861: Summary: Export rebalance metrics and state as MBeans Key: IGNITE-4861 URL: https://issues.apache.org/jira/browse/IGNITE-4861 Project: Ignite Issue

Re: remap response during prepare phase

When a client maps transaction commit, it does this optimistically on the latest version of the topology available for the client. If the topology changes on the server during request transfer, it will send the remap response with the observed version of the topology. The client will wait for this

Re: Question about OBJ binary representation

Vyacheslav, As for the real scenarios for a class name not be registered, this can happen when Ignite attempts to register a mapping on a locked topology (for example, inside a started user transaction) and the primary node for the corresponding mapping key has left. In this case, the mapping atte

Re: prepare phase messages handlers question

: > in this case assert !entry1.detached() will throw exception > > ср, 22 мар. 2017 г. в 23:17, Alexey Goncharuk >: > > > Yes, that is correct. Note, however, that in this case, node1 will send a > > NearTxPrepareRequest to node2 and lockMultiple() will be called

Re: prepare phase messages handlers question

node1 creates cacheEntry1. If Affinity function decides node2 holds key1 > then cacheEntry1 will be detached, otherwise cacheEntry isnt detached. > > ср, 22 Мар 2017 г., 18:43 Alexey Goncharuk : > > > This assertion ensures that an entry locked by an optimistic transaction > is

Re: prepare phase messages handlers question

This assertion ensures that 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 ALEKSEY K

Re: strange cacheEntry field

Hi Aleksey, This field tracks readers - objects which contain node IDs with near cache which has read this key. If an entry contains a reader, this reader must be updated as well alongside with backup nodes. See GridCacheContext#dhtMap(UUID, AffinityTopologyVersion, GridDhtCacheEntry, GridCacheVe

Re: IgniteSemaphore and failoverSafe flag

#x27;t have any way to know if client A still holds the lock or not. > > > > Am I missing something? > > > > -Val > > > > On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > wrote: > > > > > On

[jira] [Created] (IGNITE-4820) Implement parallel indexes for BPlusTree

Alexey Goncharuk created IGNITE-4820: Summary: Implement parallel indexes for BPlusTree Key: IGNITE-4820 URL: https://issues.apache.org/jira/browse/IGNITE-4820 Project: Ignite Issue Type

Re: IgniteSemaphore and failoverSafe flag

> > Which user operation would result in exception? To my knowledge, user may > already be holding the lock and not invoking any Ignite APIs, no? > Yes, this is exactly my point. Imagine that a node already holds a lock and another node is waiting for the lock. If all partition nodes leave the gr

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

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 > > пн, 13 мар. 2017 г. в 11:17, Alexey Goncharuk >: > > > My apologies, the comments were not

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

7 г. в 20:10, Alexey Goncharuk >: > > > Yes, but I have added a few more today :) > > > > 2017-03-10 19:03 GMT+03:00 ALEKSEY KUZNETSOV : > > > > > Hmm, i have fixed all your remarks more than 20 days ago. > > > > > > пт, 10 ма

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

Yes, but I have added a few more today :) 2017-03-10 19:03 GMT+03:00 ALEKSEY KUZNETSOV : > 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 comment

Re: distributed transaction of non-single coordinator

sure that either commit() or rollback() is called if an originator failed? 2017-03-10 15:38 GMT+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

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 GMT+03:00 ALEKSEY KUZNETSOV : > Well. Consider tr

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

, 28 февр. 2017 г. в 14:14, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > >: > > > > plz review ticket again > > > > пн, 20 февр. 2017 г. в 11:14, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > Thanks, Aleksey, &g

Re: general question

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

Re: general question

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

Re: IgniteSemaphore and failoverSafe flag

Guys, I was looking at this ticket and have a question related to the lock semantics: Suppose I have a node which has already acquired the lock, and then all affinity nodes related to the lock leave topology. In this case, if we automatically re-created the lock, we would end up having two lock o

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

> >>>> So you want to change or not? > >>>> > >>>> And > >>>> - GridCacheVersion.writeTo(ByteBuffer buf, MessageWriter writer) > >>>> - GridCacheVersion.readFrom(ByteBuffer buf, MessageReader reader) > >>>> &

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

Maxim, I see several usages of asGridUuid() method, so I would just remove global time and use nodeOrderDrId and topVer as different parts of high and low parts of the embedded UUID. --AG 2017-03-02 12:39 GMT+03:00 Kozlov Maxim : > Andrey, > > When removed parameter globalTime, in method: > > p

Re: IGNITE-4284 - ready for review

Nikita, The fix looks wrong to me. The point of the assertion was to ensure an invariant, see org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager#executeQuery -V2 handler is created only when remote filter factory is not null. The test observes both fields eq

Re: PR IGNITE-2845 Get operation might ignore entry update from EntryProcessor

Aleksey, I am not sure your change is a correct fix. The whole point of EntryProcessor is to avoid sending values over the network and send only entry processor result, which is typically smaller than the value stored in a cache. Looks like this case is covered by the following ticket: https://is

Re: cache metadata progapagation

Dmitriy, What do you mean by deploying cache metadata? The node filter itself must be deserialized on each node because we need to evaluate it. As for the CacheConfiguration, we do not need to deserialize the configuration on every node, this will be a good change for Ignite 2.0. 2017-02-16 23:14

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

up source > > > > пт, 17 февр. 2017 г. в 13:05, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > Aleksey, > > > > I added a comment on GitHub, however, the community is moving towards the > > UpSource review tool, so I suggest y

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

Aleksey, I added a comment on GitHub, however, the community is moving towards the UpSource review tool, so I suggest you open a PR review in Ignite UpSource: http://reviews.ignite.apache.org/ignite/ After you've registered, you should be able to open a review. --AG 2017-02-17 11:13 GMT+03:00 A

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

Alexander, This change is not applicable for GridFutureAdapter because resFlag can have 3 values there. 2017-02-16 19:58 GMT+03:00 Александр Меньшиков : > Hello. > > I propose to do refactoring of classes "GridFinishedFuture" and > "GridFutureAdapter". There is field "resFlag" which can equals "

Re: IGNITE-4534 - Ignite 2.0 eviction design

Dmitriy, For the current off-heap approach, we only have a per-entry LRU eviction policy which does not fit well page memory architecture. I like the adaptation of clock pro algorithm because it requires a significantly smaller amount of memory to track page updates and is scan-resistant. I want

Re: general question

details. 2017-02-13 20:50 GMT+03:00 ALEKSEY KUZNETSOV : > ...and what is the use of inject ? > > пн, 13 Фев 2017 г., 17:28 Alexey Goncharuk : > > > Aleksei, > > > > This processor handles various @*Resource (@IgniteInstanceResource, > > @CacheNameResource, ...) a

Re: IGNITE-4534

Hi Ivan, Welcome to the Ignite community! You should get familiar with Ignite development process described here: https://cwiki.apache.org/confluence/display/IGNITE/Development+Process Instructions on how to contribute can be found here: https://cwiki.apache.org/confluence/display/IGNITE/How+to+

Re: Custom thread pools for compute tasks

> > We cannot compensate blocked threads with new ones forever. At some point > we will have to limit new threads which will bring us to the same problem, > no? > This means that a user recursively trying to call blocking tasks inside of blocking tasks. We can as well detect this and fail with an

Re: Ensure that builder approach is used for all setters in public API

Andrey, Yakov, An MBean for eviction policy is registered in GridCacheProcessor#prepare(). --AG 2017-02-09 18:53 GMT+03:00 Yakov Zhdanov : > Wow! This is the regression (from long ago version) if true. > > As far as having mbean to manage eviction policy on the fly - why not? This > is handy. >

Re: Custom thread pools for compute tasks

Vladimir, I like the idea of compensating threads with new ones. However, I do not see why users should notify Ignite when a new distributed operation is started because Ignite already is the task executor. We can intercept (virtually) all such calls and adjust pool size automatically. No need to

Re: general question

Aleksei, This processor handles various @*Resource (@IgniteInstanceResource, @CacheNameResource, ...) annotations for user-supplied objects, such as tasks, jobs, entry processors, etc. --AG 2017-02-13 12:42 GMT+03:00 voipp : > Hi, all ! What is the use of GridResourceProcessor ? And its inject(

Re: binary output from cache

Aleksey, It can give a performance benefit for example if you access only a subset of the fields of a large object. In this case, deserializing only required fields is much faster than deserializing the whole object. --AG 2017-02-10 10:26 GMT+03:00 ALEKSEY KUZNETSOV : > How could it give perfom

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

without reflection. It means > if I try to use two exception: one with "readyFut" and second without > "readyFut", I see no way to do it in this place. > > Perhaps I misunderstood your original idea. Or maybe this code some kind > of a crutch and should be removed. What do

Re: Transaction semantics questions

+ My 5 cents: When a transaction uses one-phase commit optimization, there is no difference between PRIMARY_SYNC and FULL_SYNC. 2017-02-08 21:50 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Thanks! > > -Val > > On Tue, Feb 7, 2017 at 8:43 PM, Yakov Zhdanov wrote: > > > Val,

Re: Unexpected behavior of DiscoveryCustomMessage acks

I think we should have duplicate filtering logic in discovery manager. As far as I remember, we wanted custom events to be consistent with other discovery events and we rely on the fact that node joined and node left event won't be received twice. 2017-02-03 14:40 GMT+03:00 Sergey Chugunov : >

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

ed to > commit transaction " + > "(transaction has been rolled back on backup node): " + req.version(), > *cause*)); > __ > > How do you unsure that *"cause"* can't come to > GridCacheUtils#retryTopologySafe(final > Callabl

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexander, Do you have a use-case in mind which results in IgniteTopologyException thrown from public API with retryFuture unset? retryFuture makes sense only for certain cache operations and may be set only in certain places in the code where we already know what to wait for. I do not see how yo

Re: ScanQuery shows poor performance.

Andrey, >From the top of my head I would guess that this is done so because keyIterator handles on-heap, off-heap and swap, while entrySet() return only on-heap entries. Please check that your change does not break iteration with off-heap and swap enabled (if it does, it just means that we need to

Re: Transactional tasks

Alexei, Can you describe the semantics of the task in greater detail? * What if two jobs on different nodes access and try to put the same key? (this can be resolved by allowing a job only access local primary keys) * How do you define the lock acquisition order and prevent deadlocks? I assume t

Re: Updates reordering in transaction with cache store

Generally I agree with Yakov here, now order of updates is fully consistent with the order of cache locks acquisition. You change the transaction type => you change the order of cache locks => you change the order of db writes. I can assume that in some cases such a reordering may be useful, howev

Re: IGNITE-4157 improvement patch available

Sergey, thanks for the careful work! I've merged your contribution to ignite-2.0 branch. On Dec 16, 2016 11:50, "Sergey Chugunov" wrote: > Folks, > > I finished development on IGNITE-4157 > *Use discovery custom > messages instead of marshaller

Re: Partition data lost event

Val et al, Currently partition lost event is fired on nodes which should become partition owners, but did not find other partition owners to rebalance data from. In your example one of the node should have became an owner for partitions 1, 3, the other - for partitions 2, 4 (according to the affin

Re: IGNITE-4487 - NPE on query execution

config. If you need to change ignite configuration, override the getConfiguration(String) method * Do no start threads manually. For async test operations we have many GridTestUtils#...Multithreaded() methods 2017-01-09 11:07 GMT+03:00 Alexey Goncharuk : > Alexander, > > I left my commen

Re: Ignite 2.0 tasks/roadmap

utdated for now. Apache Ignite > > still > > > uses 4.1.0 released two years ago. Could we include to the list of > issues > > > for the release 2.0 to update to latest stable version (4.3.4 at the > > > moment)? > > > > > > On Tue, Nov 1, 2016 at

[jira] [Created] (IGNITE-4551) Reconsider cache key/value peer class loading

Alexey Goncharuk created IGNITE-4551: Summary: Reconsider cache key/value peer class loading Key: IGNITE-4551 URL: https://issues.apache.org/jira/browse/IGNITE-4551 Project: Ignite Issue

Re: DDL implementation details

> > Right, however, this section of the docs > > https://apacheignite.readme.io/docs/jcache#section-dynamic-cache > > does not clarify Ignite's behavior regarding dynamic caches when a new > node joins the cluster. Will it just pick up dynamic cache > configurations from the peers without being exp

Re: IGNITE-4302 discovery messages to exchange binary metadata - design proposal

Vladimir, Given that metadata updates will be initiated with DiscoveryCustomEvent, I see no problems neither with total message ordering (the order will be the same on all nodes and consistent with discovery events) nor with failover - the event is marked with @TcpDiscoveryEnsureDelivery, so the e

Re: DDL implementation details

Alexander, Will we keep the old option to have multiple tables in one cache? If so, how will create table statement know which cache to choose? It seems to me that to be consistent with the current DML implementation we should have a CREATE SCHEMA statement which will define the cache and cache c

Re: Empty cache memory overhead

count * node count * assignment factor > > Assignment factor depends on topology version and > IGNITE_AFFINITY_HISTORY_SIZE, default 6-7. > > Real values: > > GridAffinityAssignmentCache = 16_000 > GridAffinityAssignment = 112_000 > > I think the implementation should be changed in the way the object counts > should depends on cache data size. And the small (or empty) caches should > be more lightweight as possible. > > -- > Thanks, > Alexandr Kuramshin > > > -- Alexey Goncharuk Lead Architect GridGain Systems, Inc. www.gridgain.com

[jira] [Created] (IGNITE-4536) Update metrics for new offheap storage

Alexey Goncharuk created IGNITE-4536: Summary: Update metrics for new offheap storage Key: IGNITE-4536 URL: https://issues.apache.org/jira/browse/IGNITE-4536 Project: Ignite Issue Type

[jira] [Created] (IGNITE-4535) Add option to store deserialized values on-heap

Alexey Goncharuk created IGNITE-4535: Summary: Add option to store deserialized values on-heap Key: IGNITE-4535 URL: https://issues.apache.org/jira/browse/IGNITE-4535 Project: Ignite

[jira] [Created] (IGNITE-4534) Implement offheap eviction policies based on page memory

Alexey Goncharuk created IGNITE-4534: Summary: Implement offheap eviction policies based on page memory Key: IGNITE-4534 URL: https://issues.apache.org/jira/browse/IGNITE-4534 Project: Ignite

Re: IGNITE-4487 - NPE on query execution

l-request> > >> > >> — > >> Denis > >> > >>> On Dec 29, 2016, at 3:45 AM, Александр Меньшиков > > >> wrote: > >>> > >>> Alexey, I'm already make pull request where throw exception in that > >> place. >

PageMemory approach for Ignite 2.0

Folks, I pushed an initial implementation of IGNITE-3477 to ignite-3477 branch for community review and further discussion. Note that the implementation lacks the following features: - On-heap deserialized values cache - Full LOCAL cache support - Eviction policies - Multiple memory pools -

Re: IGNITE-4487 - NPE on query execution

I think that If fallbacks(...) returns an empty nodes collection, then we should fail with an exception. 2016-12-28 22:06 GMT+03:00 Denis Magda : > Alexander, added you to the contributors list. Please check that you can > assign the ticket on yourself. > > — > Denis > > > On Dec 28, 2016, at 2:1

Re: What branch to use for Apache Ignite 2.0 development?

+1 to have a separate branch for 2.0 and keeping master clean from breaking changes. I think 2.0 should be merged to master only after first 2.0 release, when it really becomes the main development branch. 2016-12-07 12:36 GMT+03:00 Sergi Vladykin : > I think it is good idea to be able to continu

[jira] [Created] (IGNITE-4337) Introduce persistence interface to allow build reliable persistence plugins

Alexey Goncharuk created IGNITE-4337: Summary: Introduce persistence interface to allow build reliable persistence plugins Key: IGNITE-4337 URL: https://issues.apache.org/jira/browse/IGNITE-4337

[jira] [Created] (IGNITE-4335) Implement cluster ACTIVE/INACTIVE state

Alexey Goncharuk created IGNITE-4335: Summary: Implement cluster ACTIVE/INACTIVE state Key: IGNITE-4335 URL: https://issues.apache.org/jira/browse/IGNITE-4335 Project: Ignite Issue Type

Re: TX savepoints

We also should define savepoint behavior and API rules for each of the transaction concurrency and isolation types. * Should rollbackToSavepoint() always release locks or clear saved optimistic versions? * Are forward-rollbacks allowed, e.g. try (Transaction tx = ignite.transactions().txStart()

Re: Ignite 2.0 tasks/roadmap

> solution > >>>> for > >>>>>>>>>> it. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>

[jira] [Created] (IGNITE-4157) Use discovery custom messages instead of marshaller and system cache

Alexey Goncharuk created IGNITE-4157: Summary: Use discovery custom messages instead of marshaller and system cache Key: IGNITE-4157 URL: https://issues.apache.org/jira/browse/IGNITE-4157 Project

Re: new contributor

Hi Sergey, Welcome to Apache Ignite community! I've added you to the list of contributors. You should now be able to assign this ticket to yourself. Thanks! AG

Re: Default hash code generation strategy for new binary objects

29 20:16 GMT+03:00 Dmitriy Setrakyan : > > > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda > > wrote: > > > > > >> Alex, > > >> > > >> A minor note regarding this > > >> > > >> > On Sep 29, 2016, at 8:39 AM, Ale

Re: Default hash code generation strategy for new binary objects

e > > method having following signature: > > > > int computeHashCode(BinaryObject binObj) > > > > Cache configuration will then get a new corresponding param - probably > > a class/class name to instantiate resolver from. > > > > 2. Introduce default res

Re: Default hash code generation strategy for new binary objects

19:07 GMT+03:00 Dmitriy Setrakyan : > Alexey, in your opinion, what will be faster, the binary array comparison > or field-by-field comparison? > > On Thu, Sep 29, 2016 at 8:39 AM, Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > Folks, let me point out

Re: Default hash code generation strategy for new binary objects

Folks, let me point out a few obvious (or not) things A set of fields participating in hashCode and equals is impossible to change without cluster restart. Imagine a new client adding a field F to key structure (A, B) so that new key is (A, B, F). In this case key (1, 2, 0) will be treated as a di

Re: Simulating network outages

Hi, As a starting point you can take a look at org.apache.ignite.spi.discovery.tcp.ServerImpl#forceNextNodeFailure which forces DiscoverySpi to drop next node from the topology (not sure if this is what you need). Another idea is to create a test discovery SPI which will terminate all it's threads

[jira] [Created] (IGNITE-3671) Ignite profiling interface

Alexey Goncharuk created IGNITE-3671: Summary: Ignite profiling interface Key: IGNITE-3671 URL: https://issues.apache.org/jira/browse/IGNITE-3671 Project: Ignite Issue Type: Wish

Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default

> > >> > On Aug 2, 2016, at 7:09 AM, Vladimir Ozerov < > > > > > voze...@gridgain.com > > > > > > > > > > > > > > > >> wrote: > > > > > > > > >> > > >

Re: [VOTE] Apache Ignite 1.7.0 RC1

+1 (binding) --AG 2016-08-04 5:08 GMT+03:00 Andrey Novikov : > +1 > > -- > Andrey > > On Thu, Aug 4, 2016 at 2:38 AM, Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > +1 (binding) > > > > -Val > > > > On Wed, Aug 3, 2016 at 12:32 PM, Denis Magda > wrote: > > > > > +1 (binding

Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default

specify a hashCode in insert statement, or force him to use our "automatic" algorithm of hashCode calculation in his key objects. Both ways look fishy to me. 2016-08-02 2:20 GMT+03:00 Dmitriy Setrakyan : > On Mon, Aug 1, 2016 at 10:01 AM, Alexey Goncharuk < > alexey.goncha.

Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default

Dmitriy, The question is how do you calculate the value of the hashCode? Do you want it to be specified explicitly in INSERT statement? 2016-08-01 19:47 GMT+03:00 Dmitriy Setrakyan : > Alex, > > In your case, why not just explicitly set hashcode every time you create an > object? There is Binary

[jira] [Created] (IGNITE-3616) Drop failed nodes from topology after a configured timeout

Alexey Goncharuk created IGNITE-3616: Summary: Drop failed nodes from topology after a configured timeout Key: IGNITE-3616 URL: https://issues.apache.org/jira/browse/IGNITE-3616 Project: Ignite

Re: Failed to wait for initial partition map exchange

The ticket is created: https://issues.apache.org/jira/browse/IGNITE-3616 2016-07-15 1:51 GMT+03:00 Alexey Goncharuk : > Alexey, I like the idea in general, but killing non-responsive nodes seems >> a bit drastic to me. How about this approach: >> >> - print out IDs/IPs of no

[jira] [Created] (IGNITE-3607) Send non-filtered continuous query notifications in one message per client

Alexey Goncharuk created IGNITE-3607: Summary: Send non-filtered continuous query notifications in one message per client Key: IGNITE-3607 URL: https://issues.apache.org/jira/browse/IGNITE-3607

Re: JetBrains Annotaions usage.

According to the JLS [1], adding or removing annotations has no effect on the correct linkage of the binary representations of programs in the Java programming language. Even if these annotations were RUNTIME, a user could successfully use Ignite unless he explicitly uses those classes in runtime.

Re: IGNITE-2294 implementation details

Suppose I have a PersonKey {int id;} class and Person {@SqlQueryField int id; @SqlQueryField String name; @SqlQueryField int age;} class. How would an insert statement look like? INSERT INTO Person (_key, _val) values (...) INSERT INTO Person (_key, _val, id, name, age) values (...) -> Obviously w

Re: IGNITE-2294 implementation details

For me the main question here is how we define Key and Value for a cache when using SQL interface. Unless we are going to re-architect the whole Ignite, it will still be a key-value storage in the first place, so whenever we do an INSERT, we must generate Key and Value. Given that values in INSERT

Re: Rework "withAsync" in Apache 2.0

Big +1 on this in general. I would also relax our guarantees on operations submitted from the same thread. Currently we guarantee that sequential invocations of async operations happen in the same order. I think that if a user wants such guarantees, he must define these dependencies explicitly by

[jira] [Created] (IGNITE-3499) GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented

Alexey Goncharuk created IGNITE-3499: Summary: GridCacheReplicatedFullApiMultithreadedSelfTest1 is commented Key: IGNITE-3499 URL: https://issues.apache.org/jira/browse/IGNITE-3499 Project

[jira] [Created] (IGNITE-3500) Generate expiry event in GridCacheMapEntry#checkExpired()

Alexey Goncharuk created IGNITE-3500: Summary: Generate expiry event in GridCacheMapEntry#checkExpired() Key: IGNITE-3500 URL: https://issues.apache.org/jira/browse/IGNITE-3500 Project: Ignite

[jira] [Created] (IGNITE-3498) Possible race leaving an untracked near entry

Alexey Goncharuk created IGNITE-3498: Summary: Possible race leaving an untracked near entry Key: IGNITE-3498 URL: https://issues.apache.org/jira/browse/IGNITE-3498 Project: Ignite Issue

Re: Apache Ignite - New Release

Looks like the ticket for removing _key and _value from selct * is a good candidate for 2.0. 2016-07-15 5:12 GMT-07:00 Sergi Vladykin : > We will not be able to just change this, because it will brake > compatibility. Still I believe that an option to define our SQL tables > without _key and _val

Re: Failed to wait for initial partition map exchange

> > Alexey, I like the idea in general, but killing non-responsive nodes seems > a bit drastic to me. How about this approach: > > - print out IDs/IPs of non-responsive nodes at all times > - introduce a certain kill timeout for non-responsive nodes (-1 means > disabled) > - the timeout should be a

Re: Ignite 2.0 tasks/roadmap

> > > > > I know there is IgniteDataStreamer for writing cache, but how about > > reading cache as stream for iterate all elements with scan performane > 1-3M > > tuple/sec? > > > > We already have Scan queries which allow for paginated iteration with > filters. Are you suggesting something beyond

Re: Ignite 2.0 tasks/roadmap

​Great stuff! Guys, please go ahead and file corresponding tickets or reassign the fix version to 2.0 if a ticket exists so that we keep track of the scope. It would also be great if you review the ones I created and see if they make sense.

[jira] [Created] (IGNITE-3484) MVCC for cache data structures

Alexey Goncharuk created IGNITE-3484: Summary: MVCC for cache data structures Key: IGNITE-3484 URL: https://issues.apache.org/jira/browse/IGNITE-3484 Project: Ignite Issue Type: Sub-task

Re: Failed to wait for initial partition map exchange

This is a cross-post from a user list. We faced this issue for a lot of times before and got a lot of users complaining about the whole cluster freeze. We can protect a cluster from such a situation simply by dropping non-responsive nodes from the cluster. Of course, we need to get to the bottom o

Re: Ignite 2.0 tasks/roadmap

So, no excitement about Ignite 2.0? :) I went ahead and created a 2.0 version in Ignite Jira, and included the following tickets so far based on the chance that this ticket will require breaking changes in APIs/Configuration - IGNITE-3469 - Get rid of deprecated APIs and code - IGNTIE-3477 - Rew

<    4   5   6   7   8   9   10   11   >