Re: [appengine-java] Sub domain for static content
Hi Jeff, There's no way to distinguish based on domain in app.yaml/web.xml. You'll need to either have the same mappings in both (but only request static files off one of the domains) or use a servlet and serve them dynamically. -Nick Johnson On Mon, Mar 7, 2011 at 5:56 PM, Jeff Knox lairdk...@gmail.com wrote: I am sure this is a simple thing but my brain just doesn't want to make it so simple today. Say I point two sub-domains to my application: www.mydomain.com app.mydomain.com That is all well and good - both now serve up my application. What I would like is for the WWW sub-domain to serve up static HTML or JSP files while the APP sub-domain serves up my application. Is this something I can do in the web.xml mapping or do I need another servlet sitting on top to direct the requests to the correct place? Thanks -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Can't GET with parameters
Hi Bjorn, The -d argument to curl causes it to include the provided data in the body of the request. Since you're forcing it to make a GET request, it's generating an invalid request - GETs can't have bodies. -Nick Johnson On Thu, Feb 17, 2011 at 11:55 AM, bjorn beayoha...@gmail.com wrote: When I try running curl like this: curl -i -H Accept: application/xml -X GET https:///auth?a=bc=d; everything is fine. but when I try this: curl -i -H Accept: application/xml -X GET https:///auth; -d a=bc=d I get the error message documented below. I assume this is related to this bug, http://code.google.com/p/googleappengine/issues/detail?id=601, but I don't understand why I can't pass parameters in a GET, especially when everything works fine locally. Even if the RFCs forbid this (which I don't think they do) it is very common, and works on other systems. For example, what if my ReST API is using an API Key? Is there some workaround for this other than forcing users (and my test suite) into URL-style parameters? Thanks. bjorn HTTP/1.0 400 Bad Request Content-Type: text/html; charset=UTF-8 Content-Length: 1350 Date: Thu, 17 Feb 2011 00:34:51 GMT Server: GFE/2.0 htmlhead meta http-equiv=content-type content=text/html;charset=utf-8 title400 Bad Request/title style!-- body {font-family: arial,sans-serif} div.nav {margin-top: 1ex} div.nav A {font-size: 10pt; font-family: arial,sans-serif} span.nav {font-size: 10pt; font-family: arial,sans-serif; font-weight: bold} div.nav A,span.big {font-size: 12pt; color: #cc} div.nav A {font-size: 10pt; color: black} A.l:link {color: #6f6f6f} A.u:link {color: green} //--/style script!-- var rc=400; //-- /script /head body text=#00 bgcolor=#ff table border=0 cellpadding=2 cellspacing=0 width=100%trtd rowspan=3 width=1% nowrap bfont face=times color=#0039b6 size=10G/fontfont face=times color=#c41200 size=10o/fontfont face=times color=#f3c518 size=10o/fontfont face=times color=#0039b6 size=10g/fontfont face=times color=#30a72f size=10l/fontfont face=times color=#c41200 size=10e/fontnbsp;nbsp;/b tdnbsp;/td/tr trtd bgcolor=#3366ccfont face=arial,sans-serif color=#ffbError/b/td/tr trtdnbsp;/td/tr/table blockquote H1Bad Request/H1 Your client has issued a malformed or illegal request. p /blockquote table width=100% cellpadding=0 cellspacing=0trtd bgcolor=#3366ccimg alt= width=1 height=4/td/tr/table /body/html -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Google App Engine MUD
Hi MLS, Sounds like an interesting project! On Sat, Oct 2, 2010 at 4:02 AM, MLS mlsjunkm...@gmail.com wrote: My friend and I are looking to rewrite an old BBS MUD. The game is a few thousand rooms and purely text based with commands issued by individual players and the game responding and updating players stats based on the results of their commands. I do not have a programming background, and I'm wondering about the best way to approach writing it for GAE. Attempting to translate the game to objects, I have the following layout: World object holds all of the zone objects, zone objects hold rooms, room objects hold players, player objects hold inventory objects, spellbook objects, and attributes. Then write appropriate methods for manipulating the objects appropriately and returning the results. If by 'A holds B', you mean 'B has a reference to A', then yes, this sounds sensible. You only want to use parent/child relationships when you need to be able to update multiple entities in a single transaction. If you need this support, consider reducing the scope - eg, each zone could have an entity group containing all its rooms, and each player can form an entity group holding all their items. I have a few questions though: 1. Is this a technically correct way of approaching the problem? If not, what would be better? (keep in mind, I am not a professional programmer by any means. I can find my way if I have something already written to make changes, but I've never written anything from scratch before). Would I populate all these objects, then write world to the db and retrieve it for each player action? Yes, that's right. You wouldn't generally write the whole world at once, though - just the modified bits! I have no idea how servlets work to store state, or really how they work in general really. App servers are expected to be stateless on App Engine. All your state should be stored in the datastore or memcache. Basically, how would I be storing and retrieving stored player statistics which are constantly changing many times a second as players play the game. This is another reason to limit the size of your transaction (entity) groups. A single entity group can be updated at most a few times a second. 2. A key issue is the ability to push updates to players in real time, and track individuals who are connected. For example, I would like the ability to be able to call something like room[someroomnum].sendtoall(Some message here); to push a message to all players in that room, or player[someplayernum].send(some message here); to send replies to players directly. I understand this is a complex issue with the stateless http protocol, but I have read some about the upcoming channel API which sounds like it may offer this ability but I don't know enough to be certain. Yes, the channels API is exactly what you need for this. Overall I'm looking to avoid devoting countless hours to this project if it is going to be beyond my abilities to complete successfully. Have you considered language? Your mention of servlets implies you're considering using Java. If you're already familiar with Java, by all means use it, but if you're new to both Java and Python, I'd highly recommend starting with Python - you'll find a lot less boilerplate to deal with. Of course, I'm partisan. ;) -Nick Johnson Thanks very much for your time and consideration, MLS -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Deploying Google App Engine application with my own domain
Hi Srikanth, You need an Apps account in order to use a domain with your App Engine app. The Standard edtiion of Google apps is available for free, however: http://www.google.com/apps/intl/en/group/index.html -Nick Johnson On Mon, May 10, 2010 at 11:29 AM, Srikanth Gade srikanth.g...@gmail.comwrote: Hi, I have only bought a domain name. I want to deploy App Engine application with that domain. Do i need to buy with Google Apps account to deploy applications to my domain? Thanks Regards, Srikanth -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Objectify - Twig - SimpleDS articles
Hi Andreas, Excellent article! I've posted it to the App Engine reddit: http://www.reddit.com/r/AppEngine/comments/bk4kt/datastore_frameworks_the_interview/ Please feel free to post the followup article(s) there, too, to make sure they get a wide distribution! -Nick Johnson On Mon, Mar 29, 2010 at 9:03 AM, Andreas Borglin andreas.borg...@gmail.comwrote: Hi all. I recently decided to migrate away from JDO to one of the third party datastore frameworks. At first I had only heard about objectify, but after some further digging I found out about 5 other frameworks as well (Twig, SimpleDS, siena, slim3, cloud2db). I was only interested in simple wrapper frameworks that acted as a convenience layer above the AppEngine low-level API. I _want_ the framework to expose the true nature of the datastore, but at the same time relieve the developer of the tedious tasks that's involved when working with the low-level API directly. It is much easier to work with the AppEngine datastore when its concepts, features, constraints and limitations are exposed directly. You can read more about the reasons for this in the article. This left me with objectify, Twig and SimpleDS. (siena and cloud2db are multi-platform and slim3 is more than just a datastore framework) I spent some time researching these when I got the idea to write an article about them. I contacted the authors for each framework and asked if they would be interested in participating. Passionate as they are, they agreed :-). Thanks to Jeff Schnitzer (objectify), John Patterson (Twig) and Ignacio Coloma (SimpleDS) for this. The goal is to publish two articles; one interview with the authors, and one where I solve some typical scenario with each framework. The interview article has now been published and can be found at http://borglin.net/gwt-project/?page_id=604 . The code example article will be posted sometime in the upcoming two weeks. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] datacenter distribution policies?
Hi phracktle, Posts like this may be better suited to the google-appengine group, since they're not Java specific. On Thu, Feb 4, 2010 at 7:29 PM, phraktle phrak...@gmail.com wrote: Hi, Can the Google team please shed some light on the issue of multiple datacenters in various geographical locations pertaining GAE? I would like to understand what characteristics and what level of guarantees to expect from a GAE app, and didn't find any docs or posts on this... 1. Is static content delivered by a geographically distributed CDN? Would make sense for latency and international bandwidth costs. If you specify caching settings, yes, your content may be cached at the edges of our network. 2. Does GAE launch VMs of a single app in multiple datacenters? Same as above - latency would be quite bad for some geographical locations without this. No, currently we're single-homed, with failover. 3. If VMs are distributed, what's the deal with memcache? If it's distributed, does/can it split into distinct partitions? How does that affect atomic operations, such as increment, or things like grabTail? 4. If there's geographical distribution, how does it affect Datastore performance and latencies? My current (disappointing) impression based on latencies is that GAE VMs are not geographically distributed, based on the latencies. But would be good to get some clear information on this. In general, it would be quite useful to be able to monitor VMs better, eg. how many VM launches took place, where. This would provide more insight into the operation and performance of the app... (This may also be a stepping stone toward the pay to keep some VMs warm topic, an often requested feature - at least we could see ) Thanks, Viktor -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] jingle support on app engine
Hi, Sorry, but Jingle is not supported by App engine. You can't use a different stack for XMPP support, because App Engine apps cannot open sockets. -Nick Johnson On Thu, Jan 21, 2010 at 1:32 PM, maxsap max.saprani...@gmail.com wrote: Hello all, I am interested in using app engine in my application witch is using jingle, I have read about app engines xmpp support but would I be able to use jingle? also if the official xmpp support doesn't support jingle would I be able to use smack stack to do jingle? thanks in advanced maxsap -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Introducing App Engine SDK 1.3.0
Hi George, On Tue, Dec 15, 2009 at 11:34 AM, George Moschovitis george.moschovi...@gmail.com wrote: This is a long awaited feature. Some problems though: - Instead of the serve() helper I would expect access to the blobs through a url, something like: http://my-app.appenginebs.com/blob-key You can write a trivial handler to do this. The serve() helper simply sets a header in the response that is interpreted by the infrastructure to cause it to send the blob back to the user. This provides more flexibility than solely blobkey-based serving. - No support for organization in directories Blobs are just that - chunks of data. It's up to you to construct whatever heirarchy you wish in the datastore. -Nick Johnson - A method to manipulate the uploaded blobs is missing (for example cropping/resizing big images) - No free quota -g. On Dec 15, 6:00 am, Jason (Google) apija...@google.com wrote: Hi Everyone. We just released version 1.3.0 of the App Engine SDK for both Python and Java. The most notable change is the new experimental Blobstore API which allows billed apps to store files up to 50 MB. The release also includes some performance tweaks to the Java runtime. Blog post: http://googleappengine.blogspot.com/2009/12/app-engine-sdk-130-releas... Release notes: Python:http://code.google.com/p/googleappengine/wiki/SdkReleaseNotes Java: http://code.google.com/p/googleappengine/wiki/SdkForJavaReleaseNotes Cheers! - Jason -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Introducing App Engine SDK 1.3.0
On Tue, Dec 15, 2009 at 1:55 PM, George Moschovitis george.moschovi...@gmail.com wrote: is interpreted by the infrastructure to cause it to send the blob back to the user. What does 'interpreted' mean? is the actual file served from a separate infrastructure optimized for static files (in the future maybe from a CDN)? Part of the infrastructure between the user and your code sees the blobstore header in your response, and replaces the response with the contents of that blob. I would like to skip the dynamic request to the application, using an 'opaque' url could help here... You can do this with a trivial handler - a few lines of Python, and no datastore access or external libraries required. Blobs are just that - chunks of data. It's up to you to construct whatever heirarchy you wish in the datastore. you mean keeping another entity with hierarchy data separate from BlobInfo per Blob? Yes - just use a BlobReferenceProperty. -Nick thanks, -g. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: any plans for deferred.defer in Java?
Hi Vince, I haven't had a chance to integrate your code yet, so feel free to continue making modifications. In particular, I think it would be useful to provide the same set of options the Python deferred API accepts, which include 'eta' and 'countdown' parameters, as well as specifying the queue and URL. -Nick On Wed, Nov 25, 2009 at 7:03 PM, Vince Bonfanti vbonfa...@gmail.com wrote: Hi Jeff, Thanks for the suggestions and the code. David Chandler sent me a patch to support user-specified queue names (almost exactly the same as your changes), and I've committed that patch to SVN. Regarding your other changes: - I've probably make the url-pattern init parameter optional and have it default to /_ah/queue_name rather than throw an exception from the init method if it's missing. - While we're at it, the default queue name could be optionally specified by an init parameter also. - I'm not sure a stacktrace from the doPost method is really going to give you much more information, but would be open to that change. It looks like the Deferred class is going to be added to the official GAE/J SDK, though I'm not sure when. Rather than make any more changes to the code right now, I'd rather wait to see what shows up the SDK and then work through normal Google channels to get any further modifications made. In the mean time, I'm glad it's working for you. Vince On Tue, Nov 24, 2009 at 8:09 PM, Jeff Schnitzer j...@infohazard.orgwrote: Attached is a modified version of that class that lets you define any path you want for the servlet and lets you specify which queue to use like this: Deferred.defer(task, queueName); (I needed this for my own purposes) Do with it as you wish :-) The only other major change I would make is to stop masking all the exceptions during the task processing. Or at least, if you're going to log the exception and stop propagation, log the whole thing so we get a stacktrace in the logs. Jeff On Fri, Nov 20, 2009 at 1:03 PM, David Chandler turboman...@gmail.com wrote: Vince, this is great! I hadn't been watching my own issue, so didn't see this until now. Thanks so much! Only enhancement I would suggest is to enable multiple deferred queues. For example. I would like to defer tasks in an email throttle queue separately from a general background queue. Perhaps the Deferrable interface could have a getQueueName() method, or Deferred.defer could have an additional signature defer(Deferrable task, String queueName). Thanks again, /dmc -- -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.comgoogle-appengine-java%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: any plans for deferred.defer in Java?
Hi Vince, On Wed, Nov 11, 2009 at 2:07 PM, Vince Bonfanti vbonfa...@gmail.com wrote: Hi Nick, I'm taking this off-list for now. I've visited codereview.appspot.com, but am confused. I tried creating a new issue, but: - what do I specify for SVN base? Leave it blank if it'll let you - otherwise, use *http*:// googleappengine.googlecode.com/svn/trunk/java/ - it will only let me upload a patch file (not a java source file), but I'm not sure how to create a patch for a brand-new file? Try diff /dev/null /path/to/your/file. :) Can you offer some help? thanks. Vince On Tue, Nov 10, 2009 at 5:12 PM, Nick Johnson (Google) nick.john...@google.com wrote: Hi Vince, Thanks for doing this! Could you upload your code to codereview.appspot.com and link to it from the issue? We can continue the discussion there. -Nick On Tue, Nov 10, 2009 at 9:37 PM, Vince Bonfanti vbonfa...@gmail.com wrote: I've faxed over the CLA and created issue #2381 for this: http://code.google.com/p/googleappengine/issues/detail?id=2381 Here are the changes I've made since the original implementation: - The Deferrable.doTask method is now declared to throw Exception (instead of PermanentTaskFailure). This allows implementations to throw any subclass of Exception in order to have the task retried. (PermanentTaskFailure remains a subclass of Exception). - The Deferrable.doTask method no longer takes any arguments. - Removed the TaskHolder nested class since it's no longer needed. - Allow an extra 240 bytes for task overhead; in testing the actual overhead was 101 bytes, so this will leave some head-room. In addition, the IllegalArgumentException that's thrown if the task size is exceeded is caught (and logged), and the task it then written to the datastore. - An exception is logged if payload is not an instance of Deferrable. - If the task is written to the datastore and there's a subsequent failure to queue the task, the datastore entity is deleted. - Try twice for datatstore puts and deletes in case of DatastoreTimeoutException. - Try twice when queuing a task in case of TransientFailureException. - Added comments. Let me know if you have additional feedback. Vince On Sun, Nov 8, 2009 at 3:34 PM, Nick Johnson (Google) nick.john...@google.com wrote: Hi Vince, On Sun, Nov 8, 2009 at 7:58 PM, Vince Bonfanti vbonfa...@gmail.com wrote: Hi Nick, Thanks for your feedback. Yes, I'm very interested in seeing this included in the official SDK. What are the steps from here? See this doc: http://groups.google.com/group/google-appengine/web/how-to-submit-a-patch-to-the-sdk See responses to specific questions inserted below. Vince - Perhaps make PermanentTaskFailure a runtime exception, which would eliminate the need to declare it on methods that throw it. That's fine. I generally prefer checked exceptions, but if the AppEngine team prefers unchecked exceptions, I'm happy to make this change. I wouldn't say we prefer them in general - but personally, I think common uses of PermanentTaskFailure fit into the same sort of category as out of memory errors, divisions by zero, and so forth - they're not predictable at design-time. - If you do the above, you could make the Deferrable interface extend Runnable, as suggested in the meeting. I'm not sure that's appropriate, since the implications of Runnable are different. I think Runnable is not appropriate. I also looked at Callable, but in the end thought a new interface--Deferrable--was the best option. Fair enough. - I'm not sure there's any need to be able to pass arguments to the Deferrable, since users will already have to declare a deferrable class and instantiate it. I'm open to convincing, though. I put the arguments there to mimic the Python API and then realized later they're not really needed. Removing the arguments also simplifies the code by eliminating the need for the TaskHolder class--the Deferrable class could be serialized directly. I'm happy to remove the arguments if that's what the AppEngine team decides is best. Since the Java version is inevitably different due to the need for a custom class instead of a function object, I'd vote to drop the arguments. - Have you tested tasks of size exactly MaxTaskSizeBytes? At least in Python, the actual limit seems to include some overhead that varies from task to task. No, I haven't tested this yet. - If payload isn't an instance of TaskHolder, the task will silently return - it should log an error. I think the only way payload won't be an instance of TaskHolder is if the deserialize() method returns null, in which case an error has already been logged. But I'll double
[appengine-java] Re: any plans for deferred.defer in Java?
Hi Vince, Thanks for doing this! Could you upload your code to codereview.appspot.comand link to it from the issue? We can continue the discussion there. -Nick On Tue, Nov 10, 2009 at 9:37 PM, Vince Bonfanti vbonfa...@gmail.com wrote: I've faxed over the CLA and created issue #2381 for this: http://code.google.com/p/googleappengine/issues/detail?id=2381 Here are the changes I've made since the original implementation: - The Deferrable.doTask method is now declared to throw Exception (instead of PermanentTaskFailure). This allows implementations to throw any subclass of Exception in order to have the task retried. (PermanentTaskFailure remains a subclass of Exception). - The Deferrable.doTask method no longer takes any arguments. - Removed the TaskHolder nested class since it's no longer needed. - Allow an extra 240 bytes for task overhead; in testing the actual overhead was 101 bytes, so this will leave some head-room. In addition, the IllegalArgumentException that's thrown if the task size is exceeded is caught (and logged), and the task it then written to the datastore. - An exception is logged if payload is not an instance of Deferrable. - If the task is written to the datastore and there's a subsequent failure to queue the task, the datastore entity is deleted. - Try twice for datatstore puts and deletes in case of DatastoreTimeoutException. - Try twice when queuing a task in case of TransientFailureException. - Added comments. Let me know if you have additional feedback. Vince On Sun, Nov 8, 2009 at 3:34 PM, Nick Johnson (Google) nick.john...@google.com wrote: Hi Vince, On Sun, Nov 8, 2009 at 7:58 PM, Vince Bonfanti vbonfa...@gmail.com wrote: Hi Nick, Thanks for your feedback. Yes, I'm very interested in seeing this included in the official SDK. What are the steps from here? See this doc: http://groups.google.com/group/google-appengine/web/how-to-submit-a-patch-to-the-sdk See responses to specific questions inserted below. Vince - Perhaps make PermanentTaskFailure a runtime exception, which would eliminate the need to declare it on methods that throw it. That's fine. I generally prefer checked exceptions, but if the AppEngine team prefers unchecked exceptions, I'm happy to make this change. I wouldn't say we prefer them in general - but personally, I think common uses of PermanentTaskFailure fit into the same sort of category as out of memory errors, divisions by zero, and so forth - they're not predictable at design-time. - If you do the above, you could make the Deferrable interface extend Runnable, as suggested in the meeting. I'm not sure that's appropriate, since the implications of Runnable are different. I think Runnable is not appropriate. I also looked at Callable, but in the end thought a new interface--Deferrable--was the best option. Fair enough. - I'm not sure there's any need to be able to pass arguments to the Deferrable, since users will already have to declare a deferrable class and instantiate it. I'm open to convincing, though. I put the arguments there to mimic the Python API and then realized later they're not really needed. Removing the arguments also simplifies the code by eliminating the need for the TaskHolder class--the Deferrable class could be serialized directly. I'm happy to remove the arguments if that's what the AppEngine team decides is best. Since the Java version is inevitably different due to the need for a custom class instead of a function object, I'd vote to drop the arguments. - Have you tested tasks of size exactly MaxTaskSizeBytes? At least in Python, the actual limit seems to include some overhead that varies from task to task. No, I haven't tested this yet. - If payload isn't an instance of TaskHolder, the task will silently return - it should log an error. I think the only way payload won't be an instance of TaskHolder is if the deserialize() method returns null, in which case an error has already been logged. But I'll double-check this. The other possibility is that something else serialized an object and sent it to your task handler - or possibly, that a future version of your own code did so. I think logging an error (but returning a 200 status code) would be the best policy, so these sorts of situations are debuggable. -Nick Johnson Are you interested in having this included in the official SDK? -Nick On Sat, Oct 31, 2009 at 7:08 PM, Vince Bonfanti vbonfa...@gmail.com wrote: This looked like an interesting problem, and I already had most of the pieces in place, so here's my first attempt, which is implemented in a single class (also attached, along with some test files): http://code.google.com/p/gaevfs/source/browse/trunk/src/com/newatlanta/appengine/taskqueue/Deferred.java I'm more
[appengine-java] Re: Java namespace for entity in bulkloader?
On Wed, Nov 4, 2009 at 11:31 PM, Stuart Moffatt stuartmoff...@gmail.comwrote: Nick, Can you clarify what you mean by 'java loader' and 'hosted mode'? My java loader is a servlet which loads a CSV from disk, processes it and persists entities to the datastore. The CSV has the values for the properties I want my entity to have. The CSV and the data it points to is in WEB-INF, so I can get away with loading large sets in hosted mode and smaller sets in production (because of the static file limit and request timeout it is not possible to load all of my data in production using this method). The Kind is created when I persist that first entity. This is functionally similar to a python bulk loader, except it is a one-off servlet, and does not come with all of the configuration and transport mechanism options that provided by the python SDK. In the Python SDK, entities are named after the unqualified name of the class, by default - so a 'Film' gets loaded with an entity name of 'Film'. You can specify a custom entity type name with the kind() method. I'm still not hugely familiar with Java, so I'm not sure under which conditions it will use qualified and unqualified names - basically, you need to match those with your Python loaders. At one point I tried to convince bulkloader.py (using --kind=package.MyClass) and my custom bulk loader (bulkloader.Loader.__init__(self, 'package.MyClass')) to accept the full java package name, but even when I used namespaces in the python model, this did not work. Perhaps a python example for the kind() method you mention? Am I correct in assuming that I should provide a kind() method in my custom bulk loader which overrides the default in much the same way as handle_entity() or generate_key() gives you a hook into those functions? Pretty much, except kind() is a method for Model classes, not loaders. Like this: class Foo(db.Model): @classmethod def kind(self): return 'my.Foo' In other words, should I try this? class MyClass(db.Model): name = db.StringProperty() other_property = db.StringProperty() class MyClass(bulkloader.Loader): def __init__(self): bulkloader.Loader.__init__(self, 'MyClass', [('name', str), ('other_property', str) ]) def kind(self, entity): return 'package.MyClass' I understand if you can't provide a Java example, no worries. In lieu of that, could you provide a full example of customizing the python model's namespace using the kind() method in a custom bulkloader, along with the command line syntax to push it (with appcfg.py using the custom loader). As above, and specify the kind you declared in the Python module on the command line and in the loader. And if that's not enough grin it would be good to see the query syntax in the runtime application (e.g. SELECT * from package.MyName with the right python import statements). If you're using GQL, you need to use the kind name, not the class name (so in this example it would be SELECT * FROM my.Foo). -Nick Thanks for your help on this. Stuart -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] How to use the Python bulkloader for Java apps
I've written up a blog post describing how to use the Python bulkloader to load data into Java apps: http://blog.notdot.net/2009/9/Advanced-Bulk-Loading-Part-5-Bulk-Loading-for-Java -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: [google-appengine] using a variable to buffer cache data...
Hi Prashant, On Wed, Sep 16, 2009 at 3:54 PM, Prashant antsh...@gmail.com wrote: thanks nick. Actually I wanted to use Task Queue instead of Global LinkedList, but this task queue quota is very limited. i am expecting my app to reach at least 5 to 10 lacks queues per day. How many is a 'lacks'? -Nick 2009/9/16 Nick Johnson (Google) nick.john...@google.com Hi Prashant, In addition to what Barry says below, a couple of comments: - You can safely ignore the 'high cpu' warnings if you've already done what you can to optimize the page. You're not going to hit any invisible limits based on them, just the usual CPU quota etc. - If 'eventual' writes are good enough, you may want to look into using the task queue. You can enqueue the write in the task queue, which will do it offline and avoid making the user wait. -Nick Johnson On Wed, Sep 16, 2009 at 2:11 PM, Prashant antsh...@gmail.com wrote: hi, my app needs to store some data to datastore for each every request, say 1 object per request which causes high cpu usage per request. to minimize the cpu usage per request, instead of adding the object directly to datastore i add the object to a LinkedList (every request) and use a cron which moves objects form the LinkedList to datastrore periodically, say every min. I feel it is not a good practice. I don't want to use memcache (instead of server ram) to store my LinkedList because delay in fetching and storing the list form/to memcache may cause loss of data from upcomming requests (or previous request). I don't want to use task queue either for some reasons. Experts please comment on this kind of implementation. Losses Benefits, any alternative good practice. Thanks. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: [google-appengine] using a variable to buffer cache data...
Hi Prashant, The task queue quota for billed apps is currently set at 100,000. If you have a compelling use case for more tasks per day, we can increase your quota accordingly. -Nick On Wed, Sep 16, 2009 at 9:00 PM, Prashant antsh...@gmail.com wrote: ohh sorry, my bad, I meant Lakhs (1Lakh = 100, 000). 2009/9/16 Nick Johnson (Google) nick.john...@google.com Hi Prashant, On Wed, Sep 16, 2009 at 3:54 PM, Prashant antsh...@gmail.com wrote: thanks nick. Actually I wanted to use Task Queue instead of Global LinkedList, but this task queue quota is very limited. i am expecting my app to reach at least 5 to 10 lacks queues per day. How many is a 'lacks'? -Nick 2009/9/16 Nick Johnson (Google) nick.john...@google.com Hi Prashant, In addition to what Barry says below, a couple of comments: - You can safely ignore the 'high cpu' warnings if you've already done what you can to optimize the page. You're not going to hit any invisible limits based on them, just the usual CPU quota etc. - If 'eventual' writes are good enough, you may want to look into using the task queue. You can enqueue the write in the task queue, which will do it offline and avoid making the user wait. -Nick Johnson On Wed, Sep 16, 2009 at 2:11 PM, Prashant antsh...@gmail.com wrote: hi, my app needs to store some data to datastore for each every request, say 1 object per request which causes high cpu usage per request. to minimize the cpu usage per request, instead of adding the object directly to datastore i add the object to a LinkedList (every request) and use a cron which moves objects form the LinkedList to datastrore periodically, say every min. I feel it is not a good practice. I don't want to use memcache (instead of server ram) to store my LinkedList because delay in fetching and storing the list form/to memcache may cause loss of data from upcomming requests (or previous request). I don't want to use task queue either for some reasons. Experts please comment on this kind of implementation. Losses Benefits, any alternative good practice. Thanks. -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047 -- Nick Johnson, Developer Programs Engineer, App Engine --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~--~~~~--~~--~--~---