RE: Using annotations to remap fields when deserializing BinaryObjects

Hi, Well one (weak) reason is that somebody else could already have put data to a cache using the "dash" convention, and in that case we are unable to retrieve this data (eg. how can we (automatically) deserialize the "user-name" field?) also, allowing this mapping would be in line with

Using annotations to remap fields when deserializing BinaryObjects

Hi, is it possible to deserialize cache entries to Java objects, and specify field names mapping using annotations? In example, let's say cache entries follow a "with-dashes" naming convention: binaryObject.toString() = "domain.User[id=... idHash=... user-name=Paul ]" And I deserialize it with

Call to getCache never returns on CLIENT_NODE_RECONNECTED event

Hi, I am trying to implement a mechanism so that clients can recover from a full cluster shutdown. Basically on CLIENT_RECONNECTION, my code closes a QueryCursor and then tries issuing another query. The reconnection handling code is executed by a "disco-event-worker-#..." thread; and when

Re: Re-deploying a continuous query after all server nodes restart

Hi, thanks for replying! I double-checked my case, and (I was quite wrong); the client keeps receiving updates from the CQ after the first server is restarted. (maybe it could be useful to add a case in the examples section, like "ContinuousQueryFailover"? I could try doing that eventually)

Re-deploying a continuous query after all server nodes restart

Hi all, I'd like to understand how to determine that a continuous query (CQ) needs to be re-created, in case of multiple server restarts. My understanding for the following case is: if an ignite client joins a cluster (composed by server-A only) and deploys a CQ to the cluster, server-A will

Re: Server OOM at startup

The process was started with the CMS GC- -XX:ParallelGCThreads=4 -XX:ParallelCMSThreads=4 -XX:SurvivorRatio=6 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseGCTaskAffinity -XX:MaxTenuringThreshold=6 -XX:+AlwaysPreTouch -XX:CMSWaitDuration=30 -XX:+CMSScavengeBeforeRemark

Server OOM at startup

Hi all, I am running an instance of ignite server, but I have an OOM at startup. I am starting Java with -Xmx4G , so am not expecting an OOM. Persistence is enabled, and I understand it is allocating space for the WAL; I tried limiting the data region size with the config below; but I still have

Re: Key fields are not part of the value object

Hi Val, I suppose that makes sense; we'll need to either use the whole entry, or to duplicate the fields for this specific use case. Thank you for clarifying this point! -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Key fields are not part of the value object

Hi, thanks for replying- Actually, even though we can use the SQL facilities to inspect the caches, the intended usage is to have Java clients, and possibly using the jcache api to access the data; so I really need to use cache.get(key). I looked further into this; for this very same cache, if

Key fields are not part of the value object

Hi, I declared a test table with four fields, two of these are key fields. When querying the cache using the Java api, the "value" BinaryObject does not contain the key values, whereas using SQL all fields are shown. That is, after running: create table test (a int, b int, c int, d int, primary

Re: What is the precise definition of classes eligible for P2P-classloading?

Hi Dmirty, thanks for replying. I just realized that the p2p-classloading will behave differently, if I create a remote filter using these two alternatives: qry.setRemoteFilterFactory( new MyRemoteFilterFactory() ); qry.setRemoteFilterFactory(FactoryBuilder.factoryOf(

What is the precise definition of classes eligible for P2P-classloading?

Hi, I have enabled p2p classloading, and this works well when submitting compute code, eg. IgniteCallable-s. On the other hand, it seems that p2p-classloading does NOT import data classes, is that right? (So, I think I will put data classes on the servers.) Regarding classes that are indeed