You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2015/01/19 17:05:25 UTC
Re: [OT] persisting sessions best practices
-----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?
> 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?
> 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.
2. Dump its database to disk. If you restart, you lose everything.
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.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] persisting sessions best practices
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dan,
On 1/19/15 11:46 AM, Daniel Mikusa wrote:
> On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>>
>> Some things [memcached] 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.
Interesting. I also considered Voldemort, but honestly I was looking
for something that was likely to be higher-performing than a Java hash
map :) (/This/ from a Java programmer!)
>> 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.
Cool.
>> 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.
Yeah, memcached does not have that. There are ways to hack-out some
keys but there is no command to list anything.
> 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.
Well, in memcached values are binary, so you can stuff anything you
want in there.
You can serialize a whole object tree if that's what you want to do. I
can imagine that memcached + JSON is a popular combination. We just
put plain-old binary values in as keys at this point, but assuming you
can serialize to bytes (like always!), you can store anything you want
in memcached.
But it's not like a formal column-store like Cassandra, etc. where the
storage mechanism understands a bit about the structures being stored.
It's basically an implementation of Map<byte[],byte[]> and we treat it
like it's Map<byte[],Integer> because we are not really even using the
values themselves; just the keys for quick lookup.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUvVnRAAoJEBzwKT+lPKRYi9wQAJJ6rYClvss+i4/sGGaCQQXZ
MJbVpI7tkcIaz/PFOcK7o5yJXl5F+trdMnfkIM2VGV21fvbRBe28u1c6EeA8yd8P
mmuXeLjZnOSPmKngR6LgtxSC8/IAba18DeuiDBkQ/Jgw207BXBZul8ELzm1H0ihF
B8GtWv5BgvASIl7r+8MX793rfBc2qDmyfV5f56EhyodZKPuBQ+nYBwZZWoNOZN38
NxC3bs9U5+MCimVPqU8CF11m+gJXaV/sK1wqrDFJP0watHHyLJ7kHpN35RU4TeSF
mYTYbQUxPKPaIZ+dPeo2yJZJadHZ4K3IX3vC9cgIz5sayTTl6esTMclzYCGMrFBI
BRj9EywYCSWdgo7ZG6p3lZPjmXSe/oEEAt00YolpnR/jyjkyzMT/k+GoS4+1n81A
QmV0U95i3i+D6E2RCR9YGa2O1yFhk5H9BuTYq+E831vrVP+XICP6vugICYdy5KUv
IPghVDlYoUuKSe7KDDNKvKnoLKC755OHg18spjlBRsTESVm1Ht1+yscaAtlbEwWB
TeZDfLsezIns6rp/9/qt6vB9g1zTZSNvepYB3cNKBabhj7lMd0K6Zdu4bvEpxLOO
dnrEXFzByG8vQ0mi/NAWcBBZJfcDMo4IHngqi3MDFUITHukxOg1TKa2238Rxi6If
3o5leMJ4BUfBBhnfKGn0
=JnfC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] persisting sessions best practices
Posted by Daniel Mikusa <dm...@pivotal.io>.
On Mon, Jan 19, 2015 at 11:05 AM, Christopher Schultz <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>