Re: [google-appengine] Re: Where can your run "legacy" Google App Engine (Java) applications?

[Linus Larsen]

Wow, this is really great news I think. 

I was under the impression that Google was phasing out the "legacy" 
platform, so this is not the case?

A big relief for all of us sitting with a bunch of Java 8 services were 
porting to second gen services is not really an option.

/ Linus





tisdag 4 maj 2021 kl. 23:40:39 UTC+2 skrev ludovic.c...@gmail.com:

>
> Hi,
> Ludo (from the Java App Engine team here).
> Good news: as of today, we are providing to select customers a private 
> preview access to a new Java11 GAE runtime with many of the App Engine APIs 
> (com.google.appengine.api.*) support for easy GAE application upgrade from 
> Java8.
> This new Java11 runtime is an extension of the previous Java11 runtime 
>  (which did not 
> support the 'legacy' API), and it is based on Jetty 9.4 Web server and 
> existing well know Java Web Apps, configured with appengine-web.xml (not 
> app.yaml) under a WEB-INF/ web app directory, and same existing tooling 
> (Maven, Gradle).
> It would be great if existing Java8 GAE customers could try this private 
> preview on a new version of their app (and obviously do not use it to 
> server production traffic yet), and give us feedback!
>
> Some of the major bundled GAE services the Private Preview now include:
>
>- - Memcache
>- - Datastore / Objectify with GAE Datastore
>- - URLfetch
>- - Blobstore
>- - Images
>- - Task Queues
>- - Users
>- - Mail
>
>
> If you would like to register for the Private Preview, please fill out 
> the Registration Form 
> 
> .  
> Registering will get you access to the Private Preview documentation, 
> which includes the full API docs for the runtime.
>
> Thanks for trying it now and helping us fine tuning it so we can make it 
> public soon!
> Ludo
>
> On Thursday, April 29, 2021 at 5:56:51 PM UTC-7 Wesley C (Google) wrote:
>
>> At this time, you can run those applications with the "bundled services" 
>> on our Java 8 App Engine runtime 
>> . That's the 
>> latest version w/the bundled services available. The other one is Java 
>> 11 but *without* bundled services 
>> . Also see the 
>> documentation 
>> page highlighting the differences b/w both 1st and 2nd generation runtimes 
>> .
>>
>> While we're committed to supporting legacy runtimes 
>> , 
>> we've also got guides to help developers move off bundled services so 
>> they can upgrade to Java 11 
>> . 
>> We're planning additional resources to help users upgrade their apps, so 
>> stay tuned for those. The first bunch for Python launched recently 
>> ,
>>  
>> and we're planning equivalent resources for Java after all the Python ones 
>> are done.
>>
>> Cheers,
>> --Wesley
>>
>> On Thu, Apr 29, 2021 at 3:21 PM 'cyberquarks' via Google App Engine <
>> google-a...@googlegroups.com> wrote:
>>
>>> Hi, our app is built on Google App Engine (Java) version 1.9.40 where 
>>> all components are "integrated" into the runtime, the Datastore, the Task 
>>> Queue etc. 
>>>
>>> On Friday, April 30, 2021 at 1:53:21 AM UTC+8 Elliott (Cloud Platform 
>>> Support) wrote:
>>>

 Hello,

 I understand that you would like to run a legacy Java App Engine 
 application on the infrastructure that exists currently in Google Cloud 
 Platform without modifying the existing project.

 I was able to find a document 
 , 
 which describes the legacy 8 version of Java still supported. What version 
 of Java are you using? Are you using Google App Standard or Google App 
 Flex?

 I’m thinking that depending on your answer, you may choose to use 
 Containers in Google Cloud Run  to 
 create your environment but you indicated that you do not wish to modify 
 your project.

 So to provide more options, I would ask you to give detail about your 
 project.



 On Thursday, April 29, 2021 at 10:14:18 AM UTC-4 qqua...@protonmail.com 
 wrote:

> Where can you run GAE application built with "integrated" Datastore? 
> Meaning, those application that were build prior to Google platform 
> making 
> the Datastore a separate service from the "core" GAE service. That is 
> without modifying the project.
>
> Can the current Google App Engine 

[google-appengine] Re: How to get InputStream and OutputStream from Cloud Storage on App Engine Java?

[Linus Larsen]

Well, I can't write all code for you. Basically I would not advice you to 
read and write potentially large video data files into memory. You will 
probably
run out of memory. Lets walk thru your code:

see Channels java 
doc: 
https://docs.oracle.com/javase/8/docs/api/java/nio/channels/Channels.html#newInputStream-java.nio.channels.ReadableByteChannel-

// This is the input file
BlobId id = BlobId.of("storageBucket", "videos/video_1.mp4");
byte[] content = storage.readAllBytes(id);
InputStream inputStream = new ByteArrayInputStream(content);

// You can probably use this instead to avoid reading everything in memory
Blob input = storage.get(id);
ReadChannel readChannel = input.reader();
InputStream inputStream = Channels.newInputStream(readChanne);

// Create output, write to a separate file then rename it to the original 
instead of overwriting input with output
BlobId blobId = BlobId.of("storageBucket", 
"videos/video_1_retrancoded.mp4");
BlobInfo blobInfo = BlobInfo.newBuilder(blobId).setContentType(*"video/mp4"*
).build();
Blob output = storage.create(blobInfo);
WriteChannel writeChannel = output.writer();
OutputStream outputStream = Channels.newOutputStream(writeChannel);



FFmpeg.atPath()
.addInput(PipeInput.pumpFrom(inputStream))
.setOverwriteOutput(true) // Dont see why you would need this?
.addArguments("-movflags", "faststart")
.addOutput(PipeOutput.pumpTo(outputStream)) < I need to set this
.setProgressListener(new ProgressListener() {
@Override
public void onProgress(FFmpegProgress progress) {
double percents = 100. * progress.getTimeMillis() / 
duration.get();
System.out.println("Progress: " + percents + "%");
}
})
.execute();

// When done rename output file to input file on google storage (or maybe 
it's a move you need to do.)

I just provided you with some pseudo code, you need to do the 
implementation, error handling etc. Also there are a bunch of
parameters that you can set on the readable / writable channels, you'll 
figure it out.

/ Linus








On Sunday, April 25, 2021 at 3:09:38 PM UTC+2 Richard Arnold wrote:

> Thanks for the reply. So is this going to overwrite the file specified? Or 
> is it going to create a new file in memory that I then have to save to 
> cloud storage myself? Could you show me how the code you wrote fits in with 
> the code I have?
>
> On Saturday, April 24, 2021 at 10:48:28 AM UTC-7 linus@epspot.com 
> wrote:
>
>> How about
>>
>> // Create your resource
>> BlobId blobId = BlobId.of(YOUR_BUCKET, *YOUR_FILENAME*);
>> BlobInfo blobInfo = BlobInfo.newBuilder(blobId).setContentType(
>> *"video/mp4"*).build();
>> Blob blob = getStorage().create(blobInfo);
>>
>> WriteChannel writeChannel = blob.writer();
>> // Then use writeChannel to write your bytes, it extends 
>> WritableByteChannel which has
>>
>> public int write(ByteBuffer src)
>>
>> I.e you have to create an OutputStream that writes to a ByteBuffer first.
>>
>> https://gist.github.com/hoijui/7fe8a6d31b20ae7af945
>>
>> Sort of.
>>
>> / Linus
>>
>>
>>
>> On Saturday, April 24, 2021 at 3:27:56 PM UTC+2 Richard Arnold wrote:
>>
>>> I am attempting to use FFMPEG on Google App Engine (Java) to re-encode 
>>> some video files I have that are sitting in Google Cloud Storage. I found a 
>>> Java wrapper around ffmpeg that I would like to use here: 
>>> https://github.com/kokorin/Jaffree. 
>>>
>>> My issue is that this library requires an InputStream and OutputStream. 
>>> I am trying to specify the InputStream as a file in Google Cloud Storage 
>>> and the OutputStream as a new file. 
>>>
>>> I think I have done specifying the InputStream correctly, but I do not 
>>> know what to do about the OutputStream.
>>>
>>> How can I specify the OutputStream to be a new file?
>>>
>>> Or if possible, can I just overwrite the file in Google Cloud Storage?
>>>
>>> Here is my Java code in Google App Engine so far:
>>>
>>> Storage storage = StorageOptions.getDefaultInstance().getService();
>>>
>>> // This is the input file
>>> BlobId id = BlobId.of("storageBucket", "videos/video_1.mp4");
>>> byte[] content = storage.readAllBytes(id);
>>> InputStream inputStream = new ByteArrayInputStream(content);
>>>
>>> FFmpeg.atPath()
>>> .addInput(PipeInput.pumpFrom(inputStream))
>>> .setOverwriteOutput(true)
>>> .addArguments("-movflags", "faststart")
>>> .addOutput(PipeOutput.pumpTo(outputStream)) < I need to set this
>>> .setProgressListener(new ProgressListener() {
>>> @Override
>>> public void onProgress(FFmpegProgress progress) {
>>> double percents = 100. * progress.getTimeMillis() / 
>>> duration.get();
>>> System.out.println("Progress: " + percents + "%");
>>> }
>>> })
>>> .execute();
>>>
>>

-- 
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 

[google-appengine] Re: How to get InputStream and OutputStream from Cloud Storage on App Engine Java?

[Linus Larsen]

How about

// Create your resource
BlobId blobId = BlobId.of(YOUR_BUCKET, *YOUR_FILENAME*);
BlobInfo blobInfo = BlobInfo.newBuilder(blobId).setContentType(*"video/mp4"*
).build();
Blob blob = getStorage().create(blobInfo);

WriteChannel writeChannel = blob.writer();
// Then use writeChannel to write your bytes, it extends 
WritableByteChannel which has

public int write(ByteBuffer src)

I.e you have to create an OutputStream that writes to a ByteBuffer first.

https://gist.github.com/hoijui/7fe8a6d31b20ae7af945

Sort of.

/ Linus



On Saturday, April 24, 2021 at 3:27:56 PM UTC+2 Richard Arnold wrote:

> I am attempting to use FFMPEG on Google App Engine (Java) to re-encode 
> some video files I have that are sitting in Google Cloud Storage. I found a 
> Java wrapper around ffmpeg that I would like to use here: 
> https://github.com/kokorin/Jaffree. 
>
> My issue is that this library requires an InputStream and OutputStream. I 
> am trying to specify the InputStream as a file in Google Cloud Storage and 
> the OutputStream as a new file. 
>
> I think I have done specifying the InputStream correctly, but I do not 
> know what to do about the OutputStream.
>
> How can I specify the OutputStream to be a new file?
>
> Or if possible, can I just overwrite the file in Google Cloud Storage?
>
> Here is my Java code in Google App Engine so far:
>
> Storage storage = StorageOptions.getDefaultInstance().getService();
>
> // This is the input file
> BlobId id = BlobId.of("storageBucket", "videos/video_1.mp4");
> byte[] content = storage.readAllBytes(id);
> InputStream inputStream = new ByteArrayInputStream(content);
>
> FFmpeg.atPath()
> .addInput(PipeInput.pumpFrom(inputStream))
> .setOverwriteOutput(true)
> .addArguments("-movflags", "faststart")
> .addOutput(PipeOutput.pumpTo(outputStream)) < I need to set this
> .setProgressListener(new ProgressListener() {
> @Override
> public void onProgress(FFmpegProgress progress) {
> double percents = 100. * progress.getTimeMillis() / 
> duration.get();
> System.out.println("Progress: " + percents + "%");
> }
> })
> .execute();
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/854de782-6647-43ad-b71b-7cf2cc17e72bn%40googlegroups.com.

[google-appengine] TaskQueues vs Cloud Tasks std env

[Linus Larsen]

For appengine std env the TaskQueue page in console has been removed, 
instead you get redirected to the Cloud Task page. However before I can 
visit that page I need to enable the Cloud Task api for my project.

AFAIK we are not yet forced to swap TaskQueues to CloudTasks, in fact 
CloudTasks still lacks some features present in TaskQueue (transactional 
tasks for example), also pricing would be an argument not to use CloudTask.

Anyhow, I don't understand why I need to enable an API that I'm not even 
sure to use just to be able to run some of my TaskQueues manually in the 
web console?

Cron page has also been moved to CloudScheduler page, however there I 
didn't need to enable CloudScheduler api to be able to run crontabs in web 
console.

/ Linus

   

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/1de9f1cc-5b1c-4bf9-bffb-44e3463ea5abn%40googlegroups.com.

Re: [google-appengine] Question about dispatch & backends

[Linus Larsen]

I think I have seen some documentation way back that it was not possible to
serve user facing requests from a B instance, instead you
were supposed to dispatch the request to a TaskQueue and use some sort of
client polling in order to get notified when the work on B
instance was completed.

Cannot find it anymore, the documentation has changed so much you don't
really know what's the truth anymore.

/ Linus

On Mon, Dec 14, 2020 at 3:13 PM Joshua Smith 
wrote:

> I'm thinking you didn't read my initial message carefully, so let me try
> again.
>
> Yes, I'm using the legacy runtime with the 1 minute limit on frontends.
>
> Yes, I'm using the B8 with basic scaling for my API calls, which should
> not have that limit.
>
> Yes, I'm using URL routing via dispatch.yaml, and have confirmed the B8
> instance is handling the request by checking the logs.
>
> *The request is nonetheless failing because it's taking more than one
> minute. *
>
> That should not be happening, according to the documentation. Unless
> there's *another* 1 minute limit somewhere else that I'm not aware of.
>
> -Joshua
>
> On Dec 13, 2020, at 8:58 PM, 'Manpreet Sidhu (Google Cloud Support)' via
> Google App Engine  wrote:
>
> Even though your frontend uses automatic scaling, the work is being done
> on the B8 instance that is responsible for running your API service.
>
> Based on the screenshot that you attached, the B8 instance has to return
> in 24 hours. This is due to the fact that the B8 instance is only capable
> of Manual and Basic scaling[0].
>
> Can it be safe to assume that you are using a Legacy Runtime as that is
> where the limit of 1 minute is enforced. As an alternative, you can try
> routing with URLs[1] or look into implementing the use of Task Queues as
> that has a timeout of 10 minutes.
>
> [0]: https://cloud.google.com/appengine/docs/standard#instance_classes
> [1]:
> https://cloud.google.com/appengine/docs/standard/python/how-requests-are-routed#urls
> On Saturday, December 12, 2020 at 10:11:28 AM UTC-5 Joshua Smith wrote:
>
>>
>> https://cloud.google.com/appengine/docs/standard/python/how-instances-are-managed#timeout
>>
>> My frontend service uses automatic scaling, so it has a 1 minute limit to
>> respond. But my API service is a B8 with this:
>>
>>
>> which means that it should not be subjected to that limit. Yet when I
>> send requests to it via the dispatch, it seems to be enforcing at 1 minute
>> limit regardless.
>>
>>
>>
>> On Dec 11, 2020, at 4:44 PM, 'Elliott (Cloud Platform Support)' via
>> Google App Engine  wrote:
>>
>> Hello Joshua,
>>
>> I understand that your program uses APIs that need more than 60 seconds
>> to complete but even though you are using B8 instances in App Engine, your
>> program times out past the 60 seconds. I’m assuming you are using App
>> Engine Standard.
>>
>> To find supporting documentation for you, can you tell me more about the
>> "gotta get it done in 60 seconds" rule? Can you please give examples of
>> this?
>>
>>
>> On Friday, December 11, 2020 at 12:01:48 PM UTC-5 Joshua Smith wrote:
>>
>>> I have an app with a frontend UX that queries some backend APIs for
>>> information. Some of these APIs need more than 60 seconds to complete their
>>> work.
>>>
>>> I *thought* I could solve this by doing the following:
>>>
>>> 1. Run the code on a B8 instance with a different service name
>>> 2. Set up dispatch.yaml to direct the incoming API requests to that
>>> service:
>>>
>>> dispatch:
>>>
>>> - url: "*/api/*"
>>>   service: reporting
>>>
>>> - url: "*/*"
>>>   service: default
>>>
>>> The dispatching is working correctly. I see this in my logs for an /api
>>> hit:
>>>
>>> However, it's timing out:
>>>
>>>
>>> My understanding was that a B8 instance didn't have the "gotta get it
>>> done in 60 seconds" rule that frontend instance types did.
>>>
>>> What am I missing?
>>>
>>> -Joshua
>>>
>>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-appengine/7209920b-7b59-4dd4-84a6-e722e7df462bn%40googlegroups.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/6d4408fa-0030-42c4-990b-14223e773c27n%40googlegroups.com
> 
> .
>
>
> --
> You 

Re: [google-appengine] Re: Appengine Dashboard broken?

[Linus Larsen]

Works again for me now.magic.

Den tor 8 okt. 2020 10:19troberti  skrev:

> We have the same issue, for all our Appengine projects.
>
> On Wednesday, October 7, 2020 at 11:02:47 PM UTC+2 linus@gmail.com
> wrote:
>
>> In cloud console, Appengine Dasboard for a few days it says:
>>
>> Current load
>>
>> This app has not received any requests in the last 24 hours.
>>
>> This is obviously wrong since I have loads of requests in the logs and I
>> get billed for them as well.
>>
>> This used to show the top 10 or 20 requested urls, is it broken?
>>
>> The Dashboard in Home works as expected.
>>
>>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/google-appengine/81428dd7-9003-4dd7-98de-2a52042cdd9en%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/CAKKTta0rKCxqiu60GBv2AbAqvT5OBCri7S2zcSm-ZN%2Bv%3DqS5WQ%40mail.gmail.com.

[google-appengine] Appengine Dashboard broken?

[Linus Larsen]

In cloud console, Appengine Dasboard for a few days it says:

Current load

This app has not received any requests in the last 24 hours.

This is obviously wrong since I have loads of requests in the logs and I 
get billed for them as well.

This used to show the top 10 or 20 requested urls, is it broken?

The Dashboard in Home works as expected.


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/6690c30b-1e76-4993-8490-ccfcfee6a975n%40googlegroups.com.

Re: [google-appengine] Spending LImits Going Away :(

[Linus Larsen]

True story

One day in December some year ago customers called in complaining about our 
service wasn't responding. A quick look in the console we could see that we 
had gone over our spending limit. Why? Digging deeper we could see that we 
had 1000+ instances running (standard, java, autoscale, and we hadn't 
specified maximum instances). After some trouble shooting and help with 
Google support we found the reason. It turned out that we had hit the roof 
of a socket _connect quota, for each request we get to our service we send 
a pub/sub message, in the pub/sub library we used it was not possible to 
batch send messages so each message sent was literally a socket_connect.

After hitting the socket _connect quota limit the calls to pub/sub where 
timing out, and the timeout value was too high (we were using the library 
default value), so the autoscaler scheduler started a new instance in a 
forever loop.

When this happen everything froze and we couldn't kill instances more 
rapidly than the scheduler spun up a new one, kind of a moment 22 situation.

In order to get it fixed we had to ask Google to bump the socket_connect 
quota, then we had to rise our spending limit to get everything working 
again. 

In a situation like this the only thing that wasn't getting us bankrupt was 
the spending limit,  the irony here the suggestion about using "Budget 
Alerts, Pub/Sub, and Cloud Functions when your costs exceed the threshold" 
won't work if your not allowed to call pub/sub because of a stupid 
socket_connect quota.

We probably stumbled on an edge case with a lot of combinations of usage of 
old libraries / apis, and hidden quota limits (I can't even find the 
socket_connect quota anymore on the quota pages in console), however my 
point here is spending limit is the last outpost we have to actually to set 
a cost limit and it's sad seeing it going away just as the other 
dismounting of what to be a great service.
 


 

onsdag 26 augusti 2020 kl. 22:47:44 UTC+2 skrev yananc:

> Hello Joshua,
>
> The budget alert will be triggered once your costs rise above the 
> threshold you specify. However, as Alexis has explained, there are various 
> factors that might affect ‘how quickly’ you will receive the alert.
>
> Same as the email you shared, the documentation [1] provides details on 
> how to manage App Engine costs. Specifically, besides mechanisms such as 
> setting the max number of instances, Budget Alerts, Pub/Sub, and Cloud 
> Functions could be used to automatically disable your app when your costs 
> exceed the threshold you specify. The documentation also provides steps on 
> how to implement it with sample codes.
>
> Back to the issue of ‘Cloud Datastore Read Operations’ being too high, a 
> possible solution is to leverage cache mechanism to avoid excessive 
> operations. You may find more information from the topic [2].
>
> Hope it helps.
>
> [1]: https://cloud.google.com/appengine/docs/managing-costs
>
> [2]: 
> https://stackoverflow.com/questions/12939376/google-app-engine-too-many-datastore-read-operations
>
> On Tuesday, August 25, 2020 at 6:51:49 PM UTC-4 Luca de Alfaro wrote:
>
>> Yes, at least, we can hard limit the number of active instances: see 
>> https://cloud.google.com/appengine/docs/standard/python3/config/appref
>> So if every active instance has a limited rate of use of backend services 
>> (like datastore), and there are no services accessible except via an 
>> appengine instance (e.g., no GCS direct bandwidth), in practice we can put 
>> a bound using that. 
>>
>> Luca
>>
>> On Tue, Aug 25, 2020 at 3:45 PM Luca de Alfaro  wrote:
>>
>>> I concur with the worry.  Is there any _technical_ reason why it is a 
>>> good idea to do away with a spending limit?  Can we get an instance limit 
>>> instead? 
>>> This is suddenly making standard non-scalable systems on AWS look better 
>>> than appengine! 
>>>
>>> On Tue, Aug 25, 2020 at 9:03 AM Joshua Smith  
>>> wrote:
>>>
 Once again last night, my wallet was saved when a runaway bot chewed up 
 my site’s whole daily spending limit. I got an email from a user, set up a 
 firewall rule, and goosed my budget to get things going again.

 I’m *very* concerned about Google’s decision to remove this feature. 
 Offering a cloud service that bills by usage without having a way to limit 
 the spend shifts an unreasonable amount of risk onto the subscriber.

 I’ve set up budget alerts, as suggested, but I’m concerned that:

 - What if my bill shoots up really fast? How quickly is this alert 
 going to go out?

 - What if I am away from the computer (remember when we used to be able 
 to leave our houses? good times… good times…)?

 I run this particular site as a not-for-profit social good. (It’s a 
 site that small town governments use to post their meetings.) I make 
 *no* money on it.

 I’d be perfectly happy to handle this with self-set quotas on something 

[google-appengine] Re: appcfg shutdown: earlier than scheduled?

[Linus Larsen]

I just tried updating another service (I'm using Java) which now fails:

98% Application deployment failed. Message: Deployments using appcfg are no 
longer supported. See https://cloud.google.com/appengine/docs/deprecations

But I can update other services, seriously Google what's going on? 

Deprecated in July 30, then it's extended to August 30, but it seems you 
have decided to cut the support for appcfg now? 

It's still at least 2 month away, come on!. 

/ Linus

 

On Tuesday, May 19, 2020 at 4:47:15 PM UTC+2, PPG Apps wrote:
>
> I am using appcfg and have had no issues 
>
> App Engine SDK 
> release: "1.9.87" 
> timestamp: 1571856179 
> api_versions: ['1'] 
> supported_api_versions: 
> python: 
> api_versions: ['1'] 
> python27: 
> api_versions: ['1'] 
> go: 
> api_versions: ['go1', 'go1.9'] 
> java7: 
> api_versions: ['1.0'] 
> go111: 
> api_versions: [null] 
> Python 2.5.2 
> wxPython 2.8.8.1 (msw-unicode) 
>
>
> On Thursday, May 14, 2020 at 4:45:56 AM UTC-4, OferR wrote:
>>
>>
>> Thanks Linus,
>>
>> 1. I didn't receive this email. I get other mail from the app engine 
>> people, but not this one.
>>
>> 2. Google? Why am I getting this error now?
>>
>> 3. Can anybody else confirm that they can/cannot deploy using appcfg?
>>
>> Thanks
>>
>>
>>
>> On Thursday, May 14, 2020 at 7:29:49 PM UTC+12, Linus Larsen wrote:
>>>
>>> I don't know about you guys, but I got this in the mail:
>>>
>>> The legacy standalone App Engine SDK (appcfg) was deprecated as of *July 
>>> 30, 2019*, in favor of the GA Cloud SDK 
>>> <https://www.google.com/appserve/mkt/p/AM7kBiUYJrHta2waHnldNTcQ5ec6046vFvMmt8TRDBvxD7fkID713CKb9cOc-AI46tCJQDF5RFyv_zlz4Sh5vfOdM7c>.
>>>  
>>> You must migrate your projects off the legacy standalone SDK (appcfg) by 
>>> August 30, 2020. The migration deadline was extended from July 30, 2020, to 
>>> avoid service disruption.
>>>
>>> The deadline has been extended, why you get this error now is a mystery 
>>> to me.
>>>
>>> / Linus
>>>
>>> Den torsdag 14 maj 2020 kl. 05:19:39 UTC+2 skrev OferR:
>>>>
>>>>
>>>> Thanks for your comment.
>>>>
>>>> The document that you point to and other documents clearly suggest that 
>>>> support for appcfg will be removed on July 30, 2020, which implies that it 
>>>> should still be supported now.
>>>>
>>>> However, this does not seem to be the case as evident when trying to 
>>>> deploy a new version to GAE using appcfg now.
>>>>
>>>> Can you please comment on this point.
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> On Thursday, May 14, 2020 at 2:56:38 PM UTC+12, Aref Amiri (Cloud 
>>>> Platform Support) wrote:
>>>>>
>>>>> Based on this public documentation 
>>>>> <https://cloud.google.com/appengine/docs/standard/java/sdk-gcloud-migration>,
>>>>>  
>>>>> the appcfg tool which is included in Stand alone App Engine SDK, is 
>>>>> depricated as of July 30, 2019 and is replaced by Cloud SDK 
>>>>> <https://cloud.google.com/sdk/docs>. It will become unavailable for 
>>>>> download on July 30, 2020.
>>>>>
>>>>> You may want to follow this documentation 
>>>>> <https://cloud.google.com/appengine/docs/standard/java/tools/migrating-from-appcfg-to-gcloud>
>>>>>  
>>>>> as it lists the equivalanet commands to some frequently used AppCfg 
>>>>> commands.
>>>>>
>>>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/3b1c9155-5561-489a-aa42-d4a3cb6608f0%40googlegroups.com.

[google-appengine] Re: appcfg shutdown: earlier than scheduled?

[Linus Larsen]

I don't know about you guys, but I got this in the mail:

The legacy standalone App Engine SDK (appcfg) was deprecated as of *July 
30, 2019*, in favor of the GA Cloud SDK 
.
 
You must migrate your projects off the legacy standalone SDK (appcfg) by 
August 30, 2020. The migration deadline was extended from July 30, 2020, to 
avoid service disruption.

The deadline has been extended, why you get this error now is a mystery to 
me.

/ Linus

Den torsdag 14 maj 2020 kl. 05:19:39 UTC+2 skrev OferR:
>
>
> Thanks for your comment.
>
> The document that you point to and other documents clearly suggest that 
> support for appcfg will be removed on July 30, 2020, which implies that it 
> should still be supported now.
>
> However, this does not seem to be the case as evident when trying to 
> deploy a new version to GAE using appcfg now.
>
> Can you please comment on this point.
>
> Thanks
>
>
>
> On Thursday, May 14, 2020 at 2:56:38 PM UTC+12, Aref Amiri (Cloud Platform 
> Support) wrote:
>>
>> Based on this public documentation 
>> ,
>>  
>> the appcfg tool which is included in Stand alone App Engine SDK, is 
>> depricated as of July 30, 2019 and is replaced by Cloud SDK 
>> . It will become unavailable for 
>> download on July 30, 2020.
>>
>> You may want to follow this documentation 
>> 
>>  
>> as it lists the equivalanet commands to some frequently used AppCfg 
>> commands.
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/18a150c2-7239-468b-8553-7a14f26c695c%40googlegroups.com.

[google-appengine] Re: How to mapping default services to other services ?

[Linus Larsen]

In java using std env you need to change the service (module) name to 
"default" in appengine-web.xml, ex:

http://appengine.google.com/ns/1.0;>
your app
default

And of course change the name to another name on your current default module.


Should be simiular in other languages as well, for 2:nd gen or flex env I don't 
know, probably you need

to change something in a yaml file or whatever popular these days. 






On Friday, May 8, 2020 at 3:04:31 PM UTC+2, Kanti Vekariya wrote:
>
>
> I want to replace default service to the first service how to do?
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/b49036f1-c425-4da2-8b78-4f2006d1347c%40googlegroups.com.

[google-appengine] Daily spending limit deprecated

[Linus Larsen]

According to 
https://cloud.google.com/appengine/docs/standard/java/release-notes the 
possibility to alter the daily spending limit has been deprecated but 
existing on will still be valid.

What happens if your service grows and the current spending limit is too 
low? It has happen to us on several occasions.

There must be a way of removing the daily spending limit if it cannot be 
changed, but I cannot find any documentation on how to do it.
 



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/87af2acc-ee1d-48d1-8b48-1698b50d8b14%40googlegroups.com.

Re: [google-appengine] gcloud app deploy is failing

[Linus Larsen]

Totally agree, for small companies or startups with limited resources we 
only want our services to run with minimal effort.



Den fredag 13 december 2019 kl. 15:02:52 UTC+1 skrev Joshua Smith:
>
> Confirmed that my deploy is now working. A little heads-up would be nice 
> before you take another shot at that experiment. I don’t remember opting-in 
> to being a guinea pig.
>
> And yes, I assumed it had something to do with that cloud build stuff. I 
> guess I understand why you are doing it, but this transformation of Google 
> App Engine from a PaaS offering to an IaaS offering is horrible. It used to 
> be we had a simple Launcher app that made development and deployment of an 
> app super easy. Now I’m dealing with a half dozen “services,” trying to 
> ensure all the service accounts have the right permissions, and having to 
> learn entire stacks to do something that used to be an API call.
>
> There is a real market need for a PaaS offering, which is what GAE used to 
> be. Now it’s gotten so complicated that I might as well be spinning up a 
> container in EC2. You have completely destroyed your competitive advantage, 
> and there is vacuum that someone (beanstalk maybe?) is going to step into.
>
> It reminds me of the the way Microsoft Access solved a real problem for 
> millions of users, yet Microsoft repeatedly tried to kill the thing to drag 
> people to SQL Server, which was such overkill for 99% of those users.
>
> Once again, Google is listening to their engineers instead of their 
> customers. It’s a shame. GAE was great. This gcloud mess is the opposite of 
> great.
>
> -Joshua
>
> On Dec 13, 2019, at 8:46 AM, 'joshuamo' via Google App Engine <
> google-a...@googlegroups.com > wrote:
>
> App Engine will be moving towards using Cloud Build for the Standard 
> environment[1], matching the other Serverless offerings.  Good catch 
> noticing the Cloud Build aspect here.  We were rolling this out at a low 
> percentage and this is what seems to have triggered the issue you've 
> experienced.
>
> For now, we've rolled back the experiment, so you should be able to deploy 
> again without issue.
>
> [1] https://cloud.google.com/appengine/docs/standard/payment-instrument
>
> On Thursday, December 12, 2019 at 7:54:37 AM UTC-6, Joshua Smith wrote:
>>
>> So this problem persists, which I guess means it’s not an outage, but 
>> rather something got messed up by google on my account.
>>
>> Please advise on how I can get this issue rectified. To summarize, I’m 
>> running *gcloud app deploy* and it is reporting a 404 error trying to 
>> read the manifest of the cloud bucket where it is staging things.
>>
>> I looked at the issue tracker, but that doesn’t appear to be geared 
>> toward production problems any more.
>>
>> Opening a ticket appears to have a $100/month price tag attached to it, 
>> which seems onerous considering how much my company is paying google every 
>> month for these services, and considering *google* broke my account.
>>
>> What’s the right course of action here?
>>
>> -Joshua
>>
>> On Dec 11, 2019, at 4:28 PM, Joshua Smith > > wrote:
>>
>> Digging into the GAE “Activity” logs, I see some new stuff about google 
>> cloud builder that I haven’t seen before.
>>
>> Perhaps something went sideways in the transition to that new technology?
>>
>> All these extra service accounts and whatnot that got created and show up 
>> in IAM are ridiculously complicated. I wouldn’t know where to begin 
>> diagnosing that.
>>
>> What’s the right way to get someone from google to figure out how they 
>> messed up my account?
>>
>> -Joshua
>>
>> On Dec 11, 2019, at 3:33 PM, Joshua Smith > > wrote:
>>
>> I’m trying to update a website deployed in appengine. I’ve made sure my 
>> cloud SDK is all up to date. It’s a big site, with about 8000 files. I’ve 
>> been using the same deploy command in this same folder for years. I’m 
>> getting this cryptic error:
>>
>> Updating service [default]...failed.  
>>  
>> *ERROR:* (gcloud.app.deploy) Error Response: [5] failed to fetch 
>> metadata from GCR, with reason: generic::not_found: failed to fetch 
>> metadata from GCR for image 
>> us.gcr.io/kaoncom-hr/app-engine-tmp/app/ttl-2h:8927ab89-5aed-4a70-9969-9ed1927844ec,
>>  
>> with reason: generic::not_found: fetchImageMetadata failed for image 
>> us.gcr.io/kaoncom-hr/app-engine-tmp/app/ttl-2h:8927ab89-5aed-4a70-9969-9ed1927844ec,
>>  
>> reason: generic::not_found: failed to fetch manifest from GCR (via 
>> gcr.FetchManifest): generic::not_found: error fetching 
>> "kaoncom-hr/app-engine-tmp/app/ttl-2h/manifests/8927ab89-5aed-4a70-9969-9ed1927844ec"
>>  
>> : generic::not_found: got HTTP/404 response, wanted HTTP/200
>>
>> The guid-looking thing changes every deploy. kaoncom-hr is the name of 
>> the app.
>>
>> I checked the dashboards and google is not reporting an outages.
>>
>> Any ideas?
>>
>> -Joshua
>>
>>
>>
>>
> -- 
> You received this message 

[google-appengine] Re: GAE: how to migrate appengine.api for Java8 to google cloud datastore for Java11

[Linus Larsen]

Hi

The gcloud sdk has different package names for the datastore classes, ex: 
com.google.cloud.datastore.Cursor.
I think you'll need to import the cloud datastore classes / client api. 
Check the bookshelf example app pom / parent pom.




Den onsdag 27 november 2019 kl. 01:09:30 UTC+1 skrev Han Ju Kim:
>
> Hi Elliott,
>
> I appreciate your guide, however this is is not clearly described even 
> stackoverflow [appengine] quite well. My solution run quite well in Java8, 
> however I love to migrate that to latest on for Java11 and google cloud. 
> It's a library provided from Google Cloud without any kind description on 
> migration. When I deployed Java11, it generated lots of error like above. 
> The google document for Java 11 and Datastore just say that it will be 
> automatically migrated internally. However, nothing can be found anywhere.
> There may be many developer experiencing same stuff. Is it too early to 
> consider to migrate Java11? 
>
>
>
> On Wednesday, 27 November 2019 12:26:54 UTC+13, Elliott (Cloud Platform 
> Support) wrote:
>>
>> Hello Han,
>>
>> Please note that Google Groups are reserved for general Google Cloud 
>> Platform and product discussions and not for technical issues, which is why 
>> I suggest moving the troubleshooting to Stackoverflow 
>> , where you may receive advice from our 
>> programming community.
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/6443b31a-2c4d-42cb-baa4-78332a0da321%40googlegroups.com.

[google-appengine] Re: How to connect Firebase Database from GOogle App engine

[Linus Larsen]

Ok, I think I got it now. With an app engine project using Cloud Datastore 
there is no way to create a firestore database, e.g the new firebase 
database. However
it's possible to create the old firebase database (aka real time database). 
Very confusing.

 

Den måndag 14 januari 2019 kl. 15:44:18 UTC+1 skrev Linus Larsen:
>
> So basically what you are telling me is there is no way for me to get FCM 
> messaging working with my existing app engine project that I have been 
> running
> for more or less 4 years now?
>
> I tried the Firebase Admin SDK for java, but I cannot initialise the 
> library since I need a database name, I cannot create a Firebase database 
> since I use Cloud Datastore.
>
> Creating a new Project, migrate all my services, payment infoetc, is a 
> bit overkill just to get push notifications to my mobile clients to 
> continue work as expected.
>
>
>
>
>
> Den måndag 14 januari 2019 kl. 15:20:00 UTC+1 skrev George (Cloud Platform 
> Support):
>>
>> Hi Linus, 
>>
>> You are indeed missing the fact that one can't as yet use Datastore and 
>> Firestore in the same project, one needs to choose at the start which 
>> functionality and features suit one's project better. The way you migrate 
>> from Cloud Messaging to FCM seems a separate issue. You may find related 
>> details, and an FAQ list on the "GCM and FCM Frequently Asked Questions" 
>> documentation page <https://developers.google.com/cloud-messaging/faq>. 
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/48b349ab-f078-481d-b189-6fd5b7b1982f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: How to connect Firebase Database from GOogle App engine

[Linus Larsen]

So basically what you are telling me is there is no way for me to get FCM 
messaging working with my existing app engine project that I have been 
running
for more or less 4 years now?

I tried the Firebase Admin SDK for java, but I cannot initialise the 
library since I need a database name, I cannot create a Firebase database 
since I use Cloud Datastore.

Creating a new Project, migrate all my services, payment infoetc, is a 
bit overkill just to get push notifications to my mobile clients to 
continue work as expected.





Den måndag 14 januari 2019 kl. 15:20:00 UTC+1 skrev George (Cloud Platform 
Support):
>
> Hi Linus, 
>
> You are indeed missing the fact that one can't as yet use Datastore and 
> Firestore in the same project, one needs to choose at the start which 
> functionality and features suit one's project better. The way you migrate 
> from Cloud Messaging to FCM seems a separate issue. You may find related 
> details, and an FAQ list on the "GCM and FCM Frequently Asked Questions" 
> documentation page . 
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/73a3574a-ff7b-4965-81b2-a3be8387d5ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: How to connect Firebase Database from GOogle App engine

[Linus Larsen]

It  was pretty  straight forward for me until I had to create the actual 
database where there was an error saying in order to create a new database I 
have to create a new project. Probably because my existing appengine standard 
project already using cloud datastore. I guess thats fine, however I need to 
replace my existing GCM integration with FCM because of the deprecation of GCM 
in April. Do I really need a new project for that? I dont need a new database 
(or project), I just need messaging to work after 11th of April. Am I missing 
something?

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/e6259280-08b7-456b-b0d2-c98801468bef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Appengine standard java shutdown callback

[Linus Larsen]

FK, I filed a feature 
request, https://issuetracker.google.com/issues/114794562


Den tisdag 11 september 2018 kl. 15:07:53 UTC+2 skrev Linus Larsen:
>
> I'm using pubsub with batching and I wan't to be able to drain the queue 
> on any pontential messages before the instance shutdown.
> Piece of cake I thougt, just call shutdown() in 
> LifecycleManager.shutdown(), end of story. However I'm running my instances 
> with
> autoscaling and there seems to be no way to get a proper callback when the 
> servlet container is shutting down.
>
>
>- LifecycleManager listener only works with manual and basic instance 
>classes // as per documentation 
>- ServletContextListener.contextDestroy is never invoked by appengine 
>// as per documentation
>- "_ah/stop" is never called on auto scaled instances // as per 
>documentation
>
>
> Surely there must be a way of getting notified when an instance is about 
> to shut down?
>
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/6091b397-e54f-445e-8af2-ae31accb9acb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Appengine standard java shutdown callback

[Linus Larsen]

I'm using pubsub with batching and I wan't to be able to drain the queue on 
any pontential messages before the instance shutdown.
Piece of cake I thougt, just call shutdown() in 
LifecycleManager.shutdown(), end of story. However I'm running my instances 
with
autoscaling and there seems to be no way to get a proper callback when the 
servlet container is shutting down.


   - LifecycleManager listener only works with manual and basic instance 
   classes // as per documentation 
   - ServletContextListener.contextDestroy is never invoked by appengine // 
   as per documentation
   - "_ah/stop" is never called on auto scaled instances // as per 
   documentation


Surely there must be a way of getting notified when an instance is about to 
shut down?


-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/912515bf-7f0d-4989-ad98-3a7d83c6d41f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Having issues deploying to app engine after my java 7 to 8 upgrade

[Linus Larsen]

Do you have the same version number on the app running as the one you have 
locally, if so one workaround can be to set another version number
on your local app. Run update, then enable the new version in the console 
UI. However, if everything works ok, remember to delete the instances of the
old version manually otherwise they will live and maybe affect your bill.


Den tisdag 11 september 2018 kl. 04:16:33 UTC+2 skrev LeadWay Global:
>
> I am running a multi-module java web application application.
>
> Runs great under java7.  However, now that we are required to upgrade to 
> java8 I updated my maven files and also the web files to use the java8 run 
> time. 
> All the steps when I exectute  *mvn appengine:update,* seems to run fine 
> and the deploy seems to run fine however the old app (java 7) does not seem 
> to shut down or the new ap does not start up. 
>
> This is the logs I get: 
>
> Beginning interaction for module default...
>
> 0% Created staging directory at: 
> '/var/folders/5s/63hgymfs7js4tlx1zrpt1214gn/T/appcfg4670965857950299255.tmp'
>
> 5% Scanning for jsp files.
>
> 8% Generated git repository information file.
>
> 20% Scanning files on local disk.
>
> 25% Scanned 250 files.
>
> 28% Initiating update.
>
> 31% Cloning 3 static files.
>
> 33% Cloning 362 application files.
>
> 40% Uploading 0 files.
>
> 52% Initializing precompilation...
>
> 90% Deploying new version.
>
> 95% Will check again in 1 seconds.
>
> 98% Will check again in 2 seconds.
>
> 99% Will check again in 4 seconds.
>
> 99% Will check again in 8 seconds.
>
> 99% Will check again in 16 seconds.
>
> 99% Will check again in 32 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 1 seconds.
>
> 99% Will check again in 2 seconds.
>
> 99% Will check again in 4 seconds.
>
> 99% Will check again in 8 seconds.
>
> 99% Will check again in 16 seconds.
>
> 99% Will check again in 32 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> 99% Will check again in 60 seconds.
>
> Sep 09, 2018 7:37:06 PM com.google.appengine.tools.admin.AppVersionUpload 
> commit
>
> SEVERE: Version still not serving, aborting.
>
> 99% Rolling back the update.
>
>
> com.google.appengine.tools.admin.RemoteIOException: Version not ready.
>
> Unable to update app: Version not ready.
>
> Please see the logs 
> [/var/folders/5s/63hgymfs7js4tlx1zrpt1214gn/T/appcfg5707627753653038815.log]
>  
> for further information.
>
> It fails during the first module 'default' deploy.
>
> On a side note where can I see what's inside that logs file?
>
> On local, the java8 app runs fine.
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/614fa253-6575-4d6b-8900-20bf11f8e1d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Old versions still running (flexible environment)

[Linus Larsen]

Yep, this is really easy do reproduce in the standard env as well. Just 
deploy a new version, migrate traffic to the new version. The
old version still keeps instances running (in my case both python and java).



Den måndag 26 februari 2018 kl. 15:49:58 UTC+1 skrev Hendrik Kleinwächter:
>
> We are seeing this as well. Using ruby and the flexible environment. Any 
> idea what this could be? Are the stale instances still producing costs?
>
> On Thursday, March 16, 2017 at 8:10:07 PM UTC+1, Alan deLespinasse wrote:
>>
>> I'm not sure if this is a bug or expected behavior. It's not what I 
>> expected, but I'm still somewhat confused by the Cloud Console.
>>
>> I have several services for which I noticed there were still some old 
>> versions running, although the old versions were serving 0% of traffic. 
>> Example:
>>
>>
>> 
>>
>> The two selected versions were made obsolete by the top version. Normally 
>> when I deploy a new version, the previously running version is shut down. 
>> In these cases, I think a new version never succeeded in starting up, 
>> because I had a bug that would simply crash every time. So here's what 
>> apparently happens:
>>
>>1. Version A is running
>>2. I try to deploy version B; it repeatedly fails to start up. My 
>>"gcloud app deploy" command eventually returns an error, telling me that 
>>deployment failed. Version A is still serving all traffic. Version B is 
>>apparently still running, though I didn't know that until just now.
>>3. I fix the bug and deploy version C. It starts up, version A is 
>>correctly stopped. Apparently version B is still running, though.
>>
>> So, is this a bug or expected? Is it costing us money? I'm finding it a 
>> bit hard to tell what our recent charges are for, although they are a bit 
>> higher than expected (still looking into that). I'd submit a billing ticket 
>> if I was sure.
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/8126f6c8-9971-468b-8184-3f2fa0b73936%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: GAE / Datastore issues right now?

[Linus Larsen]

Wow just got 60+ instances of my autoscaling service becuse of this, hope I 
don't have to pay for them.

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/467e341b-eb99-4ec1-bbc9-f0af3675f754%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Serious issues going on with memcache and repeated function calls

[Linus Larsen]

Is your app by any chance in europe-west region? There is a thread created 
today about this, in short we got this answer from Google today:

"There was an issue with elevated error rate for Google App Engine Memcache 
service for European applications which has been resolved for all affected 
projects. We will conduct an internal investigation of this issue and make 
appropriate improvements to our systems to help prevent or minimize future 
recurrence."

Cheers

/ Linus




Den fredag 28 juli 2017 kl. 22:45:34 UTC+2 skrev Richard Cheesmar:
>
> I am having serious issues with shared memcahce in the python standard 
> environment as of today.
>
> Even if I flush the cache, the next time I boot, it should fill the cache 
> key, less than 25MB with data, but it seems it is partially filling.
>
> I have also noticed some weird behaviour with methods being called 
> multiple times.
>
> Any ideas what is going on, this is causing severe website disruption for 
> me.
>
>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/468be0c3-86b8-4769-8568-38b4392015f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Memcache problems (eu west)

[Linus Larsen]

Thank's Michael for confirming.

I guess then there is some infrastructure work going on.

/ Linus 

Den fredag 28 juli 2017 kl. 11:37:24 UTC+2 skrev Michael Steurer:
>
> Hi Linus,
> we have the same problem on a Go standard environment for two days now. It 
> happens on some requests only but not all the time. We have bursts of a few 
> hours, e.g. yesterday from 3pm to 9pm.
>
> Best
>
>   Michael
>
>
> On Friday, July 28, 2017 at 9:28:19 AM UTC+2, Linus Larsen wrote:
>>
>> Lately I'm getting a lot of these (java, standard env):
>>
>> com.google.appengine.api.memcache.MemcacheServiceApiHelper$RpcResponseHandler
>>  
>> handleApiProxyException: Memcache putAll: Unknown exception setting 1 keys: 
>> Memcache is temporarily unavailable. (MemcacheServiceApiHelper.java:68 
>> <https://console.cloud.google.com/debug/fromlog?appModule=outlet=v38=MemcacheServiceApiHelper.java=68=597ae2230006e35f377cea51=1501225506218385000=3=epspot-production>
>> )
>>
>> I've seen this before however not as frequent, now it happens every 
>> minute but not on every request.
>>
>> Is there any work going on or is something really broken with Memcache in 
>> Europe-west region?
>>
>>
>>
>>
>>   
>>  
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/cf3611a6-2560-44b1-b88d-6eef8b68a4e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Memcache problems (eu west)

[Linus Larsen]

Lately I'm getting a lot of these (java, standard env):

com.google.appengine.api.memcache.MemcacheServiceApiHelper$RpcResponseHandler 
handleApiProxyException: Memcache putAll: Unknown exception setting 1 keys: 
Memcache is temporarily unavailable. (MemcacheServiceApiHelper.java:68 

)

I've seen this before however not as frequent, now it happens every minute 
but not on every request.

Is there any work going on or is something really broken with Memcache in 
Europe-west region?




  
 

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/51fa23a9-6ca4-453a-8c7e-e36105dca990%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Any GAE EU region changes going on we should be aware of?

[Linus Larsen]

After some digging I found out that we've made some modifications on the 
mobile app, which makes it do several ajax requests rapidly.
The result became somewhat strange.

1. Request1 starts a new instance
2. Request2 also starts a new instance since it takes aprox 20 secs to 
start a new instance, and the instance started in request1 isn't ready yet
3. Request3 also starts a new instance since the instance started in 
request1 isn't ready yet

Suddenly we have 3 instances running, and the response time wasn't improved 
since the startup time of each instance it so slow. 
I guess we can improve the behavior fiddling a bit with max/min-pending and 
min-idle instances settings.

But. As it seems, started instances are shut down very quickly, more 
quickly than they used too.

FYI, it all started last week (and it not just me who noticed these changes)

https://code.google.com/p/googleappengine/issues/detail?id=13551

And it keep on going with different kinds of issues, today pub sub calls 
timed out, memcache was totally down, datastore failures etc.
Very shaky, and it makes me wondering if Google is doing som changes in the 
EU region.












Den fredag 17 februari 2017 kl. 16:49:29 UTC+1 skrev George (Cloud Platform 
Support):
>
> Hello Linus, 
>
> You seem to have 3 projects running at this time. Which one of the 3 is 
> affected by the 100 instances for no reason at all behavior change? For 
> confidentiality, you can send us the project name by private email. 
>
> None of the 3 projects start more than a maximum of 17 instances at a 
> time. When did this change in behavior occur, exactly? 
>
> Looking at your versions in the console, one notices that "automatic" is 
> chosen as value for the "Min Idle Instances" and "Max Idle Instances" 
> parameters.   
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/4cd1885b-ab2e-4043-97dd-fac96ceae233%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Any GAE EU region changes going on we should be aware of?

[Linus Larsen]

Last couple of days our app has started to behave strange, seems like our 
instances are shut down very rapidly. Our low traffic default instance 
could easily manage a whole day with just a few instances, until a couple 
of days ago. Now it starts around 100 instances a day for no apparent 
reason. A cron job is running at every half an hour, which should keep 1 
instance alive all the time (or at least it used too), but now almost every 
of these requests fires up a new instance indicating that there was no 
instance running at all. 

Now, has anyone else noticing more spawning instances than before? 
It would be interesting to know why instances are shut down.
 

 






-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/516fb1ef-06b4-4937-8480-327dc5ccbe90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: Content-Length response header

[Linus Larsen]

FYI, we are using JAVA and no proxies in between. There is no problem doing 
a ordinary GET with curl or browser, the Content-Length header is there. 
I think this issue has to do with SSL. We have a custom domain, our own 
root certificate, and a dispatch.xml routing the traffic. Previous I posted 
an example
request for a "Hello World" request:

localhost:~$ curl -0 -I --cacert ~/cert/rootCA/rootCA.crt 
https://outlet.epspot.com/services/secure_outlet/hello

Obviously I cannot post our root certificate here, but it should give you 
an indication where the problem might be. As a mentioned before our real 
clients
is using POST and binary encoding, but it does't seem to matter, 
Content-Length header is missing.

/ Linus

 



Den fredag 18 mars 2016 kl. 21:35:36 UTC+1 skrev Nicholas (Google Cloud 
Support):
>
> According to this article 
> <https://cloud.google.com/appengine/docs/python/requests#Python_Responses>, 
> the 'Content-Length' and 'Transfer-Encoding' headers are remove from 
> responses your application may serve. Those headers are then added by the 
> Google Front End and finally, the response is served.
>
> I can't yet reproduce what you're experiencing as all GET and POST 
> requests to both my App Engine and MVM instances return 'Content-Length' 
> headers. Could you provide the following information so we could narrow our 
> testing requirements:
>
>- Request headers
>- Runtime specs (Java, Python, PHP, Go, MVM)
>- Code sample of your request handler
>- Does this occur with all your modules/versions?
>- If you deploy a 'Hello World', do you also get responses without 
>these headers?
>- Is their any proxy between the Google Front End and the client that 
>might be removing these headers?
>
> Any information you can provide to more effectively diagnose or reproduce 
> the issue would be very helpful.
>
>
> On Saturday, March 12, 2016 at 6:06:50 AM UTC-5, Linus Larsen wrote:
>>
>> Sometime yesterday (10th), our clients started to behave strage. After 
>> some investigation it seems like Google decided to remove the Content-Length
>> header from the http responses. The request / response messages between 
>> our clients are actually small protobuf encoded binary messages, using
>> Content-Type: application/octet-stream, and this has worked flawless 
>> uptil now.
>>
>> Ok, we thought we just set the clients to use HTTP1.0, since 
>> Content-Length header is mandatory in 1.0. But that didn't help we still 
>> don't get any 
>> Content-Length IMO this GAE behavior breaks GAE and HTTP1.0 compability.
>>
>> So, why is the Content-Length header missing? It was there before but has 
>> been removed, why wasn't we informed?
>>
>>
>>  
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/4e0ab957-efc3-442f-85e2-1cdccc1d8e4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [google-appengine] Content-Length response header

[Linus Larsen]

It's a bit problematic, since we have our own CA cert and our clients sends 
encrypted packages (besides SSL). However these headers are 
what we get using http 1.0:

localhost:~$ curl -0 -I --cacert ~/cert/rootCA/rootCA.crt 
https://outlet.epspot.com/services/secure_outlet/hello
HTTP/1.0 200 OK
Content-Type: text/plain
Date: Sat, 12 Mar 2016 14:48:56 GMT
Server: Google Frontend
Alt-Svc: quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"

This is what the clients are using (http POST)

HTTP/1.0 200 OK
Content-Type: application/octet-stream
Date: Sat, 12 Mar 2016 14:26:55 GMT
Server: Google Frontend
Cache-Control: private
Alt-Svc: quic=":443"; ma=2592000; v="31,30,29,28,27,26,25"
Accept-Ranges: none
Vary: Accept-Encoding

Using HTTP1.1 we get no Content-Length as well, however Content-Length were 
present before yesterday.

/ Linus

Den lördag 12 mars 2016 kl. 15:28:12 UTC+1 skrev Nickolas Daskalou:
>
> Hi Linus,
>
> Do you have a public URL we can test?
>
> Nick
> On 12/03/2016 10:07 PM, "Linus Larsen" <linus@gmail.com > 
> wrote:
>
>> Sometime yesterday (10th), our clients started to behave strage. After 
>> some investigation it seems like Google decided to remove the Content-Length
>> header from the http responses. The request / response messages between 
>> our clients are actually small protobuf encoded binary messages, using
>> Content-Type: application/octet-stream, and this has worked flawless 
>> uptil now.
>>
>> Ok, we thought we just set the clients to use HTTP1.0, since 
>> Content-Length header is mandatory in 1.0. But that didn't help we still 
>> don't get any 
>> Content-Length IMO this GAE behavior breaks GAE and HTTP1.0 compability.
>>
>> So, why is the Content-Length header missing? It was there before but has 
>> been removed, why wasn't we informed?
>>
>>
>>  
>>
>> -- 
>> 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 https://groups.google.com/group/google-appengine.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-appengine/2d8c8dbb-8f93-4935-84ea-2bcc2f86de9f%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/google-appengine/2d8c8dbb-8f93-4935-84ea-2bcc2f86de9f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/b97cc796-e248-430f-97d7-5d065a244f5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Content-Length response header

[Linus Larsen]

Sometime yesterday (10th), our clients started to behave strage. After some 
investigation it seems like Google decided to remove the Content-Length
header from the http responses. The request / response messages between our 
clients are actually small protobuf encoded binary messages, using
Content-Type: application/octet-stream, and this has worked flawless uptil 
now.

Ok, we thought we just set the clients to use HTTP1.0, since Content-Length 
header is mandatory in 1.0. But that didn't help we still don't get any 
Content-Length IMO this GAE behavior breaks GAE and HTTP1.0 compability.

So, why is the Content-Length header missing? It was there before but has 
been removed, why wasn't we informed?


 

-- 
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 https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/2d8c8dbb-8f93-4935-84ea-2bcc2f86de9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.