[google-appengine] HRD Migration is stuck for 2 days now

[Arun Ramanuj]

We are trying to migrate from Master/Slave to an HRD application, but the 
migration seems to be stuck at Copy for more than 2 days with the message:

Running: 54923 entities processed (570 per second), 2 of 612 shards remaining


I've raised a ticket with Google, but not response on it even after 2 days 
(app. ID is in the ticket):

https://code.google.com/p/googleappengine/issues/detail?id=9315&q=HRD&colspec=ID%20Type%20Component%20Status%20Stars%20Summary%20Language%20Priority%20Owner%20Log

Does anyone know what could be the reasons? Can someone from Google please 
help? I had hoped for a better HRD migration experience, but being stuck 
and having no idea of what is going on is not making us feel any good!

Thanks,
Arun

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] App Engine Server Error

[Phantom17]

there's a server error at mass-automation.com. This is a service I use, and 
I have no way to contact them. When I go to the Page, it displays SERVER 
ERROR and links here. I have no idea what's going on here, but it appears 
mass-automation is using google apps engine server or something. Who do I 
report the server error to?

Thanks
Todd

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Migration to HRD and Billing options

[Ale]

 

Hi,

I would like to migrate my datastore from master/slave to high replication 
but I have credit in my billing options. I would like to be sure that I 
will continue to have those credits after the migration.

I am asking this because in the migration document 
(https://developers.google.com/appengine/docs/adminconsole/migration) it 
says that "You must manually set any other features needed for the new 
application such as the following: - Billing" and I think there's no way to 
copy the credit, so how can I do that?

Where can I get more info about this?

Thanks!


-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Management of Id Allocation

[Christophe Pruvost]

Hi all,

I deploy my application then I use Id Allocation and get a range from 
Club(1) To Club(10)

I redeployed my application then I use Id Allocation and get a range from 
Club(1001) To Club(1010)

So my question : what is the expected behavior for id allocation ? please 
give some details

Each time I redeploy the I increase the sequence by 1000 ?

I want to flush the Club Data so I would like to get a new Sequence 
beginning from Club(1)...is it possible to do that ? What kind of action 
could I have on this sequence generator ...I do not find information on 
that ?

Thank you for all

Christophe.

PS : My code : KeyRange keyRangeClub = datastore.allocateIds("Club", 10);

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Large number of URLFetch timeouts in last two weeks or so

[ngriso]

Hello,

As we're experiencing the same problem, I filled a issue 
(https://code.google.com/p/googleappengine/issues/detail?id=9325) 

Like you, John, we had to code a workaround to no be too much affected by 
this problem.
But it's still very annoying.

Thanks
Nicolas

On Thursday, May 16, 2013 5:38:09 AM UTC+2, John Wheeler wrote:
>
> Hello,
>
> Recently, for about the last two weeks or so, I have been receiving a 
> larger than normal number of URLFetch timeouts when communicating with 
> eBay's Trading API. I opened up a ticket with eBay thinking it was them, 
> but they ran diagnostics and said that all the attempts I made to connect 
> with their API have  succeeded. The eBay developer support person had me 
> log my errors to their API calls and return the log to them with timestamps.
>
> My application makes around 3600 eBay API calls per hour or one per 
> second. About every two minutes, one times out. I have implemented retries 
> and tried all sorts of timeout settings. I have even offloaded the calls to 
> the taskqueue to get the 10 minute maximum deadline instead of the 1 minute 
> regular deadline. It doesn't seem to matter.
>
> This is not really affecting me because I have coded around it with the 
> retries, but it really bothers me because I don't know why this started or 
> is happening. Can anyone chime in with similar experience?
>
> Thanks,
> John
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: datastore admin not working?

[Malte Meister]

The blank page problem seems to be related to ah-builtin asking for access 
to your email address, which for some reason doesn't work inside the 
iframe. Once you've opened the iframe src in a new tab and given it access, 
it loads in the iframe too.
Also see here: http://stackoverflow.com/a/14463757

On Tuesday, 15 January 2013 21:58:55 UTC+2, Takashi Matsuo (Google) wrote:
>
>
> Elad,
>
> Thanks and good to hear it works in a new window. Can you bear with this 
> workaround?
> I think it's an edge case bug with your current situation, can you file a 
> bug in our issue tracker for further investigation?
>
>
> On Tue, Jan 15, 2013 at 12:37 AM, Elad Winkler 
> > wrote:
>
>> Hi Takashi,
>> Thanks for your relpy,
>> The datastore admin does open in a new window, I saw that in the original 
>> window it's blocked by 
>> x-frame-options:
>> Deny
>>
>> both in chrome and firefox..
>>
>> On Tuesday, January 15, 2013 1:53:44 AM UTC+2, Takashi Matsuo (Google) 
>> wrote:
>>
>>>
>>> Hi Elad,
>>>
>>> Can you grab the actual HTTP response when it happens? You can use 
>>> Chrome dev tool for it.
>>> The datastore admin runs in an iframe. Can you try opening the URL for 
>>> the iframe in a new browser window?
>>>
>>> Thanks,
>>>
>>>
>>> On Sun, Jan 13, 2013 at 12:31 AM, Elad Winkler wrote:
>>>
 Hi Takashi,

 I've tried re-enabling with no success.
 My app-id is: arsstage

 Thanks.


 On Thursday, January 10, 2013 8:19:02 PM UTC+2, Takashi Matsuo (Google) 
 wrote:

>
> Hi Elad,
>
> Have you tried re-enabling the datastore admin? If that didn't help, 
> can you tell me your app-id?
>
>
> On Thu, Jan 10, 2013 at 1:38 AM, Elad Winkler wrote:
>
>> For a while now I have been trying also to go to the Datastore Admin 
>> with no success,
>> Enabling and disabling also didn't work, even with 5 minute wait (in 
>> between and after)
>> I also tried chrome incognito window. 
>> I either get a nothing or "Datastore Admin is loading and will be 
>> ready momentarily."
>> Are  there any more step that I can take in order to resolve this?
>>
>> Thanks,
>> Elad.
>>
>>
>>
>> On Monday, September 17, 2012 9:21:41 PM UTC+3, Bill Strathearn wrote:
>>>
>>> As a workaround, if you disable Datastore Admin, then re-enable, you 
>>> should be able to use it.
>>>
>>> On Friday, September 14, 2012 9:36:55 AM UTC-7, sebastián serrano 
>>> wrote:

 Hi,
   Is anybody else also getting: "Datastore Admin is loading and 
 will be ready momentarily." accesing the datastore admin?
   It has been like that all day.

 -Sebastian
 www.devsar.com

>>>  -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Google App Engine" group.
>> To view this discussion on the web visit https://groups.google.com/d/
>> **ms**g/google-appengine/-/**R91uwFldq**wEJ
>> .
>>  
>> To post to this group, send email to google-a...@googlegroups.**com.
>> To unsubscribe from this group, send email to google-appengi...@**
>> googlegroups**.com.
>>
>> For more options, visit this group at http://groups.google.com/**
>> group**/google-appengine?hl=en
>> .
>>
>
>
>
> -- 
> Takashi Matsuo | Developers Advocate | tma...@google.com
>  
  -- 
 You received this message because you are subscribed to the Google 
 Groups "Google App Engine" group.
 To view this discussion on the web visit https://groups.google.com/d/**
 msg/google-appengine/-/**Mj32ltFpM7cJ
 .

 To post to this group, send email to google-a...@googlegroups.**com.
 To unsubscribe from this group, send email to google-appengi...@**
 googlegroups.com.
 For more options, visit this group at http://groups.google.com/**
 group/google-appengine?hl=en
 .

>>>
>>>
>>>
>>> -- 
>>> Takashi Matsuo | Developers Advocate | tma...@google.com
>>>  
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Google App Engine" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/google-appengine/-/yAHX24bt5dIJ.
>>
>> To post to this group, send email to 
>> google-a...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> google-appengi...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/google-appengine?hl=en.
>>
>
>
>
> -- 
> Takashi Matsuo | Developers Advocate | tma...@google.com 
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Goo

[google-appengine] Re: Can't restore backups of objects that contain blobfields with compress=True

[troberti]

A similar problem (or the same problem) is when you edit (ie. save) a 
entity with a compressed property in the Datastore viewer. The compressed 
property cannot be loaded afterwards. I have filed an issue on the ndb 
issue 
tracker: http://code.google.com/p/appengine-ndb-experiment/issues/detail?id=202 
but it does not seem to be high priority.

On Thursday, May 16, 2013 1:38:25 PM UTC+2, Emlyn wrote:
>
> Hi,
>
> Python 2.7, ndb. This probably requires someone from the appengine team.
>
> I'm getting inconsistent failures when restoring instances of this object 
> from backup:
>
> class Event(ndb.Model):
> dtStored = ndb.DateTimeProperty(auto_now_add = True)
> strType = ndb.StringProperty()
> keyClient = ndb.KeyProperty()
> keyAssertingPrincipal = ndb.KeyProperty()
> txtData = ndb.TextProperty(compressed = True)
> keysRelated = ndb.StringProperty(repeated = True)
> version = ndb.IntegerProperty()
>
> It's the only type that causes problems.
>
> When I restore it, the mapreduce tasks fail (see below). I do get a 
> handful of objects (less than 20, when there are a couple of thousand).
>
> Of the objects that do load, there's another issue; the blobs don't know 
> they're compressed, and load incorrectly. The issue is detailed here: 
> https://code.google.com/p/googleappengine/issues/detail?id=8599
>
> I've actually got a workaround for that, so the only real problem is that 
> all the objects don't load.
>
> datastore_backup_restore_datastore_backup_2013_05_16Job 
> #15811165735318781AA47 
> Processed items per shard
> Overview
>
>- Failed 
>- Elapsed time: 00:03:25
>- Start time: 16/5/2013 20:54:09
>- files: 
>
> ["/blobstore/AMIfv97SZ99dXOQM_mnRvAM0zq46DVrNbtTIgHNldiWKhvZm_Gya_gaAaaH8FmUO44MyCgd7uWIlE4zjC3NnLuw0w3v8aU2GZxOellbwnMjPoy4LdyKhI_TAL9xFFi60UGLfYXIILT-g0PHyfs6HvbqOslDqxNf7eKRGyg-KZTJZnbLrZ6AV46Y","/
>
> blobstore/AMIfv95f1-rDfkt9mU8tpjDSZFItFygt0T8wudsKbQzZGyZJZXOGLQTQylONwc9hpQJioJX3OIV8OJ2XmPLrP4I23BXefgTVyt6Ftc7Hnk2kmnFIVXcDaFwBsYwvjGKhwvY2aYicSM6W7MuED1XuXZFEIEUq378d7I50Nqa7wyADoS7ZTvxJvvA","/blobstore/AMIfv95J9-gr38xASdG532e6PRzVbRzgCpcofSM9bkHBUjJp4LlpfdbeUavUxBcd8gNxNja6is5H5QNNWpD3NgU_AYIP1-0zC4-fLcGq2_mBS-fKg_owihzibI8p35RW5yQK8s6XHS4MGGyxYw9IKZcLvknqJ6ZTLcW2ZqqhaXL_5dH8l1nrrvI","/blobstore/AMIfv94yitrEvcVwe0qUNegoTxu3_IRqknWnvy_iEieoaMVgjA1jbMoU31hMS4zcN8Rfb6-nehAhrL1A02d9HIz2v6O76Az9w98-iXW2tIc4DU8HX5Yw-59T2-IVF3kdK60UQM7nebsboVZMKzFZ5BubNGXEATlN0EV_jYc6Mx3fXiN3MOcaXrg","/blobstore/AMIfv95igj5MqPIMPYte9O_yyRvlWFApsDquW-XKXYKtbB36PCcnoJdG1fkefapX6ijnSMoSTaF_NnEVqcZF7dNuTQNoUnbAOOHzDwDuZpX1pNIrPzPXP3IGBChjEvknB6SfTQXAG8MhU5CSpj4qztyYeGQRpAAaF0UyGNOGj0QO3IYh0hXWgQ8","/blobstore/AMIfv96E9ULQbP0LocTy9gcPyRcS3R6kSlcmeWsCbFSLd_Gmyqq-1tX-IyBZL_TKYYsqNSe9_T9usaVsGAHVj9BpCd76SLiDG3vrebqmfiFQt91sizGRQKUoIqjDvB6jBX5cn2wMwAzgaj19hOyhU9mKW7ooLIZkbNbOp2Udf4hueV8mbvBCwJY","/blobstore/AMIfv96ruBqhkI3QHpegsd-SM2kM1RM9xOpyVggJRJHNJe5guB7F9Yzz9DkfADvX4JqrbJl8TwXuRtZZP2O_27oHSSVu2zdErd7D2pUBuZod5ivm7Gl7jg7FdiSdgaaKQw6PZSTj_CGVZ55PMdCgy7hrtjaqQLBbqmoVCcs5u1mo-diZ3QDYyZY","/blobstore/AMIfv9432ZpwBD6v_0LqKKtDmoShp0XndRJSl-R_DUHUleVp12EbIR0cxPGUsnZcnEGRFDsDd0PsfvDiWjUsYKZUY_LPko_gcKdIvEEKDOHbLm8jp3ESTdSUAosFIja-3-JJWJnqgaumeGbw9_Kmv6wCB27os1i203v61d1PCNL5jYVPiqYTcno"]
>
> Collapse
>  
>- kind_filter: ["Event"]
>- namespace: null
>- original_app: null 
>
> Counters
>
>- io-read-bytes: 28696 (139.98/sec avg.) 
>- io-read-msec: 410 (2/sec avg.)
>- mapper-calls: 29 (0.14/sec avg.)
>
> Mapper status ShardStatusDescriptionLast work itemTime elapsed 0 
> failed[u'/blobstore/AMIfv97SZ99dXOQM_mnRvAM0zq46DVrNbtTIgHNldiWKhvZm_Gya_gaAaaH8FmUO44MyCgd7uWIlE4zjC3NnLuw0w3v8aU2GZxOellbwnMjPoy4LdyKhI_TAL9xFFi60UGLfYXIILT-g0PHyfs6HvbqOslDqxNf7eKRGyg-KZTJZnbLrZ6AV46Y']:0'jXj\x0es~tes-test-ecarF\x0b\x12\teventtype"\x08assessor\x0c\x0b\x12\x05Event"$870ad402-6e77-4f49-8000:03:001failed[u'/blobstore/AMIfv95f1-rDfkt9mU8tpjDSZFItFygt0T8wudsKbQzZGyZJZXOGLQTQylONwc9hpQJioJX3OIV8OJ2XmPLrP4I23BXefgTVyt6Ftc7Hnk2kmnFIVXcDaFwBsYwvjGKhwvY2aYicSM6W7MuED1XuXZFEIEUq378d7I50Nqa7wyADoS7ZTvxJvvA']:0'jXj\x0es~tes-test-ecarF\x0b\x12\teventtype"\x08assessor\x0c\x0b\x12\x05Event"$0492ea38-82d4-4554-8600:03:002failed[u'/blobstore/AMIfv95J9-gr38xASdG532e6PRzVbRzgCpcofSM9bkHBUjJp4LlpfdbeUavUxBcd8gNxNja6is5H5QNNWpD3NgU_AYIP1-0zC4-fLcGq2_mBS-fKg_owihzibI8p35RW5yQK8s6XHS4MGGyxYw9IKZcLvknqJ6ZTLcW2ZqqhaXL_5dH8l1nrrvI']:0'jXj\x0es~tes-test-ecarF\x0b\x12\teventtype"\x08assessor\x0c\x0b\x12\x05Event"$bd85aa67-7dce-4661-a600:03:013failed[u'/blobstore/AMIfv94yitrEvcVwe0qUNegoTxu3_IRqknWnvy_iEieoaMVgjA1jbMoU31hMS4zcN8Rfb6-nehAhrL1A02d9HIz2v6O76Az9w98-iXW2tIc4DU8HX5Yw-59T2-IVF3kdK60UQM7nebsboVZMKzFZ5BubNGXEATlN0EV_jYc6Mx3fXiN3MOcaXrg']:0'jXj\x0es~tes-test-ecarF\x0b\x12\teventtype"\x08assessor\x0c\x0b\x12\x05Event"$a78573d4-a20a-4fcd-8000:03:004failed[u'/blo

Re: [google-appengine] Large number of URLFetch timeouts in last two weeks or so

[ngriso]

Hello,

Same for us too.
I filled an issue about this problem: 
https://code.google.com/p/googleappengine/issues/detail?id=9325

I'm quite sure too it's GAE infra issue.



On Thursday, May 16, 2013 2:25:19 PM UTC+2, Joshua Smith wrote:
>
> I'm seeing a larger than normal number of URLFetch timeouts to servers in 
> our own data center, and to Google Analytics. I increased the "deadline" 
> parameter in my urlfetch calls, and it had no effect.
>
> It also started a couple weeks ago.
>
> I'd say this is a GAE infrastructure issue.
>
> On May 15, 2013, at 11:38 PM, John Wheeler 
> > 
> wrote:
>
> Hello,
>
> Recently, for about the last two weeks or so, I have been receiving a 
> larger than normal number of URLFetch timeouts when communicating with 
> eBay's Trading API. I opened up a ticket with eBay thinking it was them, 
> but they ran diagnostics and said that all the attempts I made to connect 
> with their API have  succeeded. The eBay developer support person had me 
> log my errors to their API calls and return the log to them with timestamps.
>
> My application makes around 3600 eBay API calls per hour or one per 
> second. About every two minutes, one times out. I have implemented retries 
> and tried all sorts of timeout settings. I have even offloaded the calls to 
> the taskqueue to get the 10 minute maximum deadline instead of the 1 minute 
> regular deadline. It doesn't seem to matter.
>
> This is not really affecting me because I have coded around it with the 
> retries, but it really bothers me because I don't know why this started or 
> is happening. Can anyone chime in with similar experience?
>
> Thanks,
> John
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to google-appengi...@googlegroups.com .
> To post to this group, send email to google-a...@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/google-appengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Marcel Overdijk]

Jeff,

You seem to give up on App Engine...

I feel disappointed that Google advises not to use DI, hardcode configs etc 
to speed up the startup times.
It feels like going back to the middle ages of Java software development.

Until now I have only deployed apps being used by a couple of users. So I 
keep the warm with a cron job; only 1 instance is enough (and it never 
shuts down).
This also means for these apps I don't bother about the startup time.

But if I would build a scalable app which would spin up multiple instances 
based on current load, startup times do become important.
And in that case 10s or 30s is no difference, it should be max 5s or 
something...

I just uploaded a basic Jersey app without DI and no classpath scanning.
With 1 simple rest resource startup time was 16.9s :-(

^M



On Thursday, May 16, 2013 6:14:20 PM UTC+2, Jeff Schnitzer wrote:
>
> No, I'm not "overrating" with my subject. Your ill-educated opinion about 
> DI is not shared by the countless Java developers who find these tools 
> essential for building large, complicated, testable applications.
>
> The apparent reasoning behind those points is that Google still thinks 
> "startup time is your problem", and routes user requests to cold starts. 
> This works in Go but it will never work in Java. The last time I made a 
> Hello, World app with JPA it took 4-5 seconds to startup in production. 
> Somewhere around 5 seconds is where the user thinks your app is broken and 
> hits the reload button.  If Google Search pages took 5 seconds to load for 
> a significant percentage of users, heads would roll.
>
> If your app actually _does something_ it's going to take more than 5s to 
> load. Maybe you can make it 10s instead of 30s by adopting 2000s-era 
> programming practices, but it doesn't matter because the user has already 
> considered your app broken.
>
> And don't get me started on the frequent "sick periods" where startup time 
> goes up by 3X...
>
> Jeff
>
>
>
> On Thu, May 16, 2013 at 9:22 AM, de Witte 
> > wrote:
>
>> Aren't you a bit overrating with your subject title?
>>
>> Dependency injection a la guice and spring, are frameworks which you want 
>> to avoid as much as possible.
>>
>>
>> Op donderdag 16 mei 2013 01:52:51 UTC+2 schreef Jeff Schnitzer het 
>> volgende:
>>
>>> I attended the "Autoscaling Java" session at Google I/O. In summary, the 
>>> advice is:
>>>
>>>  * Don't use dependency injection.
>>>  * Don't use AOP.
>>>  * Hardcode configuration values as much as possible.
>>>
>>> In other words, go back to Java circa 2002. There was no discussion of 
>>> changing routing so that user requests don't see cold starts. I asked about 
>>> this in person - apparently they're still "talking about it" and nothing 
>>> has been done about it.
>>>
>>> I am sad.
>>>
>>> Jeff
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] 503 Error When Deploying

[Brendon Duncan]

I tried deploying this morning only to get a 503 error. I retried several 
times and the error continued.  I'm using Go. 

I then tried deploying with --no_precompilation.  The console told me that 
deployment succeeded. When I navigated to my site in a browser, it failed 
to come up, instead reporting a server error.

In the admin console reverted to a previously deployed and "known good" 
version.  This also now reports a server error instead of serving up pages.

Is anyone else expereincing this, is it a known issue?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Jon Sawyer]

Your last sentence says it all - "Or at least it should be". The reality is
that we work with flawed tools, and that needs to be taken into account
with everything else.

Not that Objectify has any flaws, you understand. :-)

Jon


On Thu, May 16, 2013 at 11:21 PM, Jeff Schnitzer wrote:

> This problem has occurred in the past with GAE/Python apps of sufficient
> complexity, but yeah, Java has always assumed a lot of work at startup to
> load, link, and JIT your app.  GAE assumes that your application will
> always start in a time that is reasonable for a user request. This is an
> invalid assumption for pretty much any substantial Java app.
>
> "Selecting the right programming language" is a lot more about the
> complexity of your app, the makeup of your team, and the availability of
> libraries than it is about picking the language most optimized for GAE. Or
> at least it should be.
>
> Jeff
>
>
> On Thu, May 16, 2013 at 7:58 PM, Jon Sawyer  wrote:
>
>> How much of this issue is endemic to Java's design, and therefore would
>> require significant engineering on Google's part to fix? They seem to have
>> determined the ROI isn't high enough for them to invest here.
>>
>> Is it just fundamental to the way that Java must unpack jars, and JIT the
>> bytecode, and ... ???
>>
>> Isn't Python's by-line "batteries included", indicating that the standard
>> runtime contains the kitchen sink? Is the Python environment richer
>> out-of-the-box than Java's, so you don't need to doctor it with Guice,
>> Objectify, Guava, etc.?
>>
>> This is partly an academic question, since I suspect the only people who
>> really know work at Google and aren't talking. But it's partly a learning
>> exercise; I like the idea of leveraging a PaaS environment like GAE. I've
>> been productive making use of Guice and Objectify (Thanks, Jeff!), but in
>> the future it seems that selecting the right programming environment and
>> language may be a key success factor in leveraging a PaaS application
>> delivery environment if other languages start out with significant
>> disadvantages in that environment.
>>
>>
>> On Thursday, May 16, 2013 7:40:19 PM UTC-6, Jeff Schnitzer wrote:
>>
>>> I haven't given up on GAE yet, although I came pretty close to it after
>>> walking out of that I/O session. I've actually spent almost all my free
>>> time over the last few weeks trying to get the next Objectify release out
>>> the door.
>>>
>>> By DI the speaker meant Guice, Spring, CDI, etc. By AOP he meant the
>>> interceptors that Guice, Spring, etc can create for you. I've never been a
>>> fan of Spring, but my app would be unmaintainable without some sort of DI
>>> system (I use Guice). And I tend to use a fair number of interceptors,
>>> especially around JAX-RS methods. If someone had told me at the beginning
>>> "if you want to use GAE, you must hand-wire your services and copy-paste
>>> shared logic all over your code", I would have gone elsewhere.
>>>
>>> GAE is a productive environment, but all that productivity will
>>> disappear if I have to write spaghetti code to perform in production.
>>>
>>> The number of classes and jax-rs endpoints in my app is continuing to
>>> expand, and all the classloading is pushing up my startup time. I'm never
>>> going to have a large number of instances; as a ticketing system, people
>>> tend to come to my website when they want to buy something. High value per
>>> customer, but very bursty traffic.
>>>
>>> The speaker had one suggestion that looks valuable - use Dagger instead
>>> of Guice - which might help, although it doesn't look like Dagger supports
>>> interceptors, so that may be out.
>>>
>>> I've been doing a lot of consulting on other people's
>>> Heroku/Appfog/EC2/EB/etc projects (sadly, GAE consulting doesn't pay well).
>>> Honestly I think no-autoscaling is better than GAE/Java's autoscaling.
>>> Elastic Beanstalk has the best solution - it's easy to understand, easy to
>>> configure, and doesn't produce dead user requests. Also, I forgot how much
>>> I miss being able to execute ad-hoc queries or queries that update data...
>>> and hosted MongoDB is getting cheaper.
>>>
>>> This is not to say that these other systems are better that GAE; they
>>> all have pretty serious flaws. But it's hard to get over dead user requests.
>>>
>>> Jeff
>>>
>>>
>>>
>>> On Thu, May 16, 2013 at 8:08 PM, Nick  wrote:
>>>
 I don't really understand the philosophy currently in play here.

 Obviously when load goes up, new instances need to be spun up. That
 makes sense.
 The idea that its better for the last invoker to wait 5-10 seconds,
 rather than sharing a reduced latency of say 0.5 seconds by being sent to a
 'fully' utilised instance just doesn't make sense to me. The
 characteristics of this also result in being more punishing when you have a
 low number of instances, which tends to happen if you have frequent
 releases.

 It would be good to get some insight into w

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Tomas Adamek]

Hi Jeff

thanks for heads up.

I one of the "early java gae adopters" and it really makes me sad to see 
how google kills quite awesome platform with such decisions - I went 
through simple servlet app to full scale Spring MVC (with all usual stuff 
like ehcache/velocity/others) and after major disappointment last year with 
cold starts and startup issues on GAE (Spring MVC simply didn't load in 60s 
interval sometimes, google was spinning/killing instance in couple of 
seconds) I ended up with this solution for http://www.librarist.com/:

1) I run Web frontend on Appfog (Spring MVC with Rest/Velocity/Ehache) - 
this piece is responsible for fetching all data from backend and caching 
them for user
2) REST backend runs on App engine - this part is done in multiple separate 
app engine application and it's build on own hacked spring-like minimal 
container which allow me to do some very simple DI/MVC/REST+JSON 
(configured in old good XML, no anotations no AOP) - cold start is usually 
4-5 secs and the app is fully serving then. As I said I have split all the 
app "modules" into separate applications which reduces number of request 
per app (so some apps with longer runnign request doesn't hold back app 
with faster requests). 

- cover app for fetching and displaying book covers
- book data app for fetching/storing all book related information
- pricing app which operates with external grabbers (grabbers run in 
parallel in different cloud providers aka Heroku/Appengine/Appfog/Openshif 
and I'm going to experiment with Amazon spot instances as well)

I've done this infrastructure change 2-3 months ago and as far as I can say 
it works fine (I'm having minimal latency in all of my app engine apps, 
usually run only one instance but google handles scaling very nicely now).

I'm not saying this is the only way to go since I know such design is not 
suit for every kind of application and our weak spot is now at frontend 
cloud provider (which is appfog at the moment and seems little bit unstable 
last couple of days) but I just would like to share my experience.

If anyone would like to see how the librarist works the good start would be 
the New Zealand front store (with 30+ suppliers) ie. 
http://www.librarist.com/nz/book/9780007310579/ - it usually does an 
instant price comparison on those 30+ shops in 2-4 secs (and I believe that 
now we should be able to keep such time even with more suppliers thanks to 
modular and parallel design of our backend).

Best regards

Tomas.

On Thursday, 16 May 2013 11:52:51 UTC+12, Jeff Schnitzer wrote:
>
> I attended the "Autoscaling Java" session at Google I/O. In summary, the 
> advice is:
>
>  * Don't use dependency injection.
>  * Don't use AOP.
>  * Hardcode configuration values as much as possible.
>
> In other words, go back to Java circa 2002. There was no discussion of 
> changing routing so that user requests don't see cold starts. I asked about 
> this in person - apparently they're still "talking about it" and nothing 
> has been done about it.
>
> I am sad.
>
> Jeff
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Large number of URLFetch timeouts in last two weeks or so

[John Wheeler]

Starred. Thanks


On Thu, May 16, 2013 at 2:44 AM, ngriso  wrote:

> Hello,
>
> Same for us too.
> I filled an issue about this problem:
> https://code.google.com/p/googleappengine/issues/detail?id=9325
>
> I'm quite sure too it's GAE infra issue.
>
>
>
>
> On Thursday, May 16, 2013 2:25:19 PM UTC+2, Joshua Smith wrote:
>
>> I'm seeing a larger than normal number of URLFetch timeouts to servers in
>> our own data center, and to Google Analytics. I increased the "deadline"
>> parameter in my urlfetch calls, and it had no effect.
>>
>> It also started a couple weeks ago.
>>
>> I'd say this is a GAE infrastructure issue.
>>
>> On May 15, 2013, at 11:38 PM, John Wheeler 
>> wrote:
>>
>> Hello,
>>
>> Recently, for about the last two weeks or so, I have been receiving a
>> larger than normal number of URLFetch timeouts when communicating with
>> eBay's Trading API. I opened up a ticket with eBay thinking it was them,
>> but they ran diagnostics and said that all the attempts I made to connect
>> with their API have  succeeded. The eBay developer support person had me
>> log my errors to their API calls and return the log to them with timestamps.
>>
>> My application makes around 3600 eBay API calls per hour or one per
>> second. About every two minutes, one times out. I have implemented retries
>> and tried all sorts of timeout settings. I have even offloaded the calls to
>> the taskqueue to get the 10 minute maximum deadline instead of the 1 minute
>> regular deadline. It doesn't seem to matter.
>>
>> This is not really affecting me because I have coded around it with the
>> retries, but it really bothers me because I don't know why this started or
>> is happening. Can anyone chime in with similar experience?
>>
>> Thanks,
>> John
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-appengi...@**googlegroups.com.
>> To post to this group, send email to google-a...@googlegroups.**com.
>>
>> Visit this group at http://groups.google.com/**
>> group/google-appengine?hl=en
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google App Engine" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-appengine/WI-Cy34aPQc/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] App Engine Server Error

[Google Tasks Backup Moderator]

Hi Todd,

When I go to http://mass-automation.com/ I am redirected to
http://support.mass-automation.com/ which appears to display correctly for
me (using Chrome on Windows 8 desktop mode, in Australia).

It may be that they had a temporary application or server problem.

Cheers,

Julie


On 16 May 2013 09:24, Phantom17  wrote:

> there's a server error at mass-automation.com. This is a service I use,
> and I have no way to contact them. When I go to the Page, it displays
> SERVER ERROR and links here. I have no idea what's going on here, but it
> appears mass-automation is using google apps engine server or something.
> Who do I report the server error to?
>
> Thanks
> Todd
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Re: Can't restore backups of objects that contain blobfields with compress=True

[Emlyn]

I agree, that's totally a problem. I can cope with that though, if only I
could restore my backups!


On 16 May 2013 22:05, troberti  wrote:

> A similar problem (or the same problem) is when you edit (ie. save) a
> entity with a compressed property in the Datastore viewer. The compressed
> property cannot be loaded afterwards. I have filed an issue on the ndb
> issue tracker:
> http://code.google.com/p/appengine-ndb-experiment/issues/detail?id=202but it 
> does not seem to be high priority.
>
> On Thursday, May 16, 2013 1:38:25 PM UTC+2, Emlyn wrote:
>>
>> Hi,
>>
>> Python 2.7, ndb. This probably requires someone from the appengine team.
>>
>> I'm getting inconsistent failures when restoring instances of this object
>> from backup:
>>
>> class Event(ndb.Model):
>> dtStored = ndb.DateTimeProperty(auto_now_**add = True)
>> strType = ndb.StringProperty()
>> keyClient = ndb.KeyProperty()
>> keyAssertingPrincipal = ndb.KeyProperty()
>> txtData = ndb.TextProperty(compressed = True)
>> keysRelated = ndb.StringProperty(repeated = True)
>> version = ndb.IntegerProperty()
>>
>> It's the only type that causes problems.
>>
>> When I restore it, the mapreduce tasks fail (see below). I do get a
>> handful of objects (less than 20, when there are a couple of thousand).
>>
>> Of the objects that do load, there's another issue; the blobs don't know
>> they're compressed, and load incorrectly. The issue is detailed here:
>> https://code.google.com/**p/googleappengine/issues/**detail?id=8599
>>
>> I've actually got a workaround for that, so the only real problem is that
>> all the objects don't load.
>>
>> datastore_backup_restore_**datastore_backup_2013_05_16Job
>> #15811165735318781AA47
>> Processed items per shard
>> Overview
>>
>>- Failed
>>- Elapsed time: 00:03:25
>>- Start time: 16/5/2013 20:54:09
>>- files: ["/blobstore/**AMIfv97SZ99dXOQM_**
>>mnRvAM0zq46DVrNbtTIgHNldiWKhvZ**m_Gya_**gaAaaH8FmUO44MyCgd7uWIlE4zjC3N
>>**nLuw0w3v8aU2GZxOellbwnMjPoy4Ld**yKhI_TAL9xFFi60UGLfYXIILT-**
>>g0PHyfs6HvbqOslDqxNf7eKRGyg-**KZTJZnbLrZ6AV46Y","/blobstore/**
>>AMIfv95f1-**rDfkt9mU8tpjDSZFItFygt0T8wudsK**
>>bQzZGyZJZXOGLQTQylONwc9hpQJioJ**X3OIV8OJ2XmPLrP4I23BXefgTVyt6F**
>>tc7Hnk2kmnFIVXcDaFwBsYwvjGKhwv**Y2aYicSM6W7MuED1XuXZFEIEUq378d**
>>7I50Nqa7wyADoS7ZTvxJvvA","/**blobstore/AMIfv95J9-**
>>gr38xASdG532e6PRzVbRzgCpcofSM9**bkHBUjJp4LlpfdbeUavUxBcd8gNxNj**
>>a6is5H5QNNWpD3NgU_AYIP1-0zC4-**fLcGq2_mBS-fKg_**
>>owihzibI8p35RW5yQK8s6XHS4MGGyx**Yw9IKZcLvknqJ6ZTLcW2ZqqhaXL_**
>>5dH8l1nrrvI","/blobstore/**AMIfv94yitrEvcVwe0qUNegoTxu3_**IRqknWnvy_**
>>iEieoaMVgjA1jbMoU31hMS4zcN8Rfb**6-**nehAhrL1A02d9HIz2v6O76Az9w98-**
>>iXW2tIc4DU8HX5Yw-59T2-**IVF3kdK60UQM7nebsboVZMKzFZ5Bub**NGXEATlN0EV_**
>>jYc6Mx3fXiN3MOcaXrg","/**blobstore/**AMIfv95igj5MqPIMPYte9O_**
>>yyRvlWFApsDquW-**XKXYKtbB36PCcnoJdG1fkefapX6ijn**SMoSTaF_**
>>NnEVqcZF7dNuTQNoUnbAOOHzDwDuZp**X1pNIrPzPXP3IGBChjEvknB6SfTQXA**
>>G8MhU5CSpj4qztyYeGQRpAAaF0UyGN**OGj0QO3IYh0hXWgQ8","/**blobstore/**
>>AMIfv96E9ULQbP0LocTy9gcPyRcS3R**6kSlcmeWsCbFSLd_Gmyqq-1tX-**
>>IyBZL_TKYYsqNSe9_**T9usaVsGAHVj9BpCd76SLiDG3vrebq**
>>mfiFQt91sizGRQKUoIqjDvB6jBX5cn**2wMwAzgaj19hOyhU9mKW7ooLIZkbNb**
>>Op2Udf4hueV8mbvBCwJY","/**blobstore/**AMIfv96ruBqhkI3QHpegsd-**
>>SM2kM1RM9xOpyVggJRJHNJe5guB7F9**Yzz9DkfADvX4JqrbJl8TwXuRtZZP2O**_**
>>27oHSSVu2zdErd7D2pUBuZod5ivm7G**l7jg7FdiSdgaaKQw6PZSTj_**
>>CGVZ55PMdCgy7hrtjaqQLBbqmoVCcs**5u1mo-diZ3QDYyZY","/blobstore/**
>>AMIfv9432ZpwBD6v_**0LqKKtDmoShp0XndRJSl-R_**
>>DUHUleVp12EbIR0cxPGUsnZcnEGRFD**sDd0PsfvDiWjUsYKZUY_LPko_**
>>gcKdIvEEKDOHbLm8jp3ESTdSUAosFI**ja-3-JJWJnqgaumeGbw9_**
>>
>> Kmv6wCB27os1i203v61d1PCNL5jYVP**iqYTcno"]Collapse
>>- kind_filter: ["Event"]
>>- namespace: null
>>- original_app: null
>>
>> Counters
>>
>>- io-read-bytes: 28696 (139.98/**sec avg.)
>>- io-read-msec: 410 (2/sec avg.)
>>- mapper-calls: 29 (0.14/sec avg.)
>>
>> Mapper status ShardStatusDescriptionLast work itemTime elapsed 0 
>> failed[u'/blobstore/
>> **AMIfv97SZ99dXOQM_**mnRvAM0zq46DVrNbtTIgHNldiWKhvZ**m_Gya_**
>> gaAaaH8FmUO44MyCgd7uWIlE4zjC3N**nLuw0w3v8aU2GZxOellbwnMjPoy4Ld**
>> yKhI_TAL9xFFi60UGLfYXIILT-**g0PHyfs6HvbqOslDqxNf7eKRGyg-**
>> KZTJZnbLrZ6AV46Y']:0 'jXj\x0es~tes-test-ecarF\x0b\**
>> x12\teventtype"\x08assessor\**x0c\x0b\x12\x05Event"$**
>> 870ad402-6e77-4f49-80 00:03:00 1 failed [u'/blobstore/AMIfv95f1-**
>> rDfkt9mU8tpjDSZFItFygt0T8wudsK**bQzZGyZJZXOGLQTQylONwc9hpQJioJ**
>> X3OIV8OJ2XmPLrP4I23BXefgTVyt6F**tc7Hnk2kmnFIVXcDaFwBsYwvjGKhwv**
>> Y2aYicSM6W7MuED1XuXZFEIEUq378d**7I50Nqa7wyADoS7ZTvxJvvA']:0'jXj\x0es~tes-test-ecarF\x0b\
>> **x12\teventtype"\x08assessor\**x0c\x0b\x12\x05Event"$**
>> 0492ea38-82d4-4554-86 00:03:00

Re: [google-appengine] Bad news for GAE/Java from Google I/O

[Rafael]

Hello de,

Any chance you're a python dev?

This is a phenomenal statement to make: Dependency injection a la guice and
spring, are frameworks which you want to avoid as much as possible.

In any case, i believe that coding java like the Stone Age is not an excuse
for the lack of support and features on the appengine platform. Developers
won't buy these excuses.

If you're doing a hello world project you  may not care about writing ugly
and painful code. I believe that java devs are spoiled with at least bare
minimum spring mvc.

If real java dev isn't ever going to be supported, it should be at least
clearly stated before people even try the platform and bet their business
and life's on it.

Have fun :)

Rafa

On Thursday, May 16, 2013, de Witte wrote:

> Aren't you a bit overrating with your subject title?
>
> Dependency injection a la guice and spring, are frameworks which you want
> to avoid as much as possible.
>
>
> Op donderdag 16 mei 2013 01:52:51 UTC+2 schreef Jeff Schnitzer het
> volgende:
>>
>> I attended the "Autoscaling Java" session at Google I/O. In summary, the
>> advice is:
>>
>>  * Don't use dependency injection.
>>  * Don't use AOP.
>>  * Hardcode configuration values as much as possible.
>>
>> In other words, go back to Java circa 2002. There was no discussion of
>> changing routing so that user requests don't see cold starts. I asked about
>> this in person - apparently they're still "talking about it" and nothing
>> has been done about it.
>>
>> I am sad.
>>
>> Jeff
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com  'cvml', 'google-appengine%2bunsubscr...@googlegroups.com');>.
> To post to this group, send email to 
> google-appengine@googlegroups.com 'google-appengine@googlegroups.com');>
> .
> Visit this group at http://groups.google.com/group/google-appengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [google-appengine] Unhappy with Windows SDK / Devappserver / 1.8.0

[Moises Belchin]

Oh, I'm so sorry, but thanks so much for the report.




Saludos.
Moisés Belchín.


2013/5/16 Kaan Soral 

> Let me save you the time, those solutions wouldn't solve your problem, as
> far as I know, search documents aren't in the datastore
>
>
> On Thursday, May 16, 2013 12:03:06 PM UTC+3, Moises Belchin wrote:
>
>> The same problem for me, every time I started dev_appserver all my Full
>> Text Search documents are gone.
>> I read something about --datastore_path and --clear_datastore parameters
>> for dev_appserver but I don't test them yet.
>> http://stackoverflow.com/**questions/7991558/app-engine-**
>> development-datastore-cleared-**each-time-i-turn-off-my-**computer-how
>> http://stackoverflow.com/**questions/10998936/app-engine-**
>> datastore-auto-clears-every-**time-project-runs
>>
>> Regards.
>>
>>
>> Saludos.
>> Moisés Belchín.
>>
>>
>> 2013/5/16 Kaan Soral 
>>
>>> I've just updated to 1.8.0 hoping that my search api issues would be
>>> fixed ( http://code.google.com/p/**googleappengine/issues/detail?**
>>> id=9088 )
>>> however they are not fixed, whenever I reset the devappserver, all
>>> search documents are gone, I'm not sure where they are supposed to be,
>>> don't see a documents database file anywhere. (I've played around with all
>>> dev_appserver arguments, --search_indexes is just a 1kb file always, I
>>> think there should be a seperate --search_documents argument / file)
>>>
>>> I also tested the SDK/GUI to check whether it does anything special,
>>> rather than running dev_appserver command like I do, however I was unable
>>> to shutdown/reset the app from the GUI, the "stop" button was unable to
>>> stop the app, so I killed them all and continued using the command line
>>> argument.
>>>
>>> Also I didn't test whether I have a newly introduced network issue or
>>> not, but after upgrading to 1.8.0 I'm unable to reach the app externally
>>> although I use 0.0.0.0 as the --host
>>> I will run the old version of devappserver from my backups to check
>>> whether it's indeed an issue with the 1.8.0.
>>>
>>> Generally speaking, it would be great if we can learn everything in the
>>> changelog, 1.8.0 changelog was disappointingly short.
>>>
>>> Is it just me with these problems?
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Google App Engine" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-appengi...@**googlegroups.com.
>>> To post to this group, send email to google-a...@googlegroups.**com.
>>>
>>> Visit this group at http://groups.google.com/**
>>> group/google-appengine?hl=en
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-appengine+unsubscr...@googlegroups.com.
> To post to this group, send email to google-appengine@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-appengine?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] cant login with google

[Newbee]

Its not exactly a GAE question but still hope you all will help me.
I am trying to login with google+ from one of my web app but i am getting 
the following error : Error:origin_mismatch
Heres the code.I have done and copy pasted whatever was given on their 
website.




  (function() {
   var po = document.createElement('script'); po.type = 
'text/javascript'; po.async = true;
   po.src = 'https://apis.google.com/js/client:plusone.js';
   var s = document.getElementsByTagName('script')[0]; 
s.parentNode.insertBefore(po, s);
 })();



 http://schemas.google.com/AddActivity";
   data-scope="https://www.googleapis.com/auth/plus.login";>
 



  function signinCallback(authResult) {
  if (authResult['access_token']) {
// Successfully authorized
// Hide the sign-in button now that the user is authorized, for example:
document.getElementById('signinButton').setAttribute('style', 'display: 
none');
  } else if (authResult['error']) {
// There was an error.
// Possible error codes:
//   "access_denied" - User denied access to your app
//   "immediate_failed" - Could not automatically log in the user
// console.log('There was an error: ' + authResult['error']);
  }
}
  

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Vinny P]

+1 to Jeff and this thread.

I was at the same I/O session, and I received the same impression of 
Java/GAE as Jeff. The recommendation against DI/AOP is a big issue, 
considering how many Java frameworks and abstractions depend upon those. 

-
-Vinny P
Technology & Media Advisor
Chicago, IL

My Go side project: http://invalidmail.com/

On Thursday, May 16, 2013 11:14:20 AM UTC-5, Jeff Schnitzer wrote:
>
> No, I'm not "overrating" with my subject. 
>
> The apparent reasoning behind those points is that Google still thinks 
> "startup time is your problem", and routes user requests to cold starts. 
> This works in Go but it will never work in Java. The last time I made a 
> Hello, World app with JPA it took 4-5 seconds to startup in production. 
> Somewhere around 5 seconds is where the user thinks your app is broken and 
> hits the reload button.  If Google Search pages took 5 seconds to load for 
> a significant percentage of users, heads would roll.
>
> If your app actually _does something_ it's going to take more than 5s to 
> load. Maybe you can make it 10s instead of 30s by adopting 2000s-era 
> programming practices, but it doesn't matter because the user has already 
> considered your app broken.
>
> And don't get me started on the frequent "sick periods" where startup time 
> goes up by 3X...
>
> Jeff
>
>
>
> On Thu, May 16, 2013 at 9:22 AM, de Witte 
> > wrote:
>
>> Aren't you a bit overrating with your subject title?
>>
>> Dependency injection a la guice and spring, are frameworks which you want 
>> to avoid as much as possible.
>>
>>
>> Op donderdag 16 mei 2013 01:52:51 UTC+2 schreef Jeff Schnitzer het 
>> volgende:
>>
>>> I attended the "Autoscaling Java" session at Google I/O. In summary, the 
>>> advice is:
>>>
>>>  * Don't use dependency injection.
>>>  * Don't use AOP.
>>>  * Hardcode configuration values as much as possible.
>>>
>>> In other words, go back to Java circa 2002. There was no discussion of 
>>> changing routing so that user requests don't see cold starts. I asked about 
>>> this in person - apparently they're still "talking about it" and nothing 
>>> has been done about it.
>>>
>>> I am sad.
>>>
>>> Jeff
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: How to create new folder using Google Drive API ??

[Vinny P]

On Wednesday, May 15, 2013 11:58:34 AM UTC-5, prateek bansal wrote:

> Thanks Vinny for reply :)
>
> the Link which you mention is for php .I need Java code.
>

The link is https://developers.google.com/drive/folder which does not 
contain any PHP code. It is a standard REST/JSON response which can be 
parsed with any JSON library, such as the ones listed here: 
http://stackoverflow.com/questions/338586/a-better-java-json-library .

Assuming you are using the Java Google Drive library (available here: 
http://code.google.com/p/google-api-java-client/wiki/APIs#Drive_API ) the 
relevant code to create a directory is basically:

File body = new File();
body.setTitle("Folder-Name-Here");
body.setMimeType("application/vnd.google-apps.folder");
File file = service.files().insert(body).execute();
folderId = file.getId();


(Ignore the "File" object, Google Drive treats directories as a special 
"file")


-
-Vinny P
Technology & Media Advisor
Chicago, IL

My Go side project: http://invalidmail.com/

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] User Service and G+ integration

[D X]

It seems like G+ SSO is a big deal at this year's I/O.

I've been using the User service for authentication, and G+ SSO would 
supercede the User service in every way.
Are there any plans to have the User service integrated with the G+ SSO 
features described at I/O, or is this something we'll have to do on our own?

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Tom]

The recommendation to use Dagger seems to have some merit and it would seem 
to make some sense that Google would push towards Dagger, given its 
suitability for Android.  I use GAE/J as a backend to Android (and based on 
io13 sessions, Google is rather pushing this) so things that work well on 
both GAE/J and Android are attractive.  

On a general note, at the end of the keynote someone asked a question 
suggesting that Google's dependency on a language they don't control was a 
big problem.  I hope that is not the reason behind the lack of progress on 
GAE/J.  I realize that is a common mentality but it is a sad state of 
affairs and it seemed to me to go against the thrust of Page's speech.

Tom

On Friday, May 17, 2013 10:35:31 AM UTC-4, Vinny P wrote:
>
> +1 to Jeff and this thread.
>
> I was at the same I/O session, and I received the same impression of 
> Java/GAE as Jeff. The recommendation against DI/AOP is a big issue, 
> considering how many Java frameworks and abstractions depend upon those. 
>
> -
> -Vinny P
> Technology & Media Advisor
> Chicago, IL
>
> My Go side project: http://invalidmail.com/
>
> On Thursday, May 16, 2013 11:14:20 AM UTC-5, Jeff Schnitzer wrote:
>>
>> No, I'm not "overrating" with my subject. 
>>
>> The apparent reasoning behind those points is that Google still thinks 
>> "startup time is your problem", and routes user requests to cold starts. 
>> This works in Go but it will never work in Java. The last time I made a 
>> Hello, World app with JPA it took 4-5 seconds to startup in production. 
>> Somewhere around 5 seconds is where the user thinks your app is broken and 
>> hits the reload button.  If Google Search pages took 5 seconds to load for 
>> a significant percentage of users, heads would roll.
>>
>> If your app actually _does something_ it's going to take more than 5s to 
>> load. Maybe you can make it 10s instead of 30s by adopting 2000s-era 
>> programming practices, but it doesn't matter because the user has already 
>> considered your app broken.
>>
>> And don't get me started on the frequent "sick periods" where startup 
>> time goes up by 3X...
>>
>> Jeff
>>
>>
>>
>> On Thu, May 16, 2013 at 9:22 AM, de Witte  wrote:
>>
>>> Aren't you a bit overrating with your subject title?
>>>
>>> Dependency injection a la guice and spring, are frameworks which you 
>>> want to avoid as much as possible.
>>>
>>>
>>> Op donderdag 16 mei 2013 01:52:51 UTC+2 schreef Jeff Schnitzer het 
>>> volgende:
>>>
 I attended the "Autoscaling Java" session at Google I/O. In summary, 
 the advice is:

  * Don't use dependency injection.
  * Don't use AOP.
  * Hardcode configuration values as much as possible.

 In other words, go back to Java circa 2002. There was no discussion of 
 changing routing so that user requests don't see cold starts. I asked 
 about 
 this in person - apparently they're still "talking about it" and nothing 
 has been done about it.

 I am sad.

 Jeff

>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: User Service and G+ integration

[Tom]

+1.  

I didn't actually see those sessions so I'm not sure about the technical 
details, but I note that the new endpoints service is largely based on 
passing a User object around - I wonder whether that User object can also 
be used to represent a G++ user.  Otherwise I wonder whether the endpoints 
folks will need to make some changes to respond to this new emphasis on G++ 
sign-in.  

I disagree that G+ sign-in supersedes User sign in in every way.  For one 
thing, they recently made it so that the act of installing an Android app 
with accounts permissions (e.g. accepting those permissions) is the same as 
granting the app access to your account - for the most basic level of 
authentication only.  For apps that are not social, this is awesome - no 
need to prompt the user at all, and you can depend on having this.

Tom

On Friday, May 17, 2013 2:11:35 PM UTC-4, D X wrote:
>
> It seems like G+ SSO is a big deal at this year's I/O.
>
> I've been using the User service for authentication, and G+ SSO would 
> supercede the User service in every way.
> Are there any plans to have the User service integrated with the G+ SSO 
> features described at I/O, or is this something we'll have to do on our own?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] New Cloud Backends - app authentication

[Tom]

I caught some of the Cloud Backends session and was interested in their 
discussion of app (vs. user) authentication.  I realize Cloud Backends are 
new, but is this method of app authentication new?

I'd like to use it in my (non CB) Android+GAE apps.  Is there documentation 
or sample code available - other than in CB itself - for this?  Does it 
support multiple Android apps authenticating against a single backend? 
 I've been looking at endpoints but was under the impression that endpoints 
only automates User authentication.

If there is no separate docs available then that is fine - I'll just go and 
download the backends libraries - but thought I would ask about it first.

Thanks.  Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Science!

[Vinny P]

On Thursday, May 16, 2013 8:30:06 AM UTC-5, pdknsk wrote:
>
> Google Compute Engine added a new f1-micro instance which is only 
> $0.019/h but has 600MB RAM. In comparison, B1 backends with 128MB RAM 
> are $0.08/h currently. So for 4x the price you get 1/5 RAM. 


To add in an anecdotal data point: The Compute Engine's f1-micro instances 
are FAST! Soon after Compute Engine went into general availability, I 
created and sshed into a f1-micro instance then ran a few tests (apt-get 
packages, download some files, etc). I was pleasantly surprised by how fast 
and responsive the machine was. It's much better than Amazon AWS' micro 
instance, which can only do bursty processing and just feels very anemic.

It might be interesting - if anyone has an app that does a lot of backend 
work - to move that work onto a Compute Engine machine, and then open up 
additional backends if load spikes.


On Thursday, May 16, 2013 11:26:19 AM UTC-5, Jeff Schnitzer wrote:
>
> Interesting that the datastore is now available from GCE. I suspect some 
> of the other services are on their way too.  This may eventually become 
> much more like Gala vs Golden Delicious.
>
> If the GCE<->Datastore connection is fast, it makes migrating off of GAE 
> quite a lot easier.
>

When I was configuring my Compute Engine machine, I saw options to 
integrate into Task Queue and BigQuery. It wouldn't surprise me at all to 
see further services opened up such as the Search API.


-
-Vinny P
Technology & Media Advisor
Chicago, IL

My Go side project: http://invalidmail.com/

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Ryan Chazen]

Very unfortunate, but it's been clear that GAE/J has been getting the short 
end of the stick for awhile. Given the heavy costs for doing anything 
'heavy' on GAE/J, and the prevalence of new hosting providers that can give 
you a full 8 core VM for similar prices to GAE's incredibly underpowered 
(and limited) instances, it seems like the right thing to do at this point 
is to bite the bullet and manage a few servers yourself. Often a pair of 8 
core servers can do the same work load as an enormous number of GAE 
instances without any worry of strange app engine related bugs and 
limitations.

If GAE/J actually provided a better 'just works' solution that they should 
be then this would still be in favor of GAE, but with the countless hours 
you need to spend trying to optimize an app to boot quickly, you could 
easily spend half that time setting up an automated load balancer across 
some cheap hosting providers.

This news that they're not even fixing these issues is the last straw here, 
and I'm going to begin transitioning off GAE/J.


On Thursday, May 16, 2013 1:52:51 AM UTC+2, Jeff Schnitzer wrote:
>
> I attended the "Autoscaling Java" session at Google I/O. In summary, the 
> advice is:
>
>  * Don't use dependency injection.
>  * Don't use AOP.
>  * Hardcode configuration values as much as possible.
>
> In other words, go back to Java circa 2002. There was no discussion of 
> changing routing so that user requests don't see cold starts. I asked about 
> this in person - apparently they're still "talking about it" and nothing 
> has been done about it.
>
> I am sad.
>
> Jeff
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[google-appengine] Re: Bad news for GAE/Java from Google I/O

[Joakim]

It is disheartening to see so little progress being made in this area, not 
to mention the lack of communication as to Google's stance. I love GAE but 
couldn't possibly recommend anyone to run Java here until the instance load 
times or user-facing cold starts are fixed.
I want to say "Just snapshot/save-state the JVM!", but if it was that easy 
Google would obviously have solved this a long time ago. (I hope)

Also, doesn't bytecode weaving solve most of the performance degradation 
caused by AOP?

On Thursday, May 16, 2013 1:52:51 AM UTC+2, Jeff Schnitzer wrote:
>
> I attended the "Autoscaling Java" session at Google I/O. In summary, the 
> advice is:
>
>  * Don't use dependency injection.
>  * Don't use AOP.
>  * Hardcode configuration values as much as possible.
>
> In other words, go back to Java circa 2002. There was no discussion of 
> changing routing so that user requests don't see cold starts. I asked about 
> this in person - apparently they're still "talking about it" and nothing 
> has been done about it.
>
> I am sad.
>
> Jeff
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.