Thank for your reply. From code I see that you log only entries with non
null values. If your absolutely shure that you never put null in cache - I
will create loadtest to reproduce it and create issue for you. But it will
be great, if you move logging before event.getValue! = null.
среда, 7 июня
Hi,
why you didn't use cache.size instead of cache.localSize? localSize count
only entries, stored in local node and if you ignite node connect to some
cluster this test two keys may be stored in other nodes and you get zero
local cache size... Look in logs output something like "Topology snapshot
Hi,
ignite split every cache into some number of partitions and store
partitions on cluster nodes. It decide where to store data by two step:
1) calculate partitionId by key (long in your case)
2) calculate affinity function by partitionId and cluster topology. For
every partition affinity function
Yes, if key wasn't flushed (end event wasn't collected by flusher thread to
flush) - it will be just overwritten in memory with new value (doesn't
matter what operation, i.e. insert can be overwritten to delete or visa
versa).
So in your example if WB cache get
insert k1 =0, k2=2, k3 =3 and delete
Hello Jessie,
this happen because write behind work as:
1) Store cache updates in sorted map: oldest updates go to store first, but
if you update (delete/insert, any operation with same key) key in write
behind map (cached), this operation will be coalesced (to tear down store
load), but new operat
As far as I understant you create CQ in Service.init, so node with running
service is CQ node. All other nodes from grid will send CQ events to this
node to process in your service and if you don't configure nodeFilter for
service - any node can run it, so any node can be CQ node.
But it shouldn't
If node with CQ leave grid (or just reconnect to grid, if it client node) -
you should recreate CQ, because some cache updates can happen when node
with CQ listener can't receive it. What happen it this case:
1) Node with changed cache entry process CQ, entry pass remote filter and
node try to send
Can you share you log files?
2017-05-03 19:05 GMT+07:00 begineer :
> 1) How you use ContinuousQuery: with initialQuery or without? : with
> initial
> query having same predicate
> 2) Did some nodes disconnect when you loose updates? no
> 3) Did you log entries in CQ.localListener? Just to be sure
1) How you use ContinuousQuery: with initialQuery or without?
2) Did some nodes disconnect when you loose updates?
3) Did you log entries in CQ.localListener? Just to be sure that error in
CQ logic, not in your service logic.
4) Can someone update old entries? Maybe they just get into CQ again afte
Hi,
I'm trying to reproduce it in one host (with 6 ignite server node) but all
work fine for me. Can you share ignite configuration, cache configuration,
logs or some reproducer?
2017-05-02 15:48 GMT+07:00 begineer :
> Hi,
> I am currently facing intermittent issue with continuous query. Cant rea
I think it's very interesting use case (if I understand you correctly) to
store data locally and, if client can, connect to the cluster and share
data. But for now this use case doesn't support directly and, probably, you
should put some local write behind cache before apache ignite client node
and
Hello Sweta Das!
1. It's not recommended to perform any performance tests on virtual
environment, because this environments have too many points where something
can work not as expected: memory swapping, virtual file systems, driver
problems and the effects from other virtual machines on the same h
12 matches
Mail list logo
