On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Daniel, > > On 1/19/15 9:21 AM, Daniel Mikusa wrote: > > I've not personally used memcache, but I have used redis, so I > > guess that's a similar approach. > > Are you using Redis for session persistence? > Yes, but I have used it for other things. It's a good project. > > > The technology was a nice fit, but it didn't seem like a huge win > > versus the out-of-the-box session replication. Both worked and > > both were fast enough for what I needed. I stuck with the > > out-of-the-box stuff because it's distributed and replicated by > > default and didn't require an extra server. > > Aah, so you evaluated it and discarded it as an option for sessions > because it didn't offer much over what comes with Tomcat? > Basically. I was curious and tried it out. It worked fine, although I can't say I tested it exhaustively. Main reasons I stuck with clustering support in Tomcat are a.) it's all include with Tomcat, no additional JAR's or code needed b.) I'm very familiar with it's configuration & troubleshooting c.) no additional server needed and d.) session data is automatically distributed across multiple nodes with Tomcat, for Redis I'd have to set that up or live with it being a single point of failure. > > > Where I've mainly used redis is in restricted environments where > > direct communication from one node to the other is not possible, > > like in some "cloud" environments, or when it's not as easy to > > setup like when multicast is disabled. > > I'm curious because I looked at a handful of packages for this kind of > thing (we are storing authentication nonces that need to be accessible > from all of our Tomcat servers) and we settled on memcached if only > for its simplicity and solid reputation. > > Some things it cannot do: > > 1. Replicate to other nodes. You can do sharding, but it's pretty > low-brow and the shards don't actually know about each other. > All of the smarts are in the client. The server doesn't do any > of this. Evidently, there are some flavors of memcached that > have been hacked to provide replication to other nodes, but > it's not part of the main distribution and didn't seem ... safe. > I believe the situation with Redis is similar. There some ways to do this with the stable 2.x release, but those have their are drawbacks. There's official clustering support in 3.0, which is still beta, though. It's supposed to resolve these issues. > 2. Dump its database to disk. If you restart, you lose everything. > You can save state with Redis. It's pretty flexible about how you configure it too, giving you different trade-offs between durability and performance. > > 3. Allow you to browse. Basically, if you know an item's key, > you can fetch its value. If you don't, you are out of luck. You > can't just poke around looking for things. There is no > equivalent of "SELECT * LIMIT 5" just to see what's in there. > I think you'd be looking for the "KEYS" command. http://redis.io/commands/keys This is off topic, but it's really why I like Redis so I'm going to share. With Redis, not only can a key point to a value, but it can also point to other data structures like sets, lists, hashes and sorted sets. Something I've found to be very handy. Dan > > Does Redis do any of the above? > > Honestly, I think what Tomcat needs is a session manager for Cassandra > or something similar: something intended to be a primary data store > and not a cache (like memcached is). > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJUvStFAAoJEBzwKT+lPKRYXP8P/iQknECivamRE2+XPH9KSnzh > BMwnq1TudZ20qFZbwnxA33Yli4DwEM6Sug7mph+R3iDVgqkR5srMfNeGUciwwFN7 > 4IUObktVQxg21VbSachilfi2Aat33FYTlmtHf+plDQAr0ig41pOKhujuF6pWWM3V > RNJZQgmAivQXgA86RavIaVX+7x4HeB+w8iTYQm6dGbCpTWIADeqBuT358dTKRX+D > Ricvs1M7C37LJNCyymKSgKlxAf7MF39viW9lHBsMp45o166vWcAGjj6juNuXDyBD > xdk6UbkqbGIQ+No1W20BQZEm7mL8cCq8NYqs6YHwf9rV3v6rP4E0CTH1ubNN4q/K > AwWtT5ijP7xA3cPxXEs7XdL6ynsMMJublk2/+V/+ctPE2XP7kfQCMBYhPSiux1Kc > ILikydk5u0X0Dudmes4r9g6+wabnR9OC6/lB3c6BRG6kOdbj+VJo+23vbUQZkAHt > lCVjjTirrvb6YLXuv+IXUomAlLn7bzQ39M1L1UO5wsRUd2kICnpZ7G5Cs3n5r98B > WWSBLvChvez/hnt2HP3PlTBstW06R1Ds9FvkSMtVoO3roQSPEx6b1QCEsnw1NXCL > SvAgN43FzXZxOyr+ZohGzUhSELXQI5v7pV6p3Bj+tMrAL/+fzMiS4KoJqDWc7/nB > 3NlP1g/7RN1IYnLkFm+q > =Po13 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
