Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 31529 invoked from network); 4 Jun 2009 22:41:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Jun 2009 22:41:22 -0000 Received: (qmail 50922 invoked by uid 500); 4 Jun 2009 22:41:34 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 50809 invoked by uid 500); 4 Jun 2009 22:41:33 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 50799 invoked by uid 99); 4 Jun 2009 22:41:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jun 2009 22:41:33 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com designates 209.85.222.192 as permitted sender) Received: from [209.85.222.192] (HELO mail-pz0-f192.google.com) (209.85.222.192) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Jun 2009 22:41:21 +0000 Received: by pzk30 with SMTP id 30so139557pzk.28 for ; Thu, 04 Jun 2009 15:40:59 -0700 (PDT) Received: by 10.142.147.15 with SMTP id u15mr955745wfd.47.1244155258872; Thu, 04 Jun 2009 15:40:58 -0700 (PDT) Received: from ?192.168.10.129? (adsl-66-51-196-164.dslextreme.com [66.51.196.164]) by mx.google.com with ESMTPS id 30sm2707832wfd.1.2009.06.04.15.40.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Jun 2009 15:40:57 -0700 (PDT) Message-Id: <26B596BA-2DED-4EE4-A775-28D531297B57@dslextreme.com> From: Ralph Goers To: "Commons Developers List" In-Reply-To: <18fbabce0906041422l62e0ca18pd43da6207b8b468@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: [vfs] MemcachedFilesCache for Google App Engine (object serialization) Date: Thu, 4 Jun 2009 15:40:55 -0700 References: <18fbabce0906041422l62e0ca18pd43da6207b8b468@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org Wow. I'm interested to see if you can really get this to work. Just make sure that after you get the existing unit tests to pass that the functional tests that require external servers also pass - if you do a mvn site:stage you will see the documentation on how to do that. VFS-245 is opened against AbstractFileName and probably needs to be dealt with in the context of what you are doing. On Jun 4, 2009, at 2:22 PM, Vince Bonfanti wrote: > I'm investigating creating a memcached-based FilesCache > implementation for > use with Google App Engine. The basic obstacle is that this requires > that > all objects that are used as keys or values must be serializable. > Before I > go too far down this path, I'd like to know if this is a reasonable > thing to > do (or consider doing). Any thoughts or guidance would be greatly > appreciated. > > Background info: the Google App Engine (GAE) environment is inherently > distributed, where an unknown number of multiple instances of your > servlet-based web application will be running at the same time. The > GaeVFS > project (http://gaevfs.appspot.com) implements a VFS plugin on top > of the > GAE datastore; this is needed because the "real" filesystem within > GAE is > read-only, so GaeVFS provides a writeable filesystem for use by > applications. It seems that for proper operation of VFS, the > FilesCache > implementation used by GaeVFS should (must?) also be inherently > distributed. > Fortunately, GAE supplies a memcached API that will be perfect for > this use > (if I can solve the serialization problem). > > Here's my first cut at what classes I'd need to make serializable > and some > notes on which fields might be marked transient: > > *AbstractFileName* > serialized fields: scheme (String), absPath (String), type (FileType) > transient fields: uri, baseName, rootUri, extension, decodedPath > > *FileType* > serialized fields: name (String), hasChildren (boolean), hasContent > (boolean), hasAttrs (boolean) > transient fields: none > > *AbstractFileObject* > serialized fields: name (AbstractFileName), content > (DefaultFileContent) > transient fields: fs (AbstractFileSystem), operation > (FileOperations), > attached (boolean), type (FileType), parent (FileObject), children > (FileName[]), objects (List) > > It's very important the the fs (AbstractFileSystem) field be > transient to > limit the number of other classes that need to be made serializable. > It > looks like files are always retrieved from the files cache via the > AbstractFileSystem.getFileFromCache() method; if so then the "fs" > field of > AbstractFileObject can be restored within this method and doesn't > need to be > serialized. We'll need to define a package-scope > AbstractFileObject.setFileSystem() method to support this. Or, this > could be > done within the MemcachedFilesCache.getFile() method before > returning the > FileObject (but then we'd need a FileObject.setFileSystem method, or > do some > not-very-nice type casting). > > *DefaultFileContent > *serialized fields: file (AbstractFileObject), attrs (Map), roAttrs > (Map), > fileContentInfo (FileContentInfo), fileContentInfoFactory > (FileContentInfoFactory), openStreams (int) > transient fields: threadData (ThreadLocal) > question: what types do the "attrs" and "roAttrs" maps contain? are > these > serializable? attrs and roAttrs contain attributes specific to the file system. For example, Webdav contains what you would get back from a PROPFIND method. The Jar file system seems to return values found in the jar manifest., etc. The values I found would all be Strings but I can't guarantee it. > > question: FileContentInfo and FileContentInforFactory are > interfaces, what > are the implementations of these? DefaultFileContentInfo, FileContentInfoFileNameFactory, HttpFileContentInfoFactory, MimeFileContentInfoFactory and WebdavFileContentInfoFactory. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org