I notice it implements DatastoreService, is there a way I can tell OpenBD to use the caching service instead so that googleWrite() and googleRead() work through it?
Cheers, Baz On Thu, Nov 5, 2009 at 5:40 PM, Bassil Karam <[email protected]> wrote: > Works with createObject: > > <cfset cds = createObject('Java', > 'com.newatlanta.appengine.datastore.CachingDatastoreService').init() /> > > Maybe there's an issue with cfobject? > > Baz > > > On Thu, Nov 5, 2009 at 4:27 PM, Bassil Karam <[email protected]> wrote: > >> The error is: >> >> >> Type InternalTag Context CFOBJECT >> (/home/baz/Source/ThinkLOOP-GAE/war/index.cfm, Line=1, Column=1) Source >> >> 1: <cfobject name="CDS" >> component="com.newatlanta.appengine.datastore.CachingDatastoreService" >> type="java" /> >> 2: <cfdump var="#CDS#"> >> 3: <cfabort> >> 4: <cfsilent> >> 5: <cfif not StructKeyExists(url, 'think')> >> >> ^ Snippet from underlying CFML source Stack Trace >> >> java.lang.NullPointerException >> at com.naryx.tagfusion.cfm.tag.cfOBJECT.render(Unknown Source) >> at com.naryx.tagfusion.cfm.tag.cfTag.coreRender(Unknown Source) >> at com.naryx.tagfusion.cfm.tag.cfTag.render(Unknown Source) >> at com.naryx.tagfusion.cfm.file.cfFile.render(Unknown Source) >> at com.naryx.tagfusion.cfm.engine.cfSession.onRequest(Unknown Source) >> at com.naryx.tagfusion.cfm.engine.cfEngine.service(Unknown Source) >> at com.naryx.tagfusion.cfm.cfServlet.service(Unknown Source) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) >> at >> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) >> at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) >> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) >> at >> com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54) >> at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:268) >> at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) >> at >> com.google.appengine.tools.development.StaticFileUtils.serveWelcomeFileAsForward(StaticFileUtils.java:80) >> at >> com.google.appengine.tools.development.LocalResourceFileServlet.maybeServeWelcomeFile(LocalResourceFileServlet.java:247) >> at >> com.google.appengine.tools.development.LocalResourceFileServlet.doGet(LocalResourceFileServlet.java:120) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) >> at >> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) >> at >> com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43) >> at >> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) >> at >> com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121) >> at >> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) >> at >> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) >> at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) >> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) >> at >> com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54) >> at >> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) >> at >> com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:342) >> at >> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) >> at org.mortbay.jetty.Server.handle(Server.java:313) >> at >> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) >> at >> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) >> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) >> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) >> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) >> at >> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) >> at >> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) >> >> >> >> On Thu, Nov 5, 2009 at 4:12 PM, Bassil Karam <[email protected]> wrote: >> >>> Ok, I got the class to compile into the classes folder under: >>> >>> >>> /home/baz/Source/ThinkLOOP-GAE/war/WEB-INF/classes/com/newatlanta/appengine/datastore/CachingDatastoreService.class >>> >>> How do I call it now, variations of this don't seem to work: >>> >>> <cfobject name="CDS" >>> component="com.newatlanta.appengine.datastore.CachingDatastoreService" >>> type="java" /> >>> >>> Thanks, >>> Baz >>> >>> >>> On Thu, Nov 5, 2009 at 3:05 PM, Vince Bonfanti <[email protected]>wrote: >>> >>>> >>>> You can add it directly to your project just as you would any other >>>> Java class (within your projects's "src" directory, within an >>>> appropriate directory structure to match the package). The class file >>>> will be automatically build into your "war/WEB-INF/classes" directory. >>>> >>>> Vince >>>> >>>> On Thu, Nov 5, 2009 at 3:28 PM, Bassil Karam <[email protected]> wrote: >>>> > Can I build CachingDatastoreService.java right from my GAE project? >>>> How? >>>> > Once built, where would I put it, somewhere in the WAR folder? >>>> > Excuse my ignorance.... >>>> > Baz >>>> > >>>> > On Mon, Nov 2, 2009 at 11:31 AM, Vince Bonfanti <[email protected]> >>>> wrote: >>>> >> >>>> >> Query caching and page caching in BD are currently implemented via >>>> >> memory-based caches. So, yes, they would exist on a >>>> >> per-application-instance basis in GAE. We plan to modify these in >>>> >> OpenBD-GAE to use memcache. >>>> >> >>>> >> I'd recommend just building the CachingDatastoreServvice class--it >>>> >> doesn't have any dependencies on the rest of GaeVFS. >>>> >> >>>> >> Vince >>>> >> >>>> >> On Mon, Nov 2, 2009 at 2:08 PM, Bassil Karam <[email protected]> >>>> wrote: >>>> >> > >>>> >> > Very interesting Vince. So far from my informal tests, I can tell >>>> you >>>> >> > that my app scope resets several times a day at least. So I see >>>> what >>>> >> > you mean when you say it wouldn't be best for framework >>>> >> > initialization. Also inappropriate would be object pools, or >>>> temporary >>>> >> > cache's that get flushed to the db as a batch. I take it query >>>> caching >>>> >> > and page caching also rely on the same mechanisms and have the same >>>> >> > gotchas? Come to think of it, are those even wired up? >>>> >> > >>>> >> > Next I will play around with memcached and your >>>> >> > CachingDatastoreService if I can figure out how to build it and >>>> >> > replace the current GAE-VFS. >>>> >> > >>>> >> > Cheers, >>>> >> > Baz >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > On Mon, Nov 2, 2009 at 9:00 AM, Vince Bonfanti < >>>> [email protected]> >>>> >> > wrote: >>>> >> >> >>>> >> >> RE: "could application.myvariable return different values >>>> depending on >>>> >> >> which machine it pulls it from? What about session scope?" >>>> >> >> >>>> >> >> I asked this question on the GAE forum--more than once--back in >>>> June, >>>> >> >> and never received a direct answer. However, the Servlet spec >>>> (version >>>> >> >> 2.4) has this to say (Section SRV.3.4.1): >>>> >> >> >>>> >> >> "Context attributes are local to the JVM in which they were >>>> >> >> created. This prevents ServletContext attributes from being a >>>> shared >>>> >> >> memory store in a distributed container. When information needs to >>>> be >>>> >> >> shared between servlets running in a distributed environment, the >>>> >> >> information should be placed into a session (See Chapter SRV.7, >>>> >> >> “Sessions”), stored in a database, or set in an Enterprise >>>> JavaBeansTM >>>> >> >> component." >>>> >> >> >>>> >> >> Therefore, my assumption is that there will be a separate >>>> >> >> ServletContext for each JVM instance--and possibly each >>>> application >>>> >> >> instance, if within the same JVM--that is created by GAE. (I >>>> posted >>>> >> >> this assumption on the GAE forum and was not contradicted--though >>>> also >>>> >> >> not confirmed either). >>>> >> >> >>>> >> >> Because the CFML Application scope in BD is implemented on top of >>>> the >>>> >> >> ServletContext, you will therefore get a different Application >>>> scope >>>> >> >> for each instance of your application created by GAE. So yes, >>>> >> >> "application.myvariable" might return different values for >>>> different >>>> >> >> instances of your application, just as it would if your >>>> application >>>> >> >> was deployed on several different servers within a cluster. >>>> >> >> >>>> >> >> According the GAE documentation: "App Engine includes an >>>> >> >> implementation of sessions, using the servlet session interface. >>>> The >>>> >> >> implementation uses the App Engine datastore and memcache to store >>>> >> >> session data." While I haven't tested this (yet), the implication >>>> is >>>> >> >> pretty clear than sessions are shared across instances of your >>>> >> >> application. Therefore "session.myvariable" should always return >>>> the >>>> >> >> same value across multiple instances of your application. Note >>>> that >>>> >> >> sessions are disabled by default and must be explicitly enabled; >>>> see >>>> >> >> the heading Enabling Sessions on the following page: >>>> >> >> >>>> >> >> >>>> http://code.google.com/appengine/docs/java/config/appconfig.html >>>> >> >> >>>> >> >> RE: "Will the app scope be reset quite often as machines spin up >>>> and >>>> >> >> down?" >>>> >> >> >>>> >> >> Possibly, yes. Google has not been very forthcoming regarding what >>>> to >>>> >> >> expect regarding how often and under what circumstances new >>>> instances >>>> >> >> of your application will be created or destroyed. >>>> >> >> >>>> >> >> RE: "Will it be the recommendation of openbd to favor memcached >>>> >> >> instead of those scopes?" >>>> >> >> >>>> >> >> Using the Session scope for per-user data is probably best. Doing >>>> >> >> "heavy" initialization of the Application scope is probably not a >>>> good >>>> >> >> idea; many applications and frameworks do this under the >>>> assumption >>>> >> >> that application initialization happens only once, but GAE turns >>>> this >>>> >> >> assumption on its head. It might be best to look to memcache to >>>> store >>>> >> >> data that might otherwise be stored in the Application scope, >>>> >> >> especially if you need to share this data across multiple >>>> instances of >>>> >> >> your application. >>>> >> >> >>>> >> >> RE: "what's the status and plans for memcached integration? Will >>>> it be >>>> >> >> transparently linked to the app scope, or will there be a specific >>>> set >>>> >> >> of functions to interact with it?" >>>> >> >> >>>> >> >> It's not likely that we'll transparently link the Application >>>> scope to >>>> >> >> memcache (though this is an interesting idea). One thought is to >>>> >> >> emulate the "Cluster" scope introduced by Railo and implement that >>>> >> >> scope on memcache (possibly backed by the datastore). Otherwise, >>>> we'll >>>> >> >> provide a specific set of functions to interact with memcache. >>>> >> >> >>>> >> >> RE: "For now, should I just use the datastore as my cache instead >>>> of >>>> >> >> app scope, session scope or memcached?" >>>> >> >> >>>> >> >> I would use the Session scope just as you normally would. For the >>>> >> >> Application scope, it depends what you're doing. If you're doing >>>> >> >> fairly lightweight initialization of values that don't change >>>> during >>>> >> >> the application lifetime, then I'd continue using the Application >>>> >> >> scope. If you're doing "heavy" initialization, or storing >>>> variables >>>> >> >> whose values change during the application lifetime, then I'd >>>> consider >>>> >> >> use CFOBJECT to interact with memcache directly (it would be >>>> pretty >>>> >> >> easy to write a set of CFML UDFs--or a CFC--to do this). I'd >>>> recommend >>>> >> >> using the low-level API rather than JCache: >>>> >> >> >>>> >> >> http://code.google.com/appengine/docs/java/memcache/ >>>> >> >> >>>> >> >> If you're feeling really adventurous, you might want to take a >>>> look at >>>> >> >> using the CachingDatastoreService (again, via CFOBJECT) that I've >>>> >> >> implemented for GaeVFS. This allows you to store values in the >>>> >> >> datastore with automatic caching in memcache: >>>> >> >> >>>> >> >> >>>> >> >> >>>> http://code.google.com/p/gaevfs/source/browse/trunk/src/com/newatlanta/appengine/datastore/CachingDatastoreService.java >>>> >> >> >>>> >> >> Note that the CachingDatastoreService is *not* included in the >>>> latest >>>> >> >> GaeVFS download, so you'll have to download the source and build >>>> it >>>> >> >> yourself. >>>> >> >> >>>> >> >> RE: "Additionally, does onApplicationStart() get invoked every >>>> time a >>>> >> >> new server spins up?" >>>> >> >> >>>> >> >> Yes. >>>> >> >> >>>> >> >> On Sun, Nov 1, 2009 at 4:24 PM, Bassil Karam <[email protected]> >>>> wrote: >>>> >> >>> >>>> >> >>> The way I understand it, GAE spins up and spins down servers to >>>> meet >>>> >> >>> the needs of an app - or even just because it feels like it. What >>>> >> >>> effects does this have on the *persistent* scopes (sorry Sean I >>>> know >>>> >> >>> you hate them being called that :) like application and session? >>>> More >>>> >> >>> specifically: >>>> >> >>> >>>> >> >>> - Are those scopes synchronized between machines? That is, could >>>> >> >>> application.myvariable return different values depending on which >>>> >> >>> machine it pulls it from? What about session scope? >>>> >> >>> - Will the app scope be reset quite often as machines spin up and >>>> >> >>> down? >>>> >> >>> - Will it be the recommendation of openbd to favor memcached >>>> instead >>>> >> >>> of those scopes? >>>> >> >>> >>>> >> >>> Which leads me to my next question: what's the status and plans >>>> for >>>> >> >>> memcached integration? Will it be transparently linked to the app >>>> >> >>> scope, or will there be a specific set of functions to interact >>>> with >>>> >> >>> it? For now, should I just use the datastore as my cache instead >>>> of >>>> >> >>> app scope, session scope or memcached? >>>> >> >>> >>>> >> >>> Thanks, >>>> >> >>> Baz >>>> >> >>> >>>> >> >>> >>>> >> >> >>>> >> >> > >>>> >> >> >>>> >> > >>>> >> > > >>>> >> > >>>> >> >>>> >> >>>> > >>>> > >>>> > > >>>> > >>>> >>>> >>>> >>>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
