From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.229.48.136 with SMTP id r8cs51906qcf; Thu, 28 Jul 2011 12:54:36 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCOiF2Lu6BRD4_MbxBBoEI-vpBA@googlegroups.com designates 10.236.173.103 as permitted sender) client-ip=10.236.173.103; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCOiF2Lu6BRD4_MbxBBoEI-vpBA@googlegroups.com designates 10.236.173.103 as permitted sender) smtp.mail=rack-devel+bncCOiF2Lu6BRD4_MbxBBoEI-vpBA@googlegroups.com; dkim=pass header.i=rack-devel+bncCOiF2Lu6BRD4_MbxBBoEI-vpBA@googlegroups.com Received: from mr.google.com ([10.236.173.103]) by 10.236.173.103 with SMTP id u67mr199736yhl.30.1311882874988 (num_hops = 1); Thu, 28 Jul 2011 12:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; bh=0Fa6cvCJmtm0qKu5A/ppKHFHsm4bgZlbpXo3ynlrU+Q=; b=XkSlv+5245ogbrguE8hpm2+T13xTwiuUkeaUDp2U0N0Soi+bHupa+nTY2/uuU1oZWf UE/ZV5rZzhW4XmW+vCtSuIm8xrfW4AXmcFfKxdvHcowfFn3lR22R9DswIaEx47ic7AjF 60BSUTK7ZooTlOPd7EaAShQx80/Ot4YgpA0/g= Received: by 10.236.173.103 with SMTP id u67mr61538yhl.30.1311882872535; Thu, 28 Jul 2011 12:54:32 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.91.69.31 with SMTP id w31ls5169347agk.2.gmail; Thu, 28 Jul 2011 12:54:31 -0700 (PDT) Received: by 10.236.186.98 with SMTP id v62mr144802yhm.114.1311882871248; Thu, 28 Jul 2011 12:54:31 -0700 (PDT) Received: by 10.236.186.98 with SMTP id v62mr144801yhm.114.1311882871237; Thu, 28 Jul 2011 12:54:31 -0700 (PDT) Received: from mail-gy0-f170.google.com (mail-gy0-f170.google.com [209.85.160.170]) by gmr-mx.google.com with ESMTPS id d41si1059201yhe.3.2011.07.28.12.54.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 12:54:31 -0700 (PDT) Received-SPF: pass (google.com: domain of neil.matatall@gmail.com designates 209.85.160.170 as permitted sender) client-ip=209.85.160.170; Received: by gyb13 with SMTP id 13so2357283gyb.29 for ; Thu, 28 Jul 2011 12:54:31 -0700 (PDT) Received: by 10.143.66.17 with SMTP id t17mr229377wfk.434.1311882870717; Thu, 28 Jul 2011 12:54:30 -0700 (PDT) Received: from Neil-Matatalls-MacBook-Air.local (67.110.253.162.ptr.us.xo.net [67.110.253.162]) by mx.google.com with ESMTPS id v17sm767836wfd.5.2011.07.28.12.54.28 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 12:54:29 -0700 (PDT) Message-ID: <4E31BE74.8060300@gmail.com> Date: Thu, 28 Jul 2011 12:54:28 -0700 From: Neil Matatall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rack-devel@googlegroups.com Subject: Re: Session collisions on rails 3.1rc4 (authlogic, omniauth, memcache store, passenger) References: <8F93F290D08845C89C2A7C1519A9138B@gmail.com> In-Reply-To: <8F93F290D08845C89C2A7C1519A9138B@gmail.com> X-Original-Sender: neil.matatall@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of neil.matatall@gmail.com designates 209.85.160.170 as permitted sender) smtp.mail=neil.matatall@gmail.com; dkim=pass (test mode) header.i=@gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Joshua, I think what you described was indeed our issue. The call to @pool.add actually returned "END" which is a sign of a get_multikey We were using memcache-client and the author informed me that the project was no longer supported and said that this can occur when the same memcache instance handles sessions and data. He recommended splitting the caches as well as switching to Dalli instead. So...not a rack issue! Thanks! Neil On 7/25/11 1:23 PM, Joshua Ballanco wrote: > Have you considered the possibility that memcache might be recycling > keys on you? > > We had an issue a while back where we were using memcache for both > fragment caching and session storage. Occasionally, we would get > exceptions in retrieving a session, and looking at the error message > it was clear that what was retrieved from memcache was a fragment and > not a session. Unfortunately, we moved back to a cookie-based session > store before we had a chance to look deeper into the issue. What I can > say is that based on the key generation scheme we were using for > sessions and cache keys, there was effectively 0 chance that we were > duplicating keys. Instead, it seemed like memcache was re-using slots > for different keys when we started exhausting free slots. > > Hope that helps! > > - Joshua Ballanco > > On Monday, July 25, 2011 at 2:22 PM, Neil wrote: > >> While it's entirely possible that this issue is caused by some other >> factor, but we are getting session collisions as well as an issue >> where one user is getting another user's session. This is clearly >> bad, but I cannot for the life of me figure out how this could even >> happen in the first place. The code looks thread safe to me, and a >> quick discussion on #ruby-lang seems to support that. >> >> Thoughts: >> 1. Session IDs are being generated in the same sequence (uses >> securerandom -> openssl which does not have a static seed) >> 2. Threads. Looks good to me. >> 3. Maybe memcached is returning something other than "STORED/ >> NOT_STORED" for @pool.add(sid, session), but the operation still >> succeeded? >> 4. Gnomes. >> >> Any input is GREATLY appreciated. Please don't say "it's an RC, what >> do you expect?" :) >> >> >> From >> https://github.com/rack/rack/blob/master/lib/rack/session/memcache.rb >> def generate_sid >> loop do >> sid = super >> break sid unless @pool.get(sid, true) >> end >> end >> >> def get_session(env, sid) >> with_lock(env, [nil, {}]) do >> unless sid and session = @pool.get(sid) >> sid, session = generate_sid, {} >> unless /^STORED/ =~ @pool.add(sid, session) >> raise "Session collision on '#{sid.inspect}'" >> end >> end >> [sid, session] >> end >> end >> >> def set_session(env, session_id, new_session, options) >> expiry = options[:expire_after] >> expiry = expiry.nil? ? 0 : expiry + 1 >> >> with_lock(env, false) do >> @pool.set session_id, new_session, expiry >> session_id >> end >> end >