850375 wrote:It is better to reuse a single instance of the KVStore handle. Each handle carries a lot of state so you don't want to needlessly recreate that (and the overhead of maintaining) it with new or shared handles.
I would like to bring up this old topic again.
KVStore - thread safty and reuse
I understand that kvstore is thread-safe. However, I am interested whether there is any difference in performance when using one vs. multiple kvstores.
Let's say I have an app which has 5 threads continuously writing to NoSQL. I wonder whether it's better to give the same instance of kvstore to all of these threads, or make each thread instantiate its own kvstore. Does anyone have any experience to share?
I have a situation where I am trying to figure out what is the best practise for creating the the store handle when multiple threads are used to store a high rate of data. (In db terms make a connections to the database and then reusing the connections)
Here is my scenario, I have a number of workers that each run in its own thread that process and stores a message in a NoSQL Store. The message broker receive about 500 msg/ sec. I have done a bit of profiling and saw that even if I don't call the "put" method, a lot of memory is still occupied by the store (keeping state etc). I have since before reading this article changed my Workers to each create a store handle. Each of these workers is part of a Load balanced Message Broker and they are only supposed to do work once they are available ( My reason for not sharing only one handle to the store - I have done that before and found some out of memory issues)
Now my question is:
At the rate I am receiving and storing messages it is not practical to "open" and "close" a connection each time a message needs to be stored, What is the correct way or pattern to create the handle and make sure that unused objects are destroyed so that the heap is kept clean ?
Any suggestion for keeping the store handle, and storing at a high rate will be appreciated.
PS: Batching or queuing of message batches is not an option as the data needs to be available as close to real time as possible
I have tried that, both scenarios work (One store handle or one shared). I have also tested both scenarios and running the Netbeans profiler it appears that there (Over time) is a memory leak in the java.net.SocksSocketImpl that seems to be caused by the oracle.kv.impl.api.rgstate.RepNodeStateUpdateThread$ResolveHandler, It almost appears if there is connections to the store that doesn't get closed and then collected by the GC. Any ideas that I could look at. I have changed my threading model a bit and I also looked at changing some of the JVM options to for optimization of the GC.
Note: I am saving about 500messages/sec at a 3 Node Cluster (HP Prolient Micro servers running Ubuntu )
Any ideas how I can test, verify and confirm this ?