I have downloaded infinispan 7.2.5 version and created a simple server in a cluster mode. I have placed it in a jboss folder(locally) and started the server. I have created a simple client that puts the data into the cache and another client that gets the data from the cache in eclipse.
what I have observed is in a cluster mode when I fetch single value that is not present into the cache, using getAll() method, getHits method give me 1 count (Ideally it should have been miss 1) also when I try to get a value which is already present into the cache, getHits method shows count as 2.
Also in a standalone environment when i fetched a single value from cache using getAll() method which is not present I get getMisses() method count as 1 (which is expected) but again in standalone mode also when I try to get a single value which is present in cache I get getHits method count as 2.
This is really confusing me as why this is happening. while other get() methods of infinispan behave in an expected way. This seems to happens only with getAll() method.
why is this happening?
Related
I have a microservice to wrap the access to a MongoDB (DaaS). It is implemented with Spring Data Reactive Repository (ReactiveMongoRepository).
I have deployed within a docker image, running on Kubernetes (in Google Cloud). I have configured the orchestrator to keep a minimum of 2 pods of my microservice (and a maximum of 4).
In other microservice, I have implemented a batch process with multithreading, where I call my daas, with the following sequence:
findById
Modify some fields (including increments of counters)
save
Here is the relevant code:
public Mono<Element> updateElement(String id) {
return this.daasClient.findById(id)
.map(elem -> modify(elem))
.flatMap(elem -> this.daasClient.save(elem));
}
When there are lots of operations, each pod runs some of then (including the previuos code), so I have seen that the access to the resource (Mongo) is not thread safe, so the resut is not as expected.
I guess, 2 pods run the findById simultaneously, so the update is not to the "real" document, so, the last in invoking the save method overrides the changes of the other.
Anybody know how I could do to avoid this, i.e., to implement this operation in thread-safe (pod-safe) way?
Thanks
There is a question on stackoverflow, but in my case I run the nodes from console: deployNodes, runnodes. So there is no StartedMockNode class to use transaction{} function
What’s wrong with it and how can I fix it?
Here is the method throwing the exception
serviceHub.withEntityManager {
persist(callbackData)
}
Debugged this through with Hayk on Slack.
DB transactions are handled by corda. These transactions are only generated at two points. During node startup so corda services can invoke database queries and inserts and inside of flows.
In this scenario, the database was being accessed from outside of node startup and a not during a flow's invocation.
To circumvent this, a new flow needs to be created that handles the db operations that were causing the error. The db operation can still be kept inside of a corda service but it must be called from a flow.
This flow does not need a responder. It should be annotated with #StartableByService and should not need #InitiatingFlow (need to double check that one). The contents of call simply call the db operation and return the result back to the caller.
TLDR - all db operations must be called from inside a flow or during node startup.
I'm having what I think is a memory leak with spring-data-mongodb.
Basically we're using MongoDB as a sort of cache for a RDBMS, so when the application starts we load a big chunk of the database.
So basically we are mapping/denormalising different JPA Entities to Mongo documents using different "mapping" methods like this one :
#Override
public void insertFromContacts(Set<Contact> contacts, Long seed){
MutableLong sfId = new MutableLong(seed);
List<SocialInfo> socialInfos = contacts.stream().map(c -> {
SocialInfo socialInfo = new SocialInfo();
socialInfo.setId(sfId.longValue());
socialInfo.setSearchOnly(true);
socialInfo.setStatus(null);
socialInfo.setContactId(c.getId());
sfId.increment();
return socialInfo;
}).collect(Collectors.toList());
mongoTemplate.insertAll(socialInfos);
}
However the memory does not stop growing, so I did a heap dump and I realise that spring is keeping a huge amount of BasicDBObject references in memory and I don't know why?
When checking the shortest path to the accumulation point it shows that is apparently the earlyApplicationEvents property of the class
I'm using :
- Java 8
- Spring data mongodb 1.10.8.RELEASE
- Spring data commons 1.13.8.RELEASE
- Spring 4.3.6.RELEASE
Any ideas as why?
If you track down the usage of the field earlyApplicationEvents, it is basically for holding onto events during startup until the listeners can be registered, at which point it will get set to null. See here: https://github.com/spring-projects/spring-framework/blob/e7b77cb2b6c699b759a55cd81b345cca00ec5b64/spring-context/src/main/java/org/springframework/context/support/AbstractApplicationContext.java#L828
You mention that you do the processing at start-up so I guess this prevents registration of the listeners until your process finishes.
If you move that initialization code further back until after the application context is fully initialized, this should fix the issue. For example registering an event listener and react on the ContextRefreshedEvent should do the trick. The important part is to get after the call to registerListeners of the refresh process.
scenario : in Infinispan 5.3 server , application putting value in cache using Hotrod(address1:port) , but not able to get same value using infinispan rest interface(using same address1:port and same key).
e.g. put "x"="y" in infinispan cache using hotrod . trying to fetch same cached value using address1:port/rest/cachename/x but not able to get value.
Please provide input as I am new to it, also please provide example if any.
In order to store data via one interface (e.g. HotRod) and retrieve it via a different interface (e.g. REST), you need to enable compatibility/interoperability mode.
Am bit stuck by these three questions:
1) I see that diff is calculated in AutoBeanUtils's diff method. I saw a tag called parentObject in the entity which is used in the comparison to calculate diff.
parent = proxyBean.getTag(Constants.PARENT_OBJECT); in AbstractRequestContext class.
Does that mean there are two copies for a given entity thats loaded on to the browser? If my entity actual size is say 1kb, actual data loaded will be 2kb (as two copies of entity are getting loaded onto the browser) ?
2) On the server side:
Suppose I have to fetch an entity from the database, the static find<EntityName> should be such that I have to make a db call every time, or is there a way where I can fine tune that behavior? [Sorry I did not understand the locator concept very well.]
3) What happens if there is a crash on the server side(for any reason which need not be current request specific) when a diff is sent from the client?
Thanks a lot.
when you .edit() a proxy, it makes a copy and stores the immutable proxy you passed as argument as the PARENT_OBJECT of the returned proxy.
you'd generally make a DB call every time the method is called (this is the same for a Locator's find() method), which will be no more than twice for each request. You can use some sort of cache if you need, but if you use JPA or JDO this is taken care of for you (you have to use a session-per-request pattern, aka OpenSessionInView)
If there's any error while decoding the request, a global error will be returned, that will be passed to onFailure of all Receivers for the failed RequestContext request.
See https://code.google.com/p/google-web-toolkit/wiki/RequestFactoryMovingParts#Flow