Re: [appengine-java] Sub domain for static content

2011-03-07 Thread Nick Johnson (Google)
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

2011-02-16 Thread Nick Johnson (Google)
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

2010-10-07 Thread Nick Johnson (Google)
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

2010-05-10 Thread Nick Johnson (Google)
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

2010-03-30 Thread Nick Johnson (Google)
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?

2010-02-05 Thread Nick Johnson (Google)
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

2010-01-29 Thread Nick Johnson (Google)
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

2009-12-15 Thread Nick Johnson (Google)
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

2009-12-15 Thread Nick Johnson (Google)
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?

2009-11-26 Thread Nick Johnson (Google)
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?

2009-11-11 Thread Nick Johnson (Google)
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?

2009-11-10 Thread Nick Johnson (Google)
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?

2009-11-04 Thread Nick Johnson (Google)
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

2009-09-25 Thread Nick Johnson (Google)
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...

2009-09-16 Thread Nick Johnson (Google)
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...

2009-09-16 Thread Nick Johnson (Google)
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
-~--~~~~--~~--~--~---