You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Morten Jorgensen <mo...@openjawtech.com> on 2012/04/03 10:56:52 UTC
Who wants my Cassandra session manager for Tomcat?
All,
I recently implemented a Tomcat session manager that uses Cassandra for
session storage. Cassandra is a commonly used session store for
PHP-based applications, but I could not find one that would plug
seamlessly into Tomcat. My Cassandra session manager is fully working
and has gone through basic testing.
Now I want to donate my code to the Tomcat project - if you'll have it.
I am unsure on how to proceed with this, so any direction will be very
much appreciated. I did manage the donation of XSLTC from Sun
Microsystems to the Xalan-J project at xml.apache.org way back when,
but this was more than 10 years ago and my memory isn't great...
Apologies if this is the wrong forum for this request.
Best regards,
Morten Jorgensen
--
Morten Jørgensen
Chief Architect
*OpenJaw Technologies*
T: + 353 (0)1 - 882 5444
W: www.openjawtech.com <http://www.openjawtech.com/>
Join OpenJaw Technologies Group on LinkedIn
<http://www.linkedin.com/groups?about=&gid=4074413> / Follow OpenJawTech
on Twitter <http://twitter.com/#%21/OpenJawTech>.
We have checked this material for computer viruses and although none has
been found by us, we cannot guarantee that it is completely virus free
and we do not accept any liability for loss or damage that may be
caused. Please therefore check any attachments for viruses before using
them on your own equipment. If you do find a computer virus please
inform us immediately so that we may take appropriate action.
This communication is intended solely for the addressee and is
confidential.
If you are not the intended recipient, please delete this email. Any
disclosure, copying, distribution or any action taken or omitted to be
taken in reliance on it, is prohibited and may be unlawful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Pid <pi...@pidster.com>.
On 03/04/2012 09:56, Morten Jorgensen wrote:
> All,
>
> I recently implemented a Tomcat session manager that uses Cassandra for
> session storage. Cassandra is a commonly used session store for
> PHP-based applications, but I could not find one that would plug
> seamlessly into Tomcat. My Cassandra session manager is fully working
> and has gone through basic testing.
That's interesting. Can you share some details about how it works?
p
> Now I want to donate my code to the Tomcat project - if you'll have it.
> I am unsure on how to proceed with this, so any direction will be very
> much appreciated. I did manage the donation of XSLTC from Sun
> Microsystems to the Xalan-J project at xml.apache.org way back when,
> but this was more than 10 years ago and my memory isn't great...
>
> Apologies if this is the wrong forum for this request.
>
> Best regards,
> Morten Jorgensen
>
--
[key:62590808]
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Maybe it should be posted to cassandra list?
- Romain
Le 3 avr. 2012 18:52, "Pid" <pi...@pidster.com> a écrit :
> On 03/04/2012 09:56, Morten Jorgensen wrote:
> > All,
> >
> > I recently implemented a Tomcat session manager that uses Cassandra for
> > session storage. Cassandra is a commonly used session store for
> > PHP-based applications, but I could not find one that would plug
> > seamlessly into Tomcat. My Cassandra session manager is fully working
> > and has gone through basic testing.
> >
> > Now I want to donate my code to the Tomcat project - if you'll have it.
> > I am unsure on how to proceed with this, so any direction will be very
> > much appreciated. I did manage the donation of XSLTC from Sun
> > Microsystems to the Xalan-J project at xml.apache.org way back when,
> > but this was more than 10 years ago and my memory isn't great...
>
> I can't speak for the committers/project, but one option would be to
> file an enhancement request and attach a patch in diff format.
>
> Whether it gets added or not would depend on the committers' opinion
> about the value of the feature & the impact of adding dependencies etc.
>
> Is there a community of users already, or is it too new?
>
>
> > Apologies if this is the wrong forum for this request.
>
> It's the right forum.
>
>
> p
>
> > Best regards,
> > Morten Jorgensen
> >
>
>
> --
>
> [key:62590808]
>
>
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Morten,
On 4/4/12 12:18 PM, Morten Jorgensen wrote:
> For the cache? The main reason why I use a filter is to be able to
> tie a cache object to a thread-local variable for the period for
> which the request is being processed. As soon as the response is
> streamed to the client the cache is released. If Tomcat already
> contains some internal reference to the current request then I won't
> need to use a filter in this manner. I am not a fan of thread-local
> variables, so I'd very much like to remove the dependency on having
> this filter in place.
I wonder if this Filter would fail to work properly in an asynchronous
context. You would certainly have to test that and document it
appropriately.
-chris
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Pid * <pi...@pidster.com>.
On 4 Apr 2012, at 17:19, Morten Jorgensen
<mo...@openjawtech.com> wrote:
> Thanks again for your comments. More replies below:
>>>> That's interesting. Can you share some details about how it works?
>>> Sure. It is quite simple. Cassandra is effectively a multi-level
>>> distributed hash-map, so it lends itself very well do storing session
>>> attributes.
>>>
>>> The session manager maintains two column families (like tables), one to
>>> hold session meta-data such as the last access timestamp, etc. and one
>>> column family to hold session attributes. Storing or reading a session
>>> attribute is simply a matter of writing it using the session ID as the
>>> row ID, and the session attribute name as the column name, and the
>>> session attribute value as the column value.
>>>
>>> Session attributes are read and written independently, so the entire web
>>> session does not have to be loaded into memory - only the session
>>> attributes that are actually required to service a request are read.
>>> This greatly reduces the memory footprint of the web applications that I
>>> am developing for my employer.
>> I'd be concerned about how chatty that was.
>>
>> Devil's advocate question: why store data in the session if it's not needed?
> Good question. For large web applications, and particularly web-based UIs with multiple
> user screens, you would have certain data in your session for the various screens/pages.
Not if I could avoid it, I wouldn't. I might have user data or refs
that I need for each page, but everything else goes in request scope.
> Not all pages need _all_ data in your session, and since the session manager loads session
> attributes only when the web app code asks for it, only the data that is required for the
> current page is loaded from Cassandra.
>>
>>> For improved performance I have added a write-through and a write-back
>>> cache, implemented as servlet filters. The cache is flushed or written
>>> back once the current request has finished processing. I am sure there
>>> is room for improvement here, as multiple concurrent requests for the
>>> same session should be served using the same cache instance.
>> But... (more devil's advocating, sorry) while this should address the
>> chattiness* problem, doesn't it mean that your solution is invasive and
>> can't be really deployed without modifying an app?
> The session manager works without this cache, but is slow. The cache is configured
> as a filter configured in web.xml. The code of a web app won't have to be changed,
> but you need to update your web.xml to use the session manager effectively.
Adding a Filter means modifying the app. </pedant>
>> * is that even a word?
> Yes it is, according to dictionary.com
>>
>>> The Manager does not maintain any references to Session instances at
>>> all, allowing them to be garbage collected at any time. This makes
>>> things very simple, as Cassandra holds all session state, and the
>>> session managers in my Tomcat nodes only act as a cache in front of
>>> Cassandra.
>>>
>>> The nature of Cassandra and the Tomcat's implementation of web sessions
>>> go together extremely well. I am surprised that nothing like this exists
>>> already. It is a square hole, square peg sort of scenario.
>> I'm not entirely sure I agree.
>>
>> Cassandra trades off consistency for availability and partition
>> tolerance, whereas I'd suggest a session management solution would want
>> to trade partition tolerance for consistency and availability.
>>
>> I'm also not sure that the comparison between column store and session
>> attribute map stands up beyond the initial/apparent similarity between
>> data type.
>>
>> Cassandra is write-optimised and hits disk (on at least two nodes for
>> HA) for every write AFAIK.
> Cassandra allows you choose your consistency level. I use a quorum write, which
> writes to (N/2)+1 Cassandra nodes, where the Cassandra ring contains N nodes.
But as you say, you've discovered why this is slow for a webapp, and
you have to add a cache to each request to fix it.
I'd suggest you'd be better off just loading data into the request
scope directly, rather than indirectly.
> I think this makes sense for web session data, and my current implementation
> has this consistency-level hard-coded. I think it would probably make sense to
> allow this to be configured.
>>
>>> I also have an implementation of the Map interface that stores the
>>> values of each entry as a session attribute. The way many developers
>>> write web applications is to have a "session bean" (a session attribute)
>>> that contains a Map that maintains the actual session attributes. This
>>> is OK if the entire session is persisted as a whole, but it won't
>>> perform very well with the Cassandra session manager (or the Delta
>>> Session Manager from what I understand). A developer can replace their
>>> session bean's HashMap with the SessionMap utility, and the session
>>> attributes will be treated as proper session attributes by the session
>>> manager.
>> Is there not a way to do this internally& therefore transparently to
>> the developer? Otherwise you're introducing more dependencies and
>> creating more of a framework than a pluggable manager.
> I don't think there is a clean way of doing this without overriding the default Map
> implementations of the JVM. But, I think storing session data as individual session
> attributes rather than large object hierarchies is good (but not common)
> programming practice. It allows the session container/manager to manage
> read/write operations of the session attributes separately. This practice should
> benefit not only my Cassandra session manager but also the existing Delta manager.
>>>> 1. Be relatively self-contained -- i.e. not require much in the way of
>>>> changes to existing classes
>>> There are no changes to existing classes. My session manager implements
>>> the existing org.apache.catalina.Manager interface.
>> Instead of the filter, could you use a Valve?
> For the cache? The main reason why I use a filter is to be able to tie a cache
> object to a thread-local variable for the period for which the request is being
> processed. As soon as the response is streamed to the client the cache is released.
> If Tomcat already contains some internal reference to the current request then I
> won't need to use a filter in this manner.
It must do, right?
A Valve is similar to a Filter but has access to the internal
representations of the request/session so would mean you don't need to
interfere with the app.
> I am not a fan of thread-local variables,
> so I'd very much like to remove the dependency on having this filter in place.
>
> Morten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Morten Jorgensen <mo...@openjawtech.com>.
Thanks again for your comments. More replies below:
>>> That's interesting. Can you share some details about how it works?
>> Sure. It is quite simple. Cassandra is effectively a multi-level
>> distributed hash-map, so it lends itself very well do storing session
>> attributes.
>>
>> The session manager maintains two column families (like tables), one to
>> hold session meta-data such as the last access timestamp, etc. and one
>> column family to hold session attributes. Storing or reading a session
>> attribute is simply a matter of writing it using the session ID as the
>> row ID, and the session attribute name as the column name, and the
>> session attribute value as the column value.
>>
>> Session attributes are read and written independently, so the entire web
>> session does not have to be loaded into memory - only the session
>> attributes that are actually required to service a request are read.
>> This greatly reduces the memory footprint of the web applications that I
>> am developing for my employer.
> I'd be concerned about how chatty that was.
>
> Devil's advocate question: why store data in the session if it's not needed?
Good question. For large web applications, and particularly web-based
UIs with multiple
user screens, you would have certain data in your session for the
various screens/pages.
Not all pages need _all_ data in your session, and since the session
manager loads session
attributes only when the web app code asks for it, only the data that is
required for the
current page is loaded from Cassandra.
>
>> For improved performance I have added a write-through and a write-back
>> cache, implemented as servlet filters. The cache is flushed or written
>> back once the current request has finished processing. I am sure there
>> is room for improvement here, as multiple concurrent requests for the
>> same session should be served using the same cache instance.
> But... (more devil's advocating, sorry) while this should address the
> chattiness* problem, doesn't it mean that your solution is invasive and
> can't be really deployed without modifying an app?
The session manager works without this cache, but is slow. The cache is
configured
as a filter configured in web.xml. The code of a web app won't have to
be changed,
but you need to update your web.xml to use the session manager effectively.
> * is that even a word?
Yes it is, according to dictionary.com
>
>> The Manager does not maintain any references to Session instances at
>> all, allowing them to be garbage collected at any time. This makes
>> things very simple, as Cassandra holds all session state, and the
>> session managers in my Tomcat nodes only act as a cache in front of
>> Cassandra.
>>
>> The nature of Cassandra and the Tomcat's implementation of web sessions
>> go together extremely well. I am surprised that nothing like this exists
>> already. It is a square hole, square peg sort of scenario.
> I'm not entirely sure I agree.
>
> Cassandra trades off consistency for availability and partition
> tolerance, whereas I'd suggest a session management solution would want
> to trade partition tolerance for consistency and availability.
>
> I'm also not sure that the comparison between column store and session
> attribute map stands up beyond the initial/apparent similarity between
> data type.
>
> Cassandra is write-optimised and hits disk (on at least two nodes for
> HA) for every write AFAIK.
Cassandra allows you choose your consistency level. I use a quorum
write, which
writes to (N/2)+1 Cassandra nodes, where the Cassandra ring contains N
nodes.
I think this makes sense for web session data, and my current implementation
has this consistency-level hard-coded. I think it would probably make
sense to
allow this to be configured.
>
>> I also have an implementation of the Map interface that stores the
>> values of each entry as a session attribute. The way many developers
>> write web applications is to have a "session bean" (a session attribute)
>> that contains a Map that maintains the actual session attributes. This
>> is OK if the entire session is persisted as a whole, but it won't
>> perform very well with the Cassandra session manager (or the Delta
>> Session Manager from what I understand). A developer can replace their
>> session bean's HashMap with the SessionMap utility, and the session
>> attributes will be treated as proper session attributes by the session
>> manager.
> Is there not a way to do this internally& therefore transparently to
> the developer? Otherwise you're introducing more dependencies and
> creating more of a framework than a pluggable manager.
I don't think there is a clean way of doing this without overriding the
default Map
implementations of the JVM. But, I think storing session data as
individual session
attributes rather than large object hierarchies is good (but not common)
programming practice. It allows the session container/manager to manage
read/write operations of the session attributes separately. This
practice should
benefit not only my Cassandra session manager but also the existing
Delta manager.
>
>>> 1. Be relatively self-contained -- i.e. not require much in the way of
>>> changes to existing classes
>> There are no changes to existing classes. My session manager implements
>> the existing org.apache.catalina.Manager interface.
> Instead of the filter, could you use a Valve?
For the cache? The main reason why I use a filter is to be able to tie a
cache
object to a thread-local variable for the period for which the request
is being
processed. As soon as the response is streamed to the client the cache
is released.
If Tomcat already contains some internal reference to the current
request then I
won't need to use a filter in this manner. I am not a fan of
thread-local variables,
so I'd very much like to remove the dependency on having this filter in
place.
Morten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 4/10/12 2:55 PM, Mark Thomas wrote:
> e) hosted at www.apacheextras.org (or for small amounts of code on the
> Tomcat wiki)
Aah, I had forgotten about apacheextras.org.
IMHO, this is where Morten's code probably belongs due to its
dependencies on Cassandra.
Honestly, I think this can be done as a Filter to avoid tight-coupling
to Tomcat (or a particular version thereof).
-chris
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Mark Thomas <ma...@apache.org>.
On 10/04/2012 19:38, Christopher Schultz wrote:
> On 4/10/12 2:18 PM, Morten Jorgensen wrote:
>> I would imagine that there are several architects out there that
>> are experiencing similar problems, hence I want to share my
>> work.
>
> I think the best place for this kind of thing is probably directly
> on the Wiki (if the amount of code is small) or if you can host it
> somewhere and put a link to it on the "AddOns" page.
The options for incorporating new features are:
a) Back-port them to one or more of the current stable release
branches (newest version first)
b) Include them in trunk for the next major release
c) Back-port them to the extras package of one or more of the current
d) Include them in the extras package for the next major release
stable release branches (newest version first)
e) hosted at www.apacheextras.org (or for small amounts of code on the
Tomcat wiki)
Factors that tend to push the likely destination away from a) and
towards e) are:
- features that require large amounts of new code are more likely to
end up at e)
- features that introduce new dependencies are more likely to end up at e)
- features that do not appear to appeal to the majority of Tomcat
users are more likely to end up at e)
Where the best place for a new feature is will always be subjective so
there are no hard and fast rules but hopefully this will give folks an
idea of where a proposed new feature is likely to end up.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Morten,
On 4/10/12 2:18 PM, Morten Jorgensen wrote:
> I cannot simply replace all
> session data management (currently using HttpSession) across my entire
> applications, as the time/resources required to do this is massive. I
> need to be able to replace the foundation for my applications, while
> retaining as much of the applications as-is. Nor can I rely on the
> existing session managers in Tomcat, as these do not scale to meet the
> traffic volumes that my customers see in their environments.
You can do this without using a replacement SessionManager, and it will
work across all containers. Use a Filter that wraps the
HttpServletRequest and returns a customized HttpSession object.
This custom HttpSession can use the "real" (in-memory) session for
certain attributes and it can use Cassandra for others. You can even
make it configurable on a per-session-key basis.
(We do this for certain non-Serializable data that is also very big,
when the client code can handle it being null: we wrap certain objects
in SoftReferences and let the GC destroy them if it needs memory. Then,
the webapp can discover a null value and re-load the object in question
from primary storage. It works seamlessly through the HttpSession
interface).
I think this would be a better strategy in general, since it will work
with any servlet container.
> I would imagine that there are several architects out there that are
> experiencing similar problems, hence I want to share my work.
I think the best place for this kind of thing is probably directly on
the Wiki (if the amount of code is small) or if you can host it
somewhere and put a link to it on the "AddOns" page.
-chris
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Morten Jorgensen <mo...@openjawtech.com>.
Chris, Pid & all,
I do see the argument for managing session-related data outside of the
HttpSession, but for me this is an application development life-cycle
issue. The applications that I manage has evolved over 8 years and has
thousands of references to data stored in the HttpSession. The
requirements for the applications have also evolved over the years. The
traffic volumes for this off-the-shelf application is for some of our
customers in the millions per day. I also need improved availability,
resilience, failover and fault tolerance. I cannot simply replace all
session data management (currently using HttpSession) across my entire
applications, as the time/resources required to do this is massive. I
need to be able to replace the foundation for my applications, while
retaining as much of the applications as-is. Nor can I rely on the
existing session managers in Tomcat, as these do not scale to meet the
traffic volumes that my customers see in their environments.
I would imagine that there are several architects out there that are
experiencing similar problems, hence I want to share my work.
The way caching is currently implemented is quick and dirty, and I agree
that this should be done in a manner that does not require changes -to
the existing web application (ref my development life-cycle requirements
above). A request-scope write-back cache is not 100% reliable with
multiple concurrent requests. A request-scope write-through cache is
better (yet not 100% reliable as you can have stale data in the cache),
but performance is not ideal. I will come up with a better solution for
this, and I'll revert back to this list.
Thanks to all,
Morten
On 05/04/2012 01:02, Christopher Schultz wrote:
> Pid,
>
> On 4/4/12 6:46 AM, Pid wrote:
>> On 03/04/2012 22:18, Morten Jorgensen wrote:
>>> Thanks to all for your feedback. I am providing some additional
>>> information as requested:
>>>> That's interesting. Can you share some details about how it works?
>>> Sure. It is quite simple. Cassandra is effectively a multi-level
>>> distributed hash-map, so it lends itself very well do storing session
>>> attributes.
>>>
>>> The session manager maintains two column families (like tables), one to
>>> hold session meta-data such as the last access timestamp, etc. and one
>>> column family to hold session attributes. Storing or reading a session
>>> attribute is simply a matter of writing it using the session ID as the
>>> row ID, and the session attribute name as the column name, and the
>>> session attribute value as the column value.
>>>
>>> Session attributes are read and written independently, so the entire web
>>> session does not have to be loaded into memory - only the session
>>> attributes that are actually required to service a request are read.
>>> This greatly reduces the memory footprint of the web applications that I
>>> am developing for my employer.
>> I'd be concerned about how chatty that was.
>>
>> Devil's advocate question: why store data in the session if it's not needed?
> Honestly, I was thinking the same thing today: usually, non-memory-based
> data management is usually done in such a way as to be completely
> divorced from the HttpSession concept, anyway. One needs to use
> HttpSession for things like unique ids being assigned to clients, etc.
> but then everything else can be done completely separately from that.
>
> There's no reason that a "CassandraSessionManager" would really need to
> exist unless you wanted to have completely seamless Cassandra-based
> storage. I would argue that you don't actually want that, since you have
> to put so much plumbing code in that you end up being a slave to
> HttpSession when what you really want to do is store binary data (since
> that's all Cassandra *can* store) and have it bound to some unique
> identifier (coincidentally the HttpSession id).
>
> I almost think that a Map implementation (with associated identifier,
> which could be session-id-based) with a Cassandra backing-store would be
> more useful since you could use it in any container and even entirely
> outside a container.
>
> I'm starting to be more like +0 to this idea.
>
> -chris
>
--
Morten Jørgensen
Chief Architect
*OpenJaw Technologies*
T: + 353 (0)1 - 882 5444
W: www.openjawtech.com <http://www.openjawtech.com/>
Join OpenJaw Technologies Group on LinkedIn
<http://www.linkedin.com/groups?about=&gid=4074413> / Follow OpenJawTech
on Twitter <http://twitter.com/#%21/OpenJawTech>.
We have checked this material for computer viruses and although none has
been found by us, we cannot guarantee that it is completely virus free
and we do not accept any liability for loss or damage that may be
caused. Please therefore check any attachments for viruses before using
them on your own equipment. If you do find a computer virus please
inform us immediately so that we may take appropriate action.
This communication is intended solely for the addressee and is
confidential.
If you are not the intended recipient, please delete this email. Any
disclosure, copying, distribution or any action taken or omitted to be
taken in reliance on it, is prohibited and may be unlawful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Pid,
On 4/4/12 6:46 AM, Pid wrote:
> On 03/04/2012 22:18, Morten Jorgensen wrote:
>> Thanks to all for your feedback. I am providing some additional
>> information as requested:
>>> That's interesting. Can you share some details about how it works?
>> Sure. It is quite simple. Cassandra is effectively a multi-level
>> distributed hash-map, so it lends itself very well do storing session
>> attributes.
>>
>> The session manager maintains two column families (like tables), one to
>> hold session meta-data such as the last access timestamp, etc. and one
>> column family to hold session attributes. Storing or reading a session
>> attribute is simply a matter of writing it using the session ID as the
>> row ID, and the session attribute name as the column name, and the
>> session attribute value as the column value.
>>
>> Session attributes are read and written independently, so the entire web
>> session does not have to be loaded into memory - only the session
>> attributes that are actually required to service a request are read.
>> This greatly reduces the memory footprint of the web applications that I
>> am developing for my employer.
>
> I'd be concerned about how chatty that was.
>
> Devil's advocate question: why store data in the session if it's not needed?
Honestly, I was thinking the same thing today: usually, non-memory-based
data management is usually done in such a way as to be completely
divorced from the HttpSession concept, anyway. One needs to use
HttpSession for things like unique ids being assigned to clients, etc.
but then everything else can be done completely separately from that.
There's no reason that a "CassandraSessionManager" would really need to
exist unless you wanted to have completely seamless Cassandra-based
storage. I would argue that you don't actually want that, since you have
to put so much plumbing code in that you end up being a slave to
HttpSession when what you really want to do is store binary data (since
that's all Cassandra *can* store) and have it bound to some unique
identifier (coincidentally the HttpSession id).
I almost think that a Map implementation (with associated identifier,
which could be session-id-based) with a Cassandra backing-store would be
more useful since you could use it in any container and even entirely
outside a container.
I'm starting to be more like +0 to this idea.
-chris
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Pid <pi...@pidster.com>.
On 03/04/2012 22:18, Morten Jorgensen wrote:
> Thanks to all for your feedback. I am providing some additional
> information as requested:
>> That's interesting. Can you share some details about how it works?
> Sure. It is quite simple. Cassandra is effectively a multi-level
> distributed hash-map, so it lends itself very well do storing session
> attributes.
>
> The session manager maintains two column families (like tables), one to
> hold session meta-data such as the last access timestamp, etc. and one
> column family to hold session attributes. Storing or reading a session
> attribute is simply a matter of writing it using the session ID as the
> row ID, and the session attribute name as the column name, and the
> session attribute value as the column value.
>
> Session attributes are read and written independently, so the entire web
> session does not have to be loaded into memory - only the session
> attributes that are actually required to service a request are read.
> This greatly reduces the memory footprint of the web applications that I
> am developing for my employer.
I'd be concerned about how chatty that was.
Devil's advocate question: why store data in the session if it's not needed?
> For improved performance I have added a write-through and a write-back
> cache, implemented as servlet filters. The cache is flushed or written
> back once the current request has finished processing. I am sure there
> is room for improvement here, as multiple concurrent requests for the
> same session should be served using the same cache instance.
But... (more devil's advocating, sorry) while this should address the
chattiness* problem, doesn't it mean that your solution is invasive and
can't be really deployed without modifying an app?
* is that even a word?
> The Manager does not maintain any references to Session instances at
> all, allowing them to be garbage collected at any time. This makes
> things very simple, as Cassandra holds all session state, and the
> session managers in my Tomcat nodes only act as a cache in front of
> Cassandra.
>
> The nature of Cassandra and the Tomcat's implementation of web sessions
> go together extremely well. I am surprised that nothing like this exists
> already. It is a square hole, square peg sort of scenario.
I'm not entirely sure I agree.
Cassandra trades off consistency for availability and partition
tolerance, whereas I'd suggest a session management solution would want
to trade partition tolerance for consistency and availability.
I'm also not sure that the comparison between column store and session
attribute map stands up beyond the initial/apparent similarity between
data type.
Cassandra is write-optimised and hits disk (on at least two nodes for
HA) for every write AFAIK.
> I also have an implementation of the Map interface that stores the
> values of each entry as a session attribute. The way many developers
> write web applications is to have a "session bean" (a session attribute)
> that contains a Map that maintains the actual session attributes. This
> is OK if the entire session is persisted as a whole, but it won't
> perform very well with the Cassandra session manager (or the Delta
> Session Manager from what I understand). A developer can replace their
> session bean's HashMap with the SessionMap utility, and the session
> attributes will be treated as proper session attributes by the session
> manager.
Is there not a way to do this internally & therefore transparently to
the developer? Otherwise you're introducing more dependencies and
creating more of a framework than a pluggable manager.
>> 1. Be relatively self-contained -- i.e. not require much in the way of
>> changes to existing classes
> There are no changes to existing classes. My session manager implements
> the existing org.apache.catalina.Manager interface.
Instead of the filter, could you use a Valve?
p
>> 2. Not have any external dependencies (new JAR files, etc.). This might
>> be a problem, depending on whether your code uses the REST API for
>> Cassandra or a direct Java binding.
> This could be a problem... I use the Hector API to access Cassandra, and
> there are about 10 JARs required for this API.
>> 3. Include good documentation for how to set it up. See the existing
>> session-persistence documentation for a guide, and aim to do a better
>> job ;)
> It is extremely easy to set up:
> 1) Configure your Cassandra ring (cluster).
> 2) Copy the required Hector API JARs and the Cassandra session manager
> JAR to tomcat/lib
> 3) Configure your web application descriptor to use the Cassandra
> session manager. Parameters in the web application descriptor point the
> session manager to one or more nodes in your Cassandra ring.
>> 4. Include test cases and potentially instructions for setting-up a test
>> environment (i.e. you're gonna need a working Cassandra instance).
> This is pretty much non-existent right now, so I'll put some effort in
> there. What format do you guys use for your documentation? Do you still
> use docbook?
>
> Thanks again for all your comments and feedback.
>
> Morten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
--
[key:62590808]
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Morten,
On 4/3/12 5:18 PM, Morten Jorgensen wrote:
> I also have an implementation of the Map interface that stores the
> values of each entry as a session attribute. The way many developers
> write web applications is to have a "session bean" (a session attribute)
> that contains a Map that maintains the actual session attributes. This
> is OK if the entire session is persisted as a whole, but it won't
> perform very well with the Cassandra session manager (or the Delta
> Session Manager from what I understand). A developer can replace their
> session bean's HashMap with the SessionMap utility, and the session
> attributes will be treated as proper session attributes by the session
> manager.
This seems like something that is orthogonal to your Manager
implementation, though quite useful.
>> 1. Be relatively self-contained -- i.e. not require much in the way of
>> changes to existing classes
>
> There are no changes to existing classes. My session manager implements
> the existing org.apache.catalina.Manager interface.
Great.
>> 2. Not have any external dependencies (new JAR files, etc.). This might
>> be a problem, depending on whether your code uses the REST API for
>> Cassandra or a direct Java binding.
>
> This could be a problem... I use the Hector API to access Cassandra, and
> there are about 10 JARs required for this API.
Yeah, that could be a problem. I'm going to defer to the other devs for
how tolerant we might be for such a thing to happen. It's possible that
we could make this an optional module where it might be okay to have
additional dependencies.
>> 3. Include good documentation for how to set it up. See the existing
>> session-persistence documentation for a guide, and aim to do a better
>> job ;)
>
> It is extremely easy to set up:
> 1) Configure your Cassandra ring (cluster).
> 2) Copy the required Hector API JARs and the Cassandra session manager
> JAR to tomcat/lib
> 3) Configure your web application descriptor to use the Cassandra
> session manager. Parameters in the web application descriptor point the
> session manager to one or more nodes in your Cassandra ring.
Presumably, you also need to set up Cassandra to have your column family
(etc) definitions available. You'll obviously need to document what that
is (or simply provide the configuration file, which should both document
and specify at the same time).
>> 4. Include test cases and potentially instructions for setting-up a test
>> environment (i.e. you're gonna need a working Cassandra instance).
>
> This is pretty much non-existent right now, so I'll put some effort in
> there. What format do you guys use for your documentation? Do you still
> use docbook?
Look at what's currently in the webapps/docs directory in svn. It's a
fairly simple XML format that gets XSLT'd into .html files at release time.
You could probably look at the existing docs for DeltaManager and
BackupManager here
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-manager.html and
use them as a guide. Obviously, a Cassandra-based Session Manager can be
used in a non-clustered environment to improve robustness and
durability, so it might eventually go into its own separate config page
instead of being on the cluster-manager.xml page.
Go ahead and create a bugzilla entry for this and mention that a patch
is forthcoming. When you submit a patch to Bugzilla, you have to grant
rights to the ASF so that's better than just saying "here's my Git repo"
or "you can download my patch from my website". Obviously, don't include
any of the binary dependencies: just mention what they are.
-chris
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Morten Jorgensen <mo...@openjawtech.com>.
Thanks to all for your feedback. I am providing some additional
information as requested:
> That's interesting. Can you share some details about how it works?
Sure. It is quite simple. Cassandra is effectively a multi-level
distributed hash-map, so it lends itself very well do storing session
attributes.
The session manager maintains two column families (like tables), one to
hold session meta-data such as the last access timestamp, etc. and one
column family to hold session attributes. Storing or reading a session
attribute is simply a matter of writing it using the session ID as the
row ID, and the session attribute name as the column name, and the
session attribute value as the column value.
Session attributes are read and written independently, so the entire web
session does not have to be loaded into memory - only the session
attributes that are actually required to service a request are read.
This greatly reduces the memory footprint of the web applications that I
am developing for my employer.
For improved performance I have added a write-through and a write-back
cache, implemented as servlet filters. The cache is flushed or written
back once the current request has finished processing. I am sure there
is room for improvement here, as multiple concurrent requests for the
same session should be served using the same cache instance.
The Manager does not maintain any references to Session instances at
all, allowing them to be garbage collected at any time. This makes
things very simple, as Cassandra holds all session state, and the
session managers in my Tomcat nodes only act as a cache in front of
Cassandra.
The nature of Cassandra and the Tomcat's implementation of web sessions
go together extremely well. I am surprised that nothing like this exists
already. It is a square hole, square peg sort of scenario.
I also have an implementation of the Map interface that stores the
values of each entry as a session attribute. The way many developers
write web applications is to have a "session bean" (a session attribute)
that contains a Map that maintains the actual session attributes. This
is OK if the entire session is persisted as a whole, but it won't
perform very well with the Cassandra session manager (or the Delta
Session Manager from what I understand). A developer can replace their
session bean's HashMap with the SessionMap utility, and the session
attributes will be treated as proper session attributes by the session
manager.
> 1. Be relatively self-contained -- i.e. not require much in the way of
> changes to existing classes
There are no changes to existing classes. My session manager implements
the existing org.apache.catalina.Manager interface.
> 2. Not have any external dependencies (new JAR files, etc.). This might
> be a problem, depending on whether your code uses the REST API for
> Cassandra or a direct Java binding.
This could be a problem... I use the Hector API to access Cassandra, and
there are about 10 JARs required for this API.
> 3. Include good documentation for how to set it up. See the existing
> session-persistence documentation for a guide, and aim to do a better job ;)
It is extremely easy to set up:
1) Configure your Cassandra ring (cluster).
2) Copy the required Hector API JARs and the Cassandra session manager
JAR to tomcat/lib
3) Configure your web application descriptor to use the Cassandra
session manager. Parameters in the web application descriptor point the
session manager to one or more nodes in your Cassandra ring.
> 4. Include test cases and potentially instructions for setting-up a test
> environment (i.e. you're gonna need a working Cassandra instance).
This is pretty much non-existent right now, so I'll put some effort in
there. What format do you guys use for your documentation? Do you still
use docbook?
Thanks again for all your comments and feedback.
Morten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Pid <pi...@pidster.com>.
On 03/04/2012 21:08, Christopher Schultz wrote:
> Pid,
>
> On 4/3/12 12:52 PM, Pid wrote:
>> I can't speak for the committers/project, but one option would be to
>> file an enhancement request and attach a patch in diff format.
>
> +1
>
> To get such a thing into Tomcat, it would probably have to have the
> following features:
>
> 1. Be relatively self-contained -- i.e. not require much in the way of
> changes to existing classes
>
> 2. Not have any external dependencies (new JAR files, etc.). This might
> be a problem, depending on whether your code uses the REST API for
> Cassandra or a direct Java binding.
>
> 3. Include good documentation for how to set it up. See the existing
> session-persistence documentation for a guide, and aim to do a better job ;)
>
> 4. Include test cases and potentially instructions for setting-up a test
> environment (i.e. you're gonna need a working Cassandra instance).
>
> If the above are not met, you'll likely get a lot of push-back,
> including mine. I know there's a lurker on this list who maintains a
> memcached-oriented session manager and we've never really considered
> including that in Tomcat because of (I'd imagine) dependency issues.
>
> In any case, even if it doesn't get included in Tomcat, you could always
> post it to the Wiki as contributed code. Just make sure you include
> great documentation otherwise nobody will ever use it.
There is also ASF Extras or whatever the tertiary associated thing is
called.
p
> Thanks,
> -chris
>
--
[key:62590808]
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Pid,
On 4/3/12 12:52 PM, Pid wrote:
> I can't speak for the committers/project, but one option would be to
> file an enhancement request and attach a patch in diff format.
+1
To get such a thing into Tomcat, it would probably have to have the
following features:
1. Be relatively self-contained -- i.e. not require much in the way of
changes to existing classes
2. Not have any external dependencies (new JAR files, etc.). This might
be a problem, depending on whether your code uses the REST API for
Cassandra or a direct Java binding.
3. Include good documentation for how to set it up. See the existing
session-persistence documentation for a guide, and aim to do a better job ;)
4. Include test cases and potentially instructions for setting-up a test
environment (i.e. you're gonna need a working Cassandra instance).
If the above are not met, you'll likely get a lot of push-back,
including mine. I know there's a lurker on this list who maintains a
memcached-oriented session manager and we've never really considered
including that in Tomcat because of (I'd imagine) dependency issues.
In any case, even if it doesn't get included in Tomcat, you could always
post it to the Wiki as contributed code. Just make sure you include
great documentation otherwise nobody will ever use it.
Thanks,
-chris
Re: Who wants my Cassandra session manager for Tomcat?
Posted by ma...@mohawksoft.com.
I would tend to view a Cassandra session manager as secondary to the
notion of a simple and extensible session manager interface that is
fundamentally disconnected from the tomcat infrastructure.
It would be valuable to use class serialization and session information in
a cross platform way across ruby, php, and even C++.
> On 03/04/2012 09:56, Morten Jorgensen wrote:
>> All,
>>
>> I recently implemented a Tomcat session manager that uses Cassandra for
>> session storage. Cassandra is a commonly used session store for
>> PHP-based applications, but I could not find one that would plug
>> seamlessly into Tomcat. My Cassandra session manager is fully working
>> and has gone through basic testing.
>>
>> Now I want to donate my code to the Tomcat project - if you'll have it.
>> I am unsure on how to proceed with this, so any direction will be very
>> much appreciated. I did manage the donation of XSLTC from Sun
>> Microsystems to the Xalan-J project at xml.apache.org way back when,
>> but this was more than 10 years ago and my memory isn't great...
>
> I can't speak for the committers/project, but one option would be to
> file an enhancement request and attach a patch in diff format.
>
> Whether it gets added or not would depend on the committers' opinion
> about the value of the feature & the impact of adding dependencies etc.
>
> Is there a community of users already, or is it too new?
>
>
>> Apologies if this is the wrong forum for this request.
>
> It's the right forum.
>
>
> p
>
>> Best regards,
>> Morten Jorgensen
>>
>
>
> --
>
> [key:62590808]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Who wants my Cassandra session manager for Tomcat?
Posted by Pid <pi...@pidster.com>.
On 03/04/2012 09:56, Morten Jorgensen wrote:
> All,
>
> I recently implemented a Tomcat session manager that uses Cassandra for
> session storage. Cassandra is a commonly used session store for
> PHP-based applications, but I could not find one that would plug
> seamlessly into Tomcat. My Cassandra session manager is fully working
> and has gone through basic testing.
>
> Now I want to donate my code to the Tomcat project - if you'll have it.
> I am unsure on how to proceed with this, so any direction will be very
> much appreciated. I did manage the donation of XSLTC from Sun
> Microsystems to the Xalan-J project at xml.apache.org way back when,
> but this was more than 10 years ago and my memory isn't great...
I can't speak for the committers/project, but one option would be to
file an enhancement request and attach a patch in diff format.
Whether it gets added or not would depend on the committers' opinion
about the value of the feature & the impact of adding dependencies etc.
Is there a community of users already, or is it too new?
> Apologies if this is the wrong forum for this request.
It's the right forum.
p
> Best regards,
> Morten Jorgensen
>
--
[key:62590808]