IssueTracker

Hey, sorry for coming back to this so late. We've never seen this. Without any repro steps it's going to be hard to do anything about it.

We've some cases where the Gradle daemon gets started but Studio cannot connect to it and the Studio side Gradle code handling connection to the daemon will keep spawning new ones if the connection does not get established. In this instance though the fact that the build window shows all these daemon running means that this is a different problem.

Hello, I had the issue reproduce on first project open after upgrading Android Studio from JetBrains Toolbox. Note that the project has a buildSrc.

I think you can reproduce it with the same steps if nothing changed since Arctic Fox alpha 08.

When you upgraded from the toolbox, can you indicate which version you started from and what you upgraded to?

Yes, actually it's in the title of the issue: Canary 7 to 8 of Arctic Fox.

oops, thanks :)

I just had that again when upgrading from AS BB Canary 2 to AS BB Canary 6. I am attaching screenshots and a screencast so you can see how it is materializing.

Note that for some reason, Gradle sync is complaining about JDK location while it was working perfectly on Canary 2 (and I only touched the AGP version), I don't know why and I don't plan to investigate that now, I'll just try to fix it and move it.

Wait, I cannot view my own restricted content? 😒

I don't know the difference between restricted and restricted+ beyond difference in access level. I think googlers have access to restricted for sure (I can see your last 2 restricted comments/attachement) but I'm not sure about restricted+.

I got the issue again upgrading from BumbleBee Canary 6 to Canary 7 (note that I upgraded AGP externally while AS wasn't open, because I wanted to save time by skipping a predictably failing Gradle sync).

This time, I got an interesting error in one of the 10 concurrent Gradle sync attempts:

Timeout waiting to lock buildSrc build lock. It is currently in use by another Gradle instance.
Owner PID: 9842
Our PID: 9845
Owner Operation: 
Our operation: 
Lock file: /Users/me/AndroidStudioProjects/ProjectName/buildSrc/.gradle/noVersion/buildSrc.lock

It looks like there are now file locks in place, allowing the issue to be detected in a better way, but it is still happening.

I am wondering if there is any cache that would depend on the AGP version of the last Gradle sync, and that when there's a difference between last sync AGP and the AGP AS is looking for, or the AGP of the project, AS tries doing Gradle syncs differently from how it'd try to do it when you click the Gradle sync button in the toolbar, the banner, or the Gradle tool window.

Do you know how close I am to the culprit?

Would you be able to share .idea/gradle.xml file with us? Or can you just confirm that there is only one <GradleProjectSettings> entry in the file?

I just attached it (restricted), and I can confirm there's only one <GradleProjectSettings> xml tag.

Thank you!

I found the problem in the code. We incorrectly handle detection and presence of data from previous versions of Android Studio in the cache.

Until we fix it, you should be able to get out of this state by invalidating the cache or specifically deleting the external_build_system in the Android Studio's system directory.

Hello, has it been fixed in BumbleBee Canary 10?

I had the issue when upgrading to Canary 9, but not when upgrading to Canary 10.

No, it hasn't been included in any canaries yet. However, once you have resolved the issue it should not re-apear.

The problem was triggered when Android Studio attempted to re-sync a project because of outdated cached data and upgrading to a newer canary version does not usually require re-syncing.

I'm assuming you meant "hasn't".

Reading again what you wrote, I guess it was caused by the fact that I did an Invalidate caches and restart (for another reason), something I rarely do, so yes, not fixed, but not prone to happen again this soon in my specific case.

yes, sure (edited the comment), thank you!

"Invalidate caches" should resolve it and I don't expect "9 to 10" upgrade run into this issue.

Is that a spam comment just above?

Yuriy, I am assuming this code has now been merged and released ?

yes

Thank you for addressing this 🙏

Have a great day!

This is still work in progress.

We just went through a whole ordeal with Google Support to get insight into if and when this feature (Logical Decoding) will become available, but in the end ended up being redirected to post our thoughts here and wait for the Cloud SQL Product Team to respond. This is after having been in contact with Google in early 2019 and been told to expect an update on the roadmap for this feature in Q3 2019...

Google Support asked us to repost our concerns and urgency here, for the Product Team to respond, so here we go:

use case

Our use-case is that we need to be able to extract ALL changes made to our data in near-real-time, without overhead to the client making the changes and in a maintainable fashion. We need to extract ALL changes made to our databases to keep external systems in sync, in a near real-time manner.

Our current approach is using INSERT/UPDATE/DELETE triggers on each table, but this incurs way too much overhead, causing unacceptable client slowdown. Doing this on the application level isn't an option either, as it's unmaintainable

what we need

So we want to handle this on a database-level and with PostgreSQL this would be using their Logical Decoding feature. However, settings and privileges' needed to use Logical Decoding on Cloud SQL for PostgreSQL are currently not enabled:

• wal_level parameter is set to 'replica' (probably because its needed for Create Replica), but for Logical Decoding it needs to be set to logical
• ability to control the max_replication_slots setting, as a replication slot is per database on a server and we run servers with way more databases that the default value (10) for max_replication_slots (probably also requires the max_wal_senders setting to be configurable
• ability to create (and drop) replications slots, see Logical Decoding Examples
• ability to create PUBLICATIONS, needed when using the pgoutput plugin icw Logical Decoding
• optionally support output plugins like wal2json Logical Decoding Plugins

urgency

As for the urgency: we're currently running into the limitations of the trigger-based approach, from a performance perspective. We can probably get away with it for a few more months (among others by disabling some features), but giving the lead times of the possible solutions, we need to set the wheels in motion right now.

As we see it we have 2 options:

1. Wait for Cloud SQL for PostgreSQL to add support for Logical Decoding
2. Migrate to any other hosted PostgreSQL offering, as pretty mush all other major and minor managed PostgreSQL offerings offer support for Logical Decoding

what we want to know

Given that setting in motion and executing a migration to another managed PostgreSQL provider has a lead time from somewhere between 2 to 9 months, we would like to know the roadmap for Logical Decoding on Cloud SQL for PostgreSQL, as we don't want to set the wheels in motion, only to learn 3 or 6 months from now that support was added for Logical Decoding, voiding all our migration efforts, as we're otherwise very happy with Cloud SQL and it's our preference to remain on it.

So, in the end, what we are after if for Cloud SQL for PostgreSQL to come up to the level of all other major and minor PostgreSQL hosting providers and make it possible to use Logical Decoding and create Logical Replication slots, so tools like Debezium can be used.

Would love to see Cloud SQL for PostgreSQL be added to this list: Setting Up PostgreSQL

Hoping the above clarifies our needs and urgency and hoping for a speedy response, so we can decide which wheels to set in motion.