Infeasible
Status Update
No update yet.
Comments
mi...@upside.com.au
I guess hidden should just be defined. Meaning, right now, hidden should just defined as "whether this fragment was hidden as part of a transaction". Hidden is not equivalent with visibility. I think that's where the confusion comes from.
ak...@machimachi.com
We have passed this to the development team and will update this issue with more information as it becomes available.
mi...@upside.com.au
Yeah, I'm seeing this issue as well, currently this is the workaround that I've come up with:
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
ri...@gmail.com
@4 That actually won't technically fix as isHidden() will technically mismatch with the state passed into the child fragment. Each child fragment legitimately needs to have their state set to hidden.
fa...@google.com
Yeah, I realized that as I kept working further on it. Nevermind that solution, it doesn't work.
ri...@gmail.com
@6 I don't know what the ramifications are, but when you iterate, you can save the "currentState" and then hide them all via a transaction. When restoring to visible, restore to the original state.
am...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 02290cddca3d5e4dc94e2c5f77a6728ad970b204
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Oct 07 13:11:45 2021
Dispatch onHiddenChanged to child fragments
When a parent fragment is hidden all of its children will automatically
be hidden, but we never call onHiddenChanged on any of the children.
We should dispatch onHiddenChanged down parent's entire hierarchy and
ensure that `isHidden()` also considers the parent's state.
RelNote: "Parent fragments will now dispatch `onHiddenChanged()` down
their entire hierarchy before launching their own call back."
Test: added test
Bug: 77504618
Change-Id: Iedc201ab435cb963e81bc02d203d4d37ff827e01
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
https://android-review.googlesource.com/1850016
Branch: androidx-main
commit 02290cddca3d5e4dc94e2c5f77a6728ad970b204
Author: Jeremy Woods <jbwoods@google.com>
Date: Thu Oct 07 13:11:45 2021
Dispatch onHiddenChanged to child fragments
When a parent fragment is hidden all of its children will automatically
be hidden, but we never call onHiddenChanged on any of the children.
We should dispatch onHiddenChanged down parent's entire hierarchy and
ensure that `isHidden()` also considers the parent's state.
RelNote: "Parent fragments will now dispatch `onHiddenChanged()` down
their entire hierarchy before launching their own call back."
Test: added test
Bug: 77504618
Change-Id: Iedc201ab435cb963e81bc02d203d4d37ff827e01
M fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
tg...@infopoint.com.au
This has been fixed internally and will be available in the Fragment 1.4.0-beta01 release.
ri...@gmail.com
Was that documentation there at the time this issue was reported? I looked really hard to try and figure out a way around this and couldn't find it. I just checked and it's currently not written in the Japanese documentation. Regardless, putting that in the fine print somewhere is a cop-out. You can do better.
Anyway, you need to add asia-northeast1 to that list. I don't know what your definition of "noticeable" is but I definitely noticed it.
There should be a big red warning in the console and CLI that says "Setting a custom domain will add x milliseconds of latency for applications in <region>".
Anyway, you need to add asia-northeast1 to that list. I don't know what your definition of "noticeable" is but I definitely noticed it.
There should be a big red warning in the console and CLI that says "Setting a custom domain will add x milliseconds of latency for applications in <region>".
le...@gmail.com
Please fix this... My website is faster with appspot, very slow on my custom domain. It's hosted on southamerica-east1 (São Paulo).
im...@gmail.com
+1
Same for Europe even if it's not as huge as for other continents : 1.388 (appspot) vs 5.746 (custom)
Same for Europe even if it's not as huge as for other continents : 1.388 (appspot) vs 5.746 (custom)
ni...@daskalou.com
Serving our Australia-based (Sydney) App Engine app via a custom domain adds around 130ms for each request from Melbourne, Australia (40ms vs 170ms for a 1KB static file).
The latency is exactly the same as our App Engine apps hosted in the US.
Australia App Engine costs around 35% more than using US based App Engine.
We chose Australia in order to improve performance for our Australian target audience.
Since we are getting the exact same performance compared with having our app based in the US, what then is the benefit of having an Australian based App Engine service (besides data sovereignty issues)?
The latency is exactly the same as our App Engine apps hosted in the US.
Australia App Engine costs around 35% more than using US based App Engine.
We chose Australia in order to improve performance for our Australian target audience.
Since we are getting the exact same performance compared with having our app based in the US, what then is the benefit of having an Australian based App Engine service (besides data sovereignty issues)?
di...@gmail.com
Re #12: I definitely do NOT see this for EU domains. Given how large of a difference you're mentioning (1.388 vs 5.746) I would suspect that your "appspot" test is erroring out (so instead of doing the actual work it just throws an error early on), hence the substantially quicker response.
For reference, I did some quick tests with some of our (production) apps:https://gist.github.com/cdman/1dc3062142683f7e5608e4e3653a3de5
While the "EU" and "US" apps are different, so they can't be directly compared, we can compare "appspot vs. custom domain" separately for the EU and US, and in both cases I see appspot being ~25% quicker. While it's sad that using a custom domain adds a 25% overhead :((, this particular issue does NOT seem to impact the US or EU regions.
For reference, I did some quick tests with some of our (production) apps:
While the "EU" and "US" apps are different, so they can't be directly compared, we can compare "appspot vs. custom domain" separately for the EU and US, and in both cases I see appspot being ~25% quicker. While it's sad that using a custom domain adds a 25% overhead :((, this particular issue does NOT seem to impact the US or EU regions.
pr...@gmail.com
Is there any progress here? Please fix this faster, it takes ages to load my site with custom domain ... (asia-south1)
ri...@gmail.com
"Using custom domains in the following regions might add noticeable latency to responses: northamerica-northeast1 (Montréal), and southamerica-east1 (São Paulo), asia-south1 (Mumbai), and australia-southeast1 (Sydney)."
I guess no one read my last comment. asia-northeast1 is not in that list but I noticed latency there. Please either fix the issue or add asia-northeast1 to the list.
I guess no one read my last comment. asia-northeast1 is not in that list but I noticed latency there. Please either fix the issue or add asia-northeast1 to the list.
mc...@tecnogo.com
I have the same problem in southamerica region
pu...@gmail.com
Seeing the same thing, using aus appengine and curling appspot vs custom domain from Sydney. Actual website usage reflects these times, very obvious in chrome dev tools.
➜ ~ time curl -s https://[redacted].appspot.com > /dev/null
0.26 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted].appspot.com > /dev/null
0.25 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted].appspot.com > /dev/null
0.21 real 0.04 user 0.01 sys
➜ ~ time curl -s https://[redacted].appspot.com > /dev/null
0.24 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.04 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.07 real 0.04 user 0.01 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.14 real 0.03 user 0.00 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.08 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted].
0.26 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted].
0.25 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted].
0.21 real 0.04 user 0.01 sys
➜ ~ time curl -s https://[redacted].
0.24 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.04 real 0.03 user 0.01 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.07 real 0.04 user 0.01 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.14 real 0.03 user 0.00 sys
➜ ~ time curl -s https://[redacted] > /dev/null
1.08 real 0.03 user 0.01 sys
[Deleted User] <[Deleted User]>
It's a shame, more than a year with this issue. Is in this way Google is trying to get more companies on App Engine ?
Sorry but you are doing it wrong.
Sorry but you are doing it wrong.
jo...@gmail.com
Currently evaluating a switch from AWS, looks like we'll be staying at least until this is sorted...
k....@gmail.com
Please have an update on this as soon as possible. This feature should be considered unusable as we are now exposing appspot domains to clients and cannot change this if it causes huge latency penalties. We hope that Google provides us with a little more support than "it's in the docs" as this should be a standard requirement. Ward off any other users from app engine standard by making this big red and bold on the front page of the docs, if Google has the above attitude. Our project is too big to migrate at the moment and we are getting a little annoyed by the lack of support.
ri...@gmail.com
Is this ever going to be fixed? I also experience this with my instance in São paulo. The latency difference is absurd, from 300ms to 3s.
[Deleted User] <[Deleted User]>
I have the same problem. Some IPs attributed for ghs.googlehosted.com are down. I need all IPs attributed for ghs.googlehosted.com are working. See the image.
mc...@tecnogo.com
This is unacceptable. Evaluating to switch to AWS.
ap...@evmanapp.com
Please fix as it's almost doubling response time. Also, while documentation is there regarding this issue in form of "Using custom domains in the following regions might add noticeable latency to responses", presentation is not reflecting that it's a deal breaker.
For many of us, custom domain mapping would be last thing of development and not so red alerted fyi kind of one liner is easy to miss. - from asia-south1
For many of us, custom domain mapping would be last thing of development and not so red alerted fyi kind of one liner is easy to miss. - from asia-south1
ri...@gmail.com
So much time has gone by that my contract with the company whose website I deployed is ending this month. That's not how I wanted to solve this problem for myself, but I guess that works in a way.
As I and others have previously requested, if you're not going to fix the issue, make it clear to users that it exists before it's too late and they have to start evaluating a switch to other infrastructure.
As I and others have previously requested, if you're not going to fix the issue, make it clear to users that it exists before it's too late and they have to start evaluating a switch to other infrastructure.
ni...@daskalou.com
Agree that this should really be made a lot more clear and obvious in the documentation, and in multiple places within the documentation.
ri...@gmail.com
If anyone is interested, the one workaround that I know of is to use a CDN that allows overwriting the host header so you don't have to use the CNAME record provided by Google. It will cost money of course, and might have more latency than just accessing the *.appspot.com domain, but it works and is faster than AppEngine custom domains in some cases. It depends on how close the CDN's edge is to your user vs how long the round trip is for AppEngine custom domains.
In my case, since requests using custom domains for AppEngine apps deployed in Tokyo go through Taiwan for some reason, all my users in Tokyo have to make a few-thousand kilometer round trip to do anything. However, if I use a CDN with an edge server in Japan, that distance is cut down significantly.
When (if?) I release another project on AppEngine I will most likely do my custom domain on a CDN instead of just using AppEngine's settings.
In my case, since requests using custom domains for AppEngine apps deployed in Tokyo go through Taiwan for some reason, all my users in Tokyo have to make a few-thousand kilometer round trip to do anything. However, if I use a CDN with an edge server in Japan, that distance is cut down significantly.
When (if?) I release another project on AppEngine I will most likely do my custom domain on a CDN instead of just using AppEngine's settings.
th...@gmail.com
I'm posting my situation here for the GAE team. I map a custom domain to one GAE instance in us-central (which is not on the list of locations affected by this issue, regarding the documentation). When I visit the *.appspot.com url from Asia the latency is around 200ms and pretty stable. But when I visit the custom domain the latency is mostly around 200ms, too, but would randomly go up to 600ms or higher.
Hope this issue got addressed soon.
Hope this issue got addressed soon.
aa...@alaisteryoung.com
Still having the exact same issue almost 2 years on. Any updates?
[Deleted User] <[Deleted User]>
This also affects projects outside of those mentioned regions. We have one in us-central1 where the latency is measurably slower when accessing it through the custom domain, compared to the *.appspot.com domain name. The impact is much less (maybe ~40-100ms), but it is still there.
ir...@gmail.com
I haven't measured it exactly, but this issue is adding ~1.5 seconds of latency to my site on southamerica-east1. A shame, because the appspot.com subdomain is fast.
ri...@gmail.com
I don't know why Google doesn't seem to care about this.
It also affects Cloud Run:
Custom domain:https://therandompassword.app/
Not custom domain:https://the-random-password-app-orl44wmsxa-an.a.run.app/
This problem has a simple solution: Host the servers routing custom domains in the same place as AppEngine and Cloud Run!
It also affects Cloud Run:
Custom domain:
Not custom domain:
This problem has a simple solution: Host the servers routing custom domains in the same place as AppEngine and Cloud Run!
so...@google.com
GCP Networking Engineering team is working on it. there is no ETA for this at the time.
mi...@upside.com.au
Are there any ETAs now?
ca...@gmail.com
we are facing the same problem in southamerica-east1
aw...@gmail.com
Its been 3 months since the last post GCP Network Engineering, any ETA??
de...@danielcompton.net
We have this issue in us-central1, even though that region is not on the list of regions that have a latency impact. The
If your app is located in one of the following regions, using custom domains might add noticeable latency to responses:
- us-west2
- us-east4
- northamerica-northeast1
- southamerica-east1
- europe-west2
- europe-west3
- asia-south1
- asia-northeast1
- australia-southeast1
ri...@gmail.com
I've found myself running into this issue AGAIN when I tried to use custom domains with Firebase and Cloud Run. I guess it was silly of me to think that doing that would yield a better result. I don't understand why Google went to all the trouble of putting these datacenters all over the world if they didn't plan on routing traffic to the closest one.
[Deleted User] <[Deleted User]>
It incredible to see this issue still open. Since 2017, is it incompetence or what?
ir...@gmail.com
Could you at least tell us if there are any plans to fix this in the foreseeable future? It seems like nobody's working on it and it's at the bottom of your priorities list. Thanks.
ja...@port.ac.uk
This is still an issue; please keep working on it and please – please – post updates here!
lu...@gmail.com
Same here for southamerica-east1.
This doesn't make any sense. They need to fix that.
This doesn't make any sense. They need to fix that.
ri...@gmail.com
Two years ago you said that "there is already an effort underway to make it similar in terms of latency to the appspot.com ." What is the status of that effort?
ma...@gmail.com
I had to stop using AppEngine because of this issue. There is no prevision of the fix?
mi...@nurturecloud.com
3 years for such a critical issue is far too long. We are planning migration away from GAE and straight to AWS.
am...@craveretail.com
Can we get some details on what the issue is?
[Deleted User] <[Deleted User]>
It seems like Cloud Run has the same issue (
It seems promising, but I haven't tried, yet. If someone has, could you please share your experience?
[Deleted User] <[Deleted User]>
Here we decided to connect to our back-end service with the appspot domain. The latency is way lower, even with CORS preflight requests - which we found to be typically below 20 ms.
So our users see our custom domain in the browser, even though the back-end is in another domain. It is working great.
It seems like appspot.com uses some experimental HTTP/3 features, which can be spotted by the alt-svc: h3-29=":443" response headers
am...@google.com
Hello,
Unfortunately the internal Bug related to this has been marked as Infeasible due to the following reasons described by the engineering team:
First, serverless neg behind Google Cloud Load Balancing now exists, and has neither the latency nor cross-region query flow problems, as well as having other functionality like cache flushes and TLS cipher control. Significant investment has gone into it. We would like to encourage that customers who have these concerns use this system. We're not suggesting that custom domains via the shared VIP be deprecated - indeed we've just staffed a multi-quarter project to roll out zoo3. But we're not going to invest in improvements beyond that at this time.
Second and more importantly, the originally envisaged architecture for improving latency and eliminating cross-region queries on the non-GCLB flow is no longer viable, because the whole concept of a single giant multi-purpose shared L2 fleet goes against the reliability program work.
For that reason I will close this Bug Report as well, I apologize for any inconvinience that this may cause.
ir...@gmail.com
Cloud Load Balancing in the South America region is around 30 USD/month, just to have it active. That may be peanuts for a large enterprise, but it adds up for us little guys. Besides, it seems pointless and needlessly complicated to set up load balancing with just one back-end, only to solve this issue. App Engine itself is already load-balanced.
Anyway, thanks for the update. At least now we know.
Anyway, thanks for the update. At least now we know.
ri...@gmail.com
I think Google has lost its way when it comes to App Engine, and subsequently Cloud Functions and Cloud Run. The thing that sets it apart from other services that it "just works" and we don't have to worry about application servers and load balancers and networks. Now everyone has to set up, maintain, and a load balancer just to avoid completely unnecessary latency? That is so disappointing.
There's no excuse for dragging this out for three years while we continued to support you by paying for your services, thinking you would eventually fix it. We waited because you said "GCP Networking Engineering team is working on it."
There's no excuse for dragging this out for three years while we continued to support you by paying for your services, thinking you would eventually fix it. We waited because you said "GCP Networking Engineering team is working on it."
da...@gmail.com
I am having this same problem and I'm not in a 'slow'' region. I have relocated to us-west4 (Las Vegas) to avoid this issue but I'm still getting a much slower response time from the custom domain:
Custom domain: 1.25 seconds
appspot: 200ms
I testing this from Sydney using Go1.15 on App Engine Standard.
Is it still possible I have made some error or are others seeing this difference even in regions that are not know as slow?
al...@symph.co
I made this tool to quickly check minimum latencies of different appengine regions and domains. It's not polished, but I use it to help me decide what region to choose for projects.
https://appengine-ping.symph.co/
I'm from Philippines, and this is how mine looks like after 3mins (it runs 4 rounds to try to get the minimum). Numbers are in ms.
It's sometimes weird coz the numbers change from time to time across refreshes. It's not the best measuring tool, but maybe it could help.
I'm from Philippines, and this is how mine looks like after 3mins (it runs 4 rounds to try to get the minimum). Numbers are in ms.
It's sometimes weird coz the numbers change from time to time across refreshes. It's not the best measuring tool, but maybe it could help.
ma...@parkable.com
Bummmp! This is crazy! Please fix..
aa...@gmail.com
This is beyond insane to have been seemingly parked as a no-fix? We sometimes experience 2 seconds latency in the EU-West-3 region, that's absolutely absurd. It's been 3 years!? I mean Google's own tool "Lighthouse" is recommending "optimize initial server respond time" for their own Appengine service. We will move to AWS unless fixed in a reasonable time.
ri...@gmail.com
Since Google has marked this infeasible, I've had to mark all future use of AppEngine, Run, and Functions as infeasible. What else can I do when I and most of the users of anything I would build are in Japan? Sad.
ir...@gmail.com
At the risk of violating some TOS here, I recommend Cloudflare Workers to anyone struggling with this issue.
They are truly serverless: there are no instances, scaling, regions or anything like that. Workers run everywhere. That also puts them closer to the users and makes them incredibly resilient. They also come with neat tools like KV storage, CDN cache manipulation, etc. They offer a generous free tier, and it's cheap if you need more.
There are differences between Workers and App Engine so it may not be suitable for everyone and it could require some work to migrate your app, but it's worth checking it out. I already migrated some of my stuff and I will eventually migrate the rest.
na...@gmail.com
Holy crap, can't believe this is marked as won't fix. Time to move off of appengine - I wish I knew about this before setting everything, app/domain/redirects, up in GAE.
so...@gmail.com
Hi Google Team, Is there any update on this issue. It's been a long time and the issue is still there which is really affecting the websites with custom domains, the websites becoming super slow because of this. Even tried min_idle_instance option as well but there is no effect and the response time is like taking sometimes half of a minute.
da...@gmail.com
Has anyone found a us-based region that does not have this custom domain routing issue? I've been seeing this issue in various us-central1 apps for quite some time, yet us-central1 isn't present on the list of affected regions provided by google, and there are a few others here with the same issue.
Description
The issue affects more severely local users, as in users in Australia accessing apps in australia-southeast1.
We're working on fixing this issue, but at the moment we don't have estimate to have this issue fixed.