I am to use CouchBase as my caching layer. My caches are serialized objects and not(always) Document type or JSON values. The couchbase client(Couchbase-Java-Client-1.4.3) also uses Spymemcache jars which is the client of memcached server.
My questions are,
Should I use only Couchbas Client to cache my objects into couchbase server?
What if I use default Spymemcache client to cache ? if I use, what could be pros and conse over the using couchbase client? Can the Spymemcache client handle server nodes and node failures itself?
You should not use Spymemcached with Couchbase. You can, but I would recommend against it. First off, CouchbaseClient uses the Spymemcached jar because both Memcached and Couchbase use the memcached binary protocol for key-value operations. When we initially started writing a Java Client for Couchbase it didn't make sense to re-implement something that was already written so we used Spymemcached because it performs very well. You can think of Spymemcached as doing all of the basic stuff like sending messages and Couchbase Client as adding all of the nice functionality that makes it really easy to use Couchbase.
What if I use default Spymemcache client to cache ?
Everything goes through the cache regardless of what client you use so there is not point in using two different clients.
What could be pros and cons over the using couchbase client?
If you don't use CouchbaseClient you will be using something a lot more primitive. Think about it this way. Couchbase has spent about 3 years adding features to CouchbaseClient that make it really easy to use the Couchbase. CouchbaseClient will deal with topology changes and also adds operations that Spymemcached does not have.
Can the Spymemcache client handle server nodes and node failures itself?
No, but if you send traffic through Moxi then you will be able to deal with node failures.
I wouldn't even both with Spymemcached if your using Couchbase.
Related
I want to access Neo4j db concurrently through a rest client in java.
I have already found two clients neo4j-rest-graphdb 2.0.1 and neo4j-jdbc 2.3.2 .
Since first one is no longer maintained I'm afraid to go with it.
Can someone please tell me what is the best java rest client for Neo4j which support concurrent access?
I think what you're looking for is Neo4j-OGM
Neo4j OGM is a fast object-graph mapping library for Neo4j, optimised for server-based installations and utilising Cypher via the transactional HTTP endpoint.
It's created and maintained by Neo4j team.
Concurrency is managed by Neo4j itself, you can use any client without worrying for concurrency problem.
I am wondering what are advantages of using one client over another. Is there possibility to use MemcachedClient to connect to client side Moxi instance?
Performance. From the memcache->Membase days, Moxi handles the routing/distribution from the Couchbase cluster side, but then all your AppServers hit individual nodes of Moxi in the cluster. We have done a lot of optimizations and improvements over this design to increase performance.
One of the improvements is with Couchbase SDK's the client's themselves have a map of cluster topology so they go directly to nodes responsible for the data rather than the Moxi routing. You will find that you get a performance boost and reduced latencies by using the Couchbase SDK's!
In addition to Scalabl3 answer take a look to : http://www.couchbase.com/memcached
Can someone point me to example of Java code that can work both with Memcached server and Couchbase server. If i understand correctly one can use spymemcached for communicating with both server. Does that mean i can use same code to connect(obviously using different url) get and put values to them or there are some differences?
Any particular reason to use the memcached protocol directly?
The best practice when working with Couchbase is to use the Client SDK (many languages are supported as you can see here http://www.couchbase.com/develop , including Java) ?
The reason why it is better to use the SDK (and for the same reason you have to use Moxi) is because to be able to support the clustering from your application.
You client SDK will direct the operations to the correct cluster nodes, but also the cluster map will automatically be updated when you add new nodes (or when nodes are failing).
The Java SDK tutorial will guide you through the different steps of developing an application using Couchbase:
- http://www.couchbase.com/docs/couchbase-sdk-java-1.1/tutorial.html
So, can you use the Java client SDK?
According to the couchbase documentation it support textual memcached protocol. So you can use any of the available java memcached client and reuse the same code used for memcached. Couchbase supports memcached protocol only through moxi.
Question:-
Does java client need to worry about multiple servers ?
Meaning:-
I have given two servers in memcached client, but when i set or get a key from cache, do i need to provide any server related info to it or memcache itself takes care of it??
My knowledge:-
Memcache itself takes care due to consistent hashing.
but does spymemcached 2.8.0 provides consistent hashing???
Memcached servers are pooling servers. Meaning that you define a pool (a list) of servers and when the Java client attempts a write it writes towards the pool.
It's the client's job to decide which server from the pool will receive and store the value and how it will retrieve the value from that pool.
Basically this allows you to start with one Memcached server (possibly on the same machine) and if push comes to shove you can add a few dozen more servers to the pool without touching the application code.
Since the client is responsible of distributing data across the pool of servers (the client has to choose right memcached server to store/fetch data) there are few distribution algorithms.
One of the simplest is modula. This algorithm distributes keys depending on the amount of memcached servers in pool. If the number of servers in the pool changes, the client won't be able to the find stored data, there will be cache misses. In such case it's better to use consistent hashing.
Most popular java memcached clients spymemached and xmemcached support consistent hashing.
In some use cases instead of directly using the memcached client, caching can be added to a spring application through AOP (interceptors) using simple-spring-memcached or Spring 3.1 Cache Abstraction. Spring Cache currently doesn't support memcached but simple-spring-memcached provides such integration in snapshot build and upcoming 3.0.0 release.
MemCached server will manage to store and retrieve key/value by itself.
While storing using hash generate the key and store it.
While retrieve again hash the given key and find on which server it has been stored and then fetch it, this will take some time.
Instead, there is one approach which can be used for storing and retrieving.
Create one HashMap and store the key with server address as value. Now next time if the same key needs to get then instead of searching, you will get the server address directly from the HashMap and you needs to fetch value from there only. Hence you can save the searching time of MemCahce server.
Hope you understand what i mean.
I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.
Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.
RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.
I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.
It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.
Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions
Use Spring....Then pick and choose the protocol.
We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.