[appengine-java] Re: [google-appengine] using a variable to buffer & cache data...
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 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 --~--~-~--~~~---~--~~ 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 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) > >> 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 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 wrote: > ohh sorry, my bad, I meant Lakhs (1Lakh = 100, 000). > > > > 2009/9/16 Nick Johnson (Google) > >> Hi Prashant, >> >> On Wed, Sep 16, 2009 at 3:54 PM, Prashant 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) >>> >>>> 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 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 -~--~~~~--~~--~--~---
[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: Java namespace for entity in bulkloader?
Hi Stuart, I'm not sure why this would be happening. Your best option might be to insert a record using Java, then check how it shows up in the admin console, and make sure to use the exact same name for the kind you use in the Java loader. -Nick Johnson On Wed, Nov 4, 2009 at 6:25 PM, Stuart Moffatt wrote: > Maybe I didn't word my problem very well. > > Let me describe it again: > > Data push: > 1. I am bulkloading data to an app using python appcfg and custom > bulkloaders. > 2. The custom bulk loaders are pushing data from a CSV. > 3. The models of the data being pushed have simple names in python (no > package namespace) > 4. The entities all get successfully uploaded. > > Data query: > 1. The application that uses the data pushed via bulk loading is in > Java > 2. Because it's in Java, there is a package namespace for where my > entity classes exist > 3. App Engine is supposed to ignore the long package namespace and > just pick up the simple name (ie, the name of the class) > 4. These simple names are supposed to match the simple names of the > data that was pushed via bulk loading. > > The problem: > 1. Queries for the simple name via the admin interface return data as > expected > 2. Queries for the simple name via Java code do NOT return data as > expected. Instead I get a JDO error about the class not being found > (sorry, don't have my code in front of me to list the trace). > Basically, it seems that a query for a simple name throws an error > when that simple class name exists in a fully named package. > > I am using JDO annotations in my classes as per the tutorials. Is > there some magic that I am missing? Perhaps I am doing something wrong > with my annotations? > > I would rather post details, but wanted to get a handle on the general > problem before I bog down the list with a stack trace and entity code. > > Stuart > > On Nov 3, 5:06 pm, Stuart Moffatt wrote: > > I am using Nick's excellent tutorials on bulk loading, and was able to > > push a huge pile of entities up to production. Problem is, they looked > > like this: > > > > MySpecialEntity > > > > in my custom python bulkloader class and in production. > > > > The gotcha is my application is Java, and queries for: > > > > SELECT FROM org.domain.app.MySpecialEntity > > > > fail because the Javanamespacewas not part of the python bulkloader. > > > > Anyone know a workaround? > > > > 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] Re: Java namespace for entity in bulkloader?
On Wed, Nov 4, 2009 at 10:43 PM, Stuart Moffatt wrote:
> Nick,
>
> I've used a java loader in hosted mode (to spare the expense of doing it in
> production) for all of my entities. When I load them locally, /_ah/admin
> reports the simple name of the entity, with the right data. But my java code
> needs to query with the full package name.
>
Can you clarify what you mean by 'java loader' and 'hosted mode'?
>
> For instance, these work in hosted mode after entities loaded via Java
> loader
>
>- Query q = new Query(MyClass.class) // automatically passes full
>package name
>- Query q = new Query("package.MyClass") // manually pass full package
>name
>
> But these do not work in hosted mode after entities loaded via Java loader
>
>- Query q = new Query("SELECT * FROM MyClass") // simple name fails to
>map to package name
>- Query q = new Query(MyClass.class.getSimpleName()) // simple name
>fails to map to package name
>
> I am hoping I have explained this correctly. I got so confused yesterday
> trying to distinguish between:
>
>- working / not working (ie JDO error)
>- combined with hosted/production
>- combined with python/java loaders
>
> In your example at
> http://blog.notdot.net/2009/9/Advanced-Bulk-Loading-Part-5-Bulk-Loading-for-Java
> what
> is the corresponding java package name for the python model "Film"? Do
> s pushed via the bulk loader get returned when your Java code queries
> for Film.class or "SELECT * FROM Film"?
>
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.
-Nick
> I guess I am looking for validation (ie, working code) that entities pushed
> with a python bulkloader can be queried properly using Java. Like I said, I
> have probably got either the Query syntax wrong in the servlet or the
> annotations wrong in the class.
>
> If you add some Java code to the Film example, it would help immensely.
>
> Stuart
>
>
> On Wed, Nov 4, 2009 at 4:24 PM, Nick Johnson (Google) <
> nick.john...@google.com> wrote:
>
>> Hi Stuart,
>>
>> I'm not sure why this would be happening. Your best option might be to
>> insert a record using Java, then check how it shows up in the admin console,
>> and make sure to use the exact same name for the kind you use in the Java
>> loader.
>>
>> -Nick Johnson
>>
>>
>> On Wed, Nov 4, 2009 at 6:25 PM, Stuart Moffatt
>> wrote:
>>
>>> Maybe I didn't word my problem very well.
>>>
>>> Let me describe it again:
>>>
>>> Data push:
>>> 1. I am bulkloading data to an app using python appcfg and custom
>>> bulkloaders.
>>> 2. The custom bulk loaders are pushing data from a CSV.
>>> 3. The models of the data being pushed have simple names in python (no
>>> package namespace)
>>> 4. The entities all get successfully uploaded.
>>>
>>> Data query:
>>> 1. The application that uses the data pushed via bulk loading is in
>>> Java
>>> 2. Because it's in Java, there is a package namespace for where my
>>> entity classes exist
>>> 3. App Engine is supposed to ignore the long package namespace and
>>> just pick up the simple name (ie, the name of the class)
>>> 4. These simple names are supposed to match the simple names of the
>>> data that was pushed via bulk loading.
>>>
>>> The problem:
>>> 1. Queries for the simple name via the admin interface return data as
>>> expected
>>> 2. Queries for the simple name via Java code do NOT return data as
>>> expected. Instead I get a JDO error about the class not being found
>>> (sorry, don't have my code in front of me to list the trace).
>>> Basically, it seems that a query for a simple name throws an error
>>> when that simple class name exists in a fully named package.
>>>
>>> I am using JDO annotations in my classes as per the tutorials. Is
>>> there some magic that I am missing? Perhaps I am doing something wrong
>>> with my annotations?
>>>
>>> I would rather post details, but wanted to get a handle on the general
>>> problem before I bog down the list with a stack trace an
[appengine-java] Re: Java namespace for entity in bulkloader?
On Wed, Nov 4, 2009 at 11:31 PM, Stuart Moffatt wrote:
> 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 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] Re: any plans for deferred.defer in Java?
Hi Vince, On Sun, Nov 8, 2009 at 7:58 PM, Vince Bonfanti 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 > 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 than happy to contribute this for inclusion in the SDK. > >> > >> Some caveats: > >> > >> 1) Because of issue #2097 > >> (http://code.google.com/p/googleappengine/issues/detail?id=2097), this > >> doesn't work on the development server (it does work in production). > >> So go star that issue! > >> > >> 2) I've only done minimal testing on the production server (see the > >> attached test files). > >> > >> 3) This post is the only documentation that's currently available. > >> > >> First, add the following your your web.xml: > >> > >> > >>Deferred > >> > >> > com.newatlanta.appengine.taskqueue.Deferred > >> > >> > >>Deferred > >>/_ah/queue/deferred > >> > >> > >> Second, define the "deferred" queue within queue.xml (use whatever > >> rate you want): > >> > >> > >>deferred > >>10/s > >> > >> > >> Next, create a class that implements the > >> com.newatlanta.appengine.taskqueue.Deferred.Deferrable interface; the > >> "doTask()" method of this class is where you implement your task > >> logic. > >> > >> Then, invoke the com.newatlanta.appengine.taskqueue.Deferred.defer() > >> method to queue up your task: > >> > >>TestDeferred testDeferred = new TestDeferred(); // implements > >> Deferrable > >>Deferred.defer( testDeferred, "one", "two", "three", 1, 2, 3 ); > >> > >> (Note that it would be possible to pass arguments as attributes to > >> your Deferrable instance, rather than using varargs; I'm not sure it > >> makes much difference which you choose). > >> > >> Just as for the Python implementation, if the arguments size exceeds > >> 10KB, the arguments are stored in a datastore entity, which i
[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 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) > wrote: > > Hi Vince, > > > > On Sun, Nov 8, 2009 at 7:58 PM, Vince Bonfanti > 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
[appengine-java] Re: any plans for deferred.defer in Java?
Hi Vince, On Wed, Nov 11, 2009 at 2:07 PM, Vince Bonfanti 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) > 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 > 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) > >> wrote: > >> > Hi Vince, > >> > > >> > On Sun, Nov 8, 2009 at 7:58 PM, Vince Bonfanti > >> > 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 no
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 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 init parameter optional and have > it default to "/_ah/" 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 wrote: > >> 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 >> 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.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)" 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.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.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 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.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 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.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] 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 wrote: > 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.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] 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 wrote: > 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.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] Disable Single Property Indexes
Hi James, It's not possible to disable just the single property indexing. If you exclude a property from being indexed, it won't be included in these indexes, but it won't be included in any composite indexes, either. -Nick Johnson On Wed, Jun 30, 2010 at 3:04 PM, James wrote: > Is there a way to disable the automatic single-propery indexes using > JDO? Can they be disabled on data that already exists, or would I > need to create an entirely new Kind? > > -- > 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. > > -- 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] Google App Engine MUD
Hi MLS,
Sounds like an interesting project!
On Sat, Oct 2, 2010 at 4:02 AM, MLS 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.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] 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 wrote: > When I try running curl like this: > > curl -i -H "Accept: application/xml" -X GET "https:///auth?a=b&c=d"; > > everything is fine. > > but when I try this: > > curl -i -H "Accept: application/xml" -X GET "https:///auth"; -d > "a=b&c=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 > > > > > > 400 Bad Request > > > > > > width=1% nowrap> > G color=#c41200 size=10>o size=10>og face=times color=#30a72f size=10>l size=10>e > > color="#ff">Error > > > Bad Request > Your client has issued a malformed or illegal request. > > > > bgcolor="#3366cc"> > > > -- > 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] 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 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.
