Metadata-related exceptions

[Xander Victory]

During metadata deployment (native connection, check for conflicts=shared logins), a bunch of “fun” exceptions (Read access is allowed from event dispatch thread or inside read-action only) are logged during the listing metadata stage. There are a lot, but they all appear to be roughly the same, so only a few copied in attachment.

The deploy is still able to proceed (though presumably without checking for modifications properly)

[Scott Wells]

Ugh...yeah, these "read access/write access allowed..." errors change as the base IDE gets updated based on the context in which certain things execute either changes and/or as JetBrains adds more of their own validation. I'll take care of these in the next build or so. Thanks for reporting.

[Scott Wells]

Prospective fix delivered in 2.0.9.4. Let me know if you continue to see this issue after updating.

[Xander Victory]

Sadly it still happens :(

[Xander Victory]

This was just pulling up the Retrieve Metadata dialog, though the list still shows despite the errors

[Scott Wells]

Not entirely surprising. Unfortunately I was unable to reproduce the issue so I tactically addressed the particular item in your log. Thanks for providing another log. Give me just a few and I'll attach another build that addresses all other potential instances of the same issue in this area of code to see if that helps.

[Scott Wells]

Here you go. You can install it using Settings/Preferences>Plugins>Install plugin from disk (under the gear drop-down menu). Please let me know if you continue to see this issue on the attached build.

[Xander Victory]

are we sure this isn't a Jetbrains bug? It always seems to happen within their XML functions

[Scott Wells]

It's not a JetBrains bug. The issue is occurring in IC code where I'm using their XML support to parse and extract information from composite XML documents such as *.object files. The nature of the issue is that you're not supposed to read from these parse trees unless you're on the EDT which ensures single-threaded behavior or in a declarative read action which tells the plugin SDK to mutex access to the tree. However, this becomes a moving target when something that did occur on the EDT in a previous release of the IDE no longer occurs on the EDT in a newer release. Sometimes the threading behavior can even vary by host OS, though that's more rare.

I hate to treat this like an onion-peeling exercise, but since I'm not seeing these, I'm just studying the calls made in this area of the code and looking for those that are reading from the parsed XML document. I did find another one using your log and fixed it. I'm not seeing any others that look like they'd cause the same issue. I'm spinning another build right now for you to try. Apologies for using you as a beta tester here...

[Scott Wells]

Here you go. Same install instructions as before. If this one doesn't take care of it I'm going to try to instrument the entry point of the code to reproduce the issue instead of wasting any more of your time.

[Xander Victory]

Success!

No IC errors from full retrieve, single file deploy changed (where nothing changed), then single file deploy all metadata

I don’t mind being the guinea pig either, I know very well what it’s like not being able to reproduce bugs!

[Scott Wells]

That's great! And I appreciate your willingness to work through this in an iterative fashion with me. Yes, it's very frustrating to have a user clearly experience an issue but not be able to reproduce it. It happens more often with environmental things such as restrictive networks, but once in a while things like this happen as well where it should reproduce easily for me, but for whatever reason it doesn't.

Stay on this build for now, and when I release the next build (likely next week given the US holiday this week), it'll be safe to update.

[Scott Wells]

Delivered in 2.0.9.5.