memcached session integration in application layer
pradeep gummi
doesnt integrate on the tomcat container level (extension of
ManagerBase) but using HttpSessionListeners or filters in application
layer. We need a solution to integrate with a generic web-container.
Any thoughts?
Martin Grotzke
Sticky or non-sticky sessions?
Cheers,
Martin
pradeep gummi
On Jun 16, 11:30 am, Martin Grotzke <martin.grot...@googlemail.com>
wrote:
>
> Cheers,
> Martin
>
Martin Grotzke
specify/modify the sessionId. So you cannot encode the memcached-node of
the session into the sessionId, and have to use hash based memcached
node selection (be it consistent hashing or not). If a memcached fails,
you can use failover handling of the memcached client lib of your choice
and see if this matches your requirements.
If your tomcats are configured with a jvmRoute, you have to strip this
off the sessionId to get the memcached key. Otherwise, when the
sessionId including the jvmRoute would be used as memcached key, the key
would change on a tomcat failover as the jvmRoute is then changed to the
one of the tomcat that is taking over the session.
Perhaps there are others here on the list that also thought about such
an approach and can share their thoughts?
Cheers,
Martin
--
Martin Grotzke
http://twitter.com/martin_grotzke
pradeep gummi
in the session_id as it has other implications in our distributed
architecture. Instead use membase to support fail_over handling.
We use a different_cookie based approach for "sticky" sessions and
hence need a "non_sticky" session solution that doesnt integrate at
the tomcat layer but instead on the application layer. Can I use
memcache_session_manager for such problem?
Thanks,
pradeep
On Jun 16, 2:28 pm, Martin Grotzke <martin.grot...@googlemail.com>
wrote:
> < 1KViewDownload
Martin Grotzke
On 06/16/2011 10:35 PM, pradeep gummi wrote:
> Now I understand for the approach. We prefer not to use the node_name
> in the session_id as it has other implications in our distributed
> architecture.
Just to clarify: you decide about the nodeId that's appended to the
sessionId. E.g. for memcached node running on 192.168.0.12:11211 you
choose n1 (or just 1, or x3zc89by or anything else), so you definitely
shouldn't expose any internals.
> Instead use membase to support fail_over handling.
> We use a different_cookie based approach for "sticky" sessions and
> hence need a "non_sticky" session solution that doesnt integrate at
> the tomcat layer but instead on the application layer.
I'm not sure what you're really trying to do, but as you write you have
your own session cookie, use non-sticky sessions and you want to keep
all this in the application layer this translates into the following
technical bits and pieces:
- overwrite request.getSession() (in your own implementation of
HttpServletRequestWrapper)
- sessions are loaded from membase and stored in membase (through moxi
probably).
- if there's no sessionId available you generate a new one (you're then
also managing sessionIds yourselves)
- you have your own implementation of HttpSession
- as membase driver you'd choose s.th. like spymemcached
One thing to consider with non-sticky sessions are concurrent requests
(caused by tabbed browsing, ajax requests etc.) that might access the
session from different app servers / tomcats. For msm I implemented some
strategies for session locking to handle this issue, you just need to
check your application properties/requirements to see if you need to
think about it.
> Can I use memcache_session_manager for such problem?
msm is a solution to your goals. The only goal that it does not achieve
is that you want to keep all this in the application layer. Why do you
have this requirement?
Cheers,
Martin
Martin Grotzke
I'm cc'ing the mailing list as this might be interesting for others or
perhaps s.o. on the list can also help (or even has already a solution
for your issues.
On 07/07/2011 10:54 PM, pradeep gummi wrote:
> Hello Martin,
> We scrapped the idea of writing our session mgr and instead use the
> memcached session manager in the tomcat. We are working on updating our
> embedded tomcat initialize the session-cache-manager.
>
> The problems that I need to solve are:
> 1. Instead of configuring each mem-cached node, configure the remote
> membase vip for the session interaction. (spymemcached 2.7 client version).
If you have on membase you want to connect from msm you can simply
configure this as one node (just n1:mem.base.ip:11211). You might also
think about running moxi on the tomcat machines and connect them from msm.
> 2. Use non-sticky version and avoid node information in the sessionId.
> Is there a way to make it just random-number. This will help us
> associate the resquests to the same session within our stack.
The session id is built by SessionIdFormat [1]. It could be changed so
that it does not add the node id to the sessionId if there's only one
memcached node configured. Perhaps it makes also sense to change the
memcached node definition in the manager configuration so that for a
single node the node id is optional (so that "mem.base.ip:11211" would
also be valid).
If you'd like to provide a patch for this (e.g. as pull request on
github) you'd make me happy :-)
Unfortunately the next days I cannot help with this as I'm going on
vacation tomorrow morning (still reading/answering mails). After that I
have some time again and could help actively.
Cheers,
Martin
Martin Grotzke
On 07/15/2011 04:52 PM, pradeep gummi wrote:
> Hello Martin,
> Pls ping me if you are back from vacation.
Because of the bad weather we had to change our holidays a little bit so
that unexpectedly I have a few coding hours per day now.
> I tried making the changes
> but couldnt get all the tests running sucessfully.
> Pls review the comments in red below.
>
>> Hello Martin,
>> We scrapped the idea of writing our session mgr and instead use the
>> memcached session manager in the tomcat. We are working on updating our
>> embedded tomcat initialize the session-cache-manager.
>>
>> The problems that I need to solve are:
>> 1. Instead of configuring each mem-cached node, configure the remote
>> membase vip for the session interaction. (spymemcached 2.7 client
> version).
>>If you have on membase you want to connect from msm you can simply
>>configure this as one node (just n1:mem.base.ip:11211). You might also
>>think about running moxi on the tomcat machines and connect them from msm.
> I tried this approach setting up moxy locally pointing ot remote membase
> nodes in a cluster and this worked.
Great!
>>> 2. Use non-sticky version and avoid node information in the sessionId.
>>> Is there a way to make it just random-number. This will help us
>>> associate the resquests to the same session within our stack.
>> The session id is built by SessionIdFormat [1]. It could be changed so
>> that it does not add the node id to the sessionId if there's only one
>> memcached node configured. Perhaps it makes also sense to change the
>> memcached node definition in the manager configuration so that for a
>> single node the node id is optional (so that "mem.base.ip:11211" would
>> also be valid).
>> If you'd like to provide a patch for this (e.g. as pull request on
>> github) you'd make me happy :-)
> I forked the code to *memcached-session-mgr-pg*
Where can I find this? I searched github for this and for your name but
didn't find anything. Can you provide a link where I can review? Or just
place a pull request on github, this allows easy code review. For github
forking and pull requests you might read
http://help.github.com/send-pull-requests/
> and made the following
> changes and committed to my branch.
>
> 1. Changed the sessionIdFormat to support membase.pi:11211 format
> 2. Changed the manager configuration to support single node format with
> node_id as optional.
Sounds good.
> Pls review the code and let me know your comments. BTW, I couldnt get
> the tests running successfully. Also, I havent been able to
> figure out all the impacts of my code changes.
As soon as you send me a link to your changes or submit a pull request
I'll have a look at this and I can also see what's needed to get the
tests running.
Cheers,
Martin
Martin Grotzke
I checked your pullrequest. One issue with the current implementation is
that it does not allow having a single node defined in the previous
format (like e.g. "n1:localhost:11211") and thus is not backwards
compatible. That was probably the reason why you changed some
memcachedNode defintions in tests by removing the node id.
I also noticed that there's the NodeLocator strategy
(SuffixBasedNodeLocator) passed to spymemcached that has to be
changed/replaced.
Overall I think that at this point we need a better abstraction over
nodeId, memcachedNodes and concepts/classes around them.
I'll work on this and started by merging your changes into the branch
single-node-config which is based on the current master (has changed
some days ago a little bit). On progress I'll push it to github and can
ping you if you're interested.
Until this is finished I suggest that you use s.th. like "x" as nodeId
which actually tells the user nothing about your
internals/infrastructure. Ok?
Cheers,
Martin
On 07/18/2011 05:46 PM, pradeep gummi wrote:
> Hi Martin,
> I am sorry that I havent responded early as i dint know what stepped I
> missed. ( I committed code but did not push and create a branch). I
> submitted a pull request. Pls review.
>
> Thanks
> Pradeep
>
> On Fri, Jul 15, 2011 at 3:42 PM, Martin Grotzke
> <martin....@googlemail.com <mailto:martin....@googlemail.com>>
Martin Grotzke
> Hi Martin,
> nodeId, memcachedNodes and concepts/classes around them.
>
> about the design and approach. It would be great if you could help with
> this impl.
>
> Until this is finished I suggest that you use s.th <http://s.th/>. like
> "x" as nodeId
> which actually tells the user nothing about your
> internals/infrastructure. Ok?
>
> failover-nodes for now. This will atleast allow us to have unique
> session-id, not changing the node information.
>
> Do you think you will get time in the next two weeks to work on this? If
> not, pls send me high-level design, and I will try to make progress.
I'm already working at this and should have a working version ready the
next days.
Cheers,
Martin
>
> Thanks again for all your help.
>
> -Pradeep
>
>
>
>
> On Mon, Jul 18, 2011 at 5:39 PM, Martin Grotzke
> <martin....@googlemail.com <mailto:martin....@googlemail.com>>
> wrote:
>
> Hi Pradeep,
>
> I checked your pullrequest. One issue with the current implementation is
> that it does not allow having a single node defined in the previous
> format (like e.g. "n1:localhost:11211") and thus is not backwards
> compatible. That was probably the reason why you changed some
> memcachedNode defintions in tests by removing the node id.
>
> I also noticed that there's the NodeLocator strategy
> (SuffixBasedNodeLocator) passed to spymemcached that has to be
> changed/replaced.
>
> Overall I think that at this point we need a better abstraction over
> nodeId, memcachedNodes and concepts/classes around them.
>
> I'll work on this and started by merging your changes into the branch
> single-node-config which is based on the current master (has changed
> some days ago a little bit). On progress I'll push it to github and can
> ping you if you're interested.
>
> Until this is finished I suggest that you use s.th <http://s.th>.
> like "x" as nodeId
> which actually tells the user nothing about your
> internals/infrastructure. Ok?
>
> Cheers,
> Martin
>
>
> On 07/18/2011 05:46 PM, pradeep gummi wrote:
> > Hi Martin,
> > I am sorry that I havent responded early as i dint know what stepped I
> > missed. ( I committed code but did not push and create a branch). I
> > submitted a pull request. Pls review.
> >
> > Thanks
> > Pradeep
> >
> > On Fri, Jul 15, 2011 at 3:42 PM, Martin Grotzke
> > <martin....@googlemail.com
> <mailto:martin....@googlemail.com>
> <mailto:martin....@googlemail.com
--
Dennis Brakhane, Martin Grotzke und Ole Langbehn GbR
Breitenfelder Str. 13c, 20251 Hamburg