Frequent Freezing and Generally Poor Responsiveness / UX

[quietopus]

Not sure exactly how to reproduce. Problems are frequent and ongoing when editing Apex code. Project size is 20-30 classes with few, if any, dependencies outside of the project. Sophisticated use of inheritance, interfaces, and abstract classes.

Main Issues

• Most of the time, error checking is quick to respond but unusably slow to adapt.
• Work is occasionally lost due to IDE freezing and needing to be restarted.

Slow Type and Scope Checking

Variable names and types are marked as unresolved/incorrect before I can finish typing them. Error annotations remain on-screen for several seconds if not indefinitely, even after errors are corrected. Needing to either ignore annotations or spend a few seconds reading each error tool-tip to decide whether it is relevant.

Mid-statement edits sometimes cause large-scale invalidation of code with sluggish removal of error annotations once edit is complete.

Freezing

While editing, IDE frequently freezes for 5-20 seconds at a time. Occasionally, IDE freezes indefinitely, requiring me to forcefully terminate the IDE. Each time this happens, I lose all work done since the last save.

The indefinite freezing / termination scenario tends to recur around the same code / edit. IDE freezes and 5-10 minutes of work is lost. I restart the IDE and attempt to redo the work. A few minutes later, the IDE freezes again and the same work is lost again. The attached idea.log and idea.log.1 files attached depict this event. The threadDumps-freeze directories without duration suffixes (e.g. -18sec) indicate times when the IDE was forcibly terminated (three since yesterday).

[Scott Wells]

Sorry that you're having these issues. It sounds horrible, to be sure. Let's see if we can figure out what's going on. First, do you have any notion of when this change in behavior started (assuming it is in fact a change in behavior)?

I've scanned the provided log and many of the thread dumps. There's nothing about IC in the log really, and while I see com.illuminatedcloud in several of the thread dumps for longer pauses, what I'm seeing doesn't seem to represent a consistent pattern and the stack trace locations I do see don't seem like things that would cause pauses. It does look like you have a number of other plugins active including Maven, Kotlin, GitIgnore, etc., that do pop up frequently in these thread dumps. By no means am I trying to point the finger at something else--I personally also use Maven and GitIgnore as well--but perhaps we should start with a few straightforward troubleshooting steps:

1. Can you disable any enabled plugins that you know that you're not using just to rule them out? If the behavior is the same after slimming down the active set, that's certainly useful; if the behavior improves, that's also useful.
2. Have you raised the max heap for the IDE just in case these are garbage collection pauses (albeit long ones)? You can read about how to do that here. I almost always add -Xmx2048m in my installs if not 3072. Again, let's see if that helps or not.
3. Can you try completely rebuilding caches and indices using File>Invalidate Caches / Restart? I noticed that you're on 2019.1 which should have performed a full reindex, and I don't see any signs of corrupted caches in the log you provided, but again, let's rule out the potentially obvious things.
4. Out of curiosity, how big is your .idea/workspace.xml? I had another user the other day having slow performance saving things, and it turned out that file had grown to >100MB for him. The IDE was saving it to disk constantly which was slowing down almost ever operation. He deleted the file because it most almost exclusively cruft, and the performance change was dramatic! You don't even have to delete it...there's probably a large amount of stuff in that file that can be removed safely while leaving the rest. But let's only entertain that if the file is quite large. If it's small(ish), it's almost certainly not the issue.

Okay, let's start with those and see where that leaves it. Please let me know.

[quietopus]

Thanks for the quick response and the helpful suggestions! I have addressed the items on your list as follows:

1. Tentatively disabled about 105 plugins (82 bundled, 23 downloaded).
2. System default was -Xmx750m. Custom value was -Xmx1125. Raised the custom value to -Xmx3072. Will lower this if it becomes a burden on the system (total 8 GB RAM).
3. Done. Invalidated caches, restarted, and waited for indexing to complete.
4. The project in question has a .idea/workspace.xml file size of 954 KB. Also looked at the same file in a number of other active projects. The largest I found was 2,660 KB.

Will continue working with the above settings and post back when it becomes apparent what discernable result they have achieved, presumably some time within the next few days.

[Scott Wells]

Sounds good. That should rule out the most obvious reasons that come to my mind. Please let me know your experience with these changes in place. Hopefully one of them (or some combination of them) will address these long pauses for you. If not, though, at least there will be less potential contributors to sort through.

[quietopus]

The worst problem (freezing, requiring forced termination) happened again. See attached logs in logs-20190404202800.zip.

After configuring the system according to my previous comment, initial results were relatively acceptable:

1. Started up the IDE, looking at the same project.
2. Opened up an Apex file. All types were marked as red / undefined.
3. Regenerated the symbol table for the module.
4. Waited for Indexing to finish. Errors remained.
5. Restarted the IDE (without invalidating caches / indexes).
6. Errors were gone.

Then, this happened:

1. Opened up an Apex class which had previously been prone to triggering freezes.
2. Highlighted a particular portion of code, which had previously taken multiple attempts to complete without triggering a freeze.
3. Pressed CTRL+X (cut).
4. The IDE froze, requiring a forced termination.

The indefinite freezing very often seems to be triggered by actions which result in the removal of code (i.e. cutting or deleting). In this case, at least, this intuition seems to be correct.

[Scott Wells]

Okay, at least we know it's something else. The good news is that the behavior you're seeing is absolutely not normal and not acceptable. As a frame of reference, I also use IC every day for Salesforce development in my ISV role on a Surface Pro i5 with 8GB of RAM and things hum along very nicely.

Let's start with the first behavior you described because item 2, "All types were marked as red / undefined", indicates that misconfigured project to me. That could lead to other downstream issues. Can you describe the directory structure of your project and then send me your .iml file for review? Feel free to email it if it contains sensitive information. I'm mainly trying to see if the source roots and such are properly configured.

[Scott Wells]

Okay, I'm seeing some potentially curious behavior in the thread dumps you provided, in particular toward the end (time-wise) which presumably matches the IDE freezing entirely. I see three threads in IC code blocked waiting on locks--two on the same lock--during indexing. All of the lock acquisition is attempted by code in the base IDE, but in response to IC trying to read from the index in both cases. I can't be 100% sure, but it certainly looks like it could have led to a deadlock which would explain the latter behavior.

I also saw this in the idea.log that you provided:

2019-04-04 19:50:04,953 [ 219362]  ERROR - j.psi.stubs.StubTreeLoaderImpl - Outdated stub in index: file://C:/path-hidden indexed at 1554355574458 with document size 6932, doc=DocumentImpl[file://C:/path-hidden], docSaved=false, wasIndexedAlready=true, queried at 1554355574458
indexed lengths={chars=6932, bytes=7160}
doc length=6359
file length=7160
cached PSI class com.illuminatedcloud.intellij.filetype.ApexClassFile
PSI length=6359
projects with file: 1 

Just to be 100% sure, when you rebuild caches, you did use File>Invalidate Caches / Restart>Invalidate & Restart, correct? I just want to make sure that you're rebuilding all indices and not just IC's.

Sorry if I'm repeating myself, but did you mention when this behavior started for you? I don't need an exact build, but was everything fine and then this behavior started, or is this what you've been experiencing all along? Is there any chance it coincided with the upgrade to 2019.1? If there's a chance, could you roll back to 2018.3.6 to see if that resolves the issue?

Casting a pretty wide net, I know, but given that I've not seen this behavior before, and given that's happening so regularly for you, I'm trying to isolate key contributors.

[quietopus]

Here are my best responses to your questions:

Project Structure

My project structure typically consists of an empty project with Illuminated Cloud modules subsequently added. My usual setup steps are actually described more or less in detail in another issue of mine, Issue 1188.

Note that I usually manually configure the SDK setting for each module so that modules in the same project pointing to the same org share the same symbol table. This involves manually configuring File > Project Structure > Modules > module-name > Dependencies > Module SDK (if the setting is already set, I re-click the setting anyway, since sometimes the table beneath the drop-down contains a red-colored entry even when the SDK is selected.) and File > Project Structure > Project > Project SDK.

The workspace for this project looks something like this:

.idea/
# Created Automatically
IlluminatedCloud/
# Created Automatically
misc-resource/
# A nodejs module containing a custom build for a third-party JS resource.
orgname--sbname__generic/
# An IlluminatedCloud module containing custom-built, unmanaged items.
# Includes various Aura Components, Lightning Web Components, Apex Classes, Custom Objects, and a Static Resources compiled from the misc-resource directory
orgname--sbname__project/
# An IlluminatedCloud module containing custom-built, unmanaged items.
# Includes Apex classes only.
orgname--sbname__dev-ui/
# An IlluminatedCloud module containing custom-built, unmanaged items.
# Contains Lightning Web Components, Apex Classes, and Static Resources.

Each IlluminatedCloud module directory uses a sandbox connection and uniformly contains src and .git directories (registered as VCS roots), along with a .gitignore file and the module's module-name.iml file. Checking File > Project Structure > Modules > module-name > Sources for each module shows src as the only folder listed under the Source Folders panel all the way on the right (I never modified this).

I am not sure whether my client would see it as being in their interests for me to send the config files themselves. Will look into it. If sanitizing the names is too troublesome, perhaps I can get approval otherwise. In the best case, where can I find your preferred email address (or at least reach you on a private channel)?

Invalidating Caches

Every reference I have made so far to invalidating caches and restarting has referred to my using the File > Invalidate Caches / Restart > Invalidate & Restart menu option.

First Occurrences

I've seen the freezing problem off-and-on since late January. I logged Issue 1243 in early February, concerning the freezing.

As always, thanks for your help!

[Scott Wells]

Okay, thanks for the update, and thanks for referencing the older issue. I have no idea how that slipped my radar, but I'm profusely apologetic that it did. Hopefully we'll be able to figure it out now that I'm fully aware of it.

So...the way you're manually setting the SDK definitely stands out to me. IC goes out of its way to own the creation and association of SDKs with modules, and that's certainly something that I haven't personally done, nor have I seen others do. IC will share an SDK associated with a connection's OST automatically by choosing the same connection for multiple modules, but it's not really designed for sharing the same OST with multiple modules the way (I think) you're doing it. Let's try a few things there...do you see the same problem with a single-module project using a single SDK created/managed 100% by IC? Note that my current day job project has ~7 IC modules, so there's definitely no issue using multiple modules. I just want to build up from something really simple and see if/when we can see the problems start. If a single-module project with an IC-managed OST/SDK works fine, what happens if you add a second module and let IC manage the OST/SDK for it? Let's see where that pattern leads us.

[quietopus]

No worries. I can imagine a side-project as widely used as this one would be quite demanding.

Regarding the setup:

Happy to know if there is an alternative way to address the reason for my using the IDE the way I am. I share the OST among modules because I often have multiple modules pointing at the same connection, and each new module generates an error stating that an OST needs to be generated. Waiting 15-20 minutes for IC to generate several exact copies of the same data (and re-generate them if the OST becomes outdated) seems wasteful if it can be avoided. So, instead of generating them, I generate the first one and then point the others to it. The reason I often use multiple modules for the same connection is so that I can segment the project directories across feature lines, which makes features easier to segment into repositories which cater to similar concerns.

Regarding the experimentation:

I'll setup something like you described and take note of what happens.

Which issue are we looking for at the moment? The undefined references? Or the freezing? Not sure I can conclusively say whether the freezing is or isn't an issue with a given setup, since I do not know how to reliably trigger it.

[Scott Wells]

Thanks for being so understanding. On a semi-related note, a week-from-Monday IC will no longer be a side-project for me. I'll be working on it full-time. VERY excited about that change.

OSTs (and their associated SDKs) are 1:1 with connections, and connections can be 1:many with modules. That's how we set up the project at my day job. I'd show a screenshot but it would contain some sensitive information.

Regardless of how many modules you have in a project, you should only need to generate one OST per-connection used by that project. It sounds like you're trying to reproduce that same setup. If you just choose the same connection for all modules that should share it--and currently you'll also need to choose a unique development package per-module--when IC generates an OST for that connection, all modules will be updated to use the resulting SDK.

As for the issues you're looking for while working up from a simple single-module project to a more complex structure, pretty much all of the things you described. Nothing you described in your response from ~3 hours ago should be occurring. Not the red unresolvable references that finally resolve, and definitely not the IDE lock-up. My guess/hope that the simple project doesn't exhibit any of those issues. Then it's a matter of building up to figure out what change introduces them.

Please keep me posted, and if it would help to have a screenshare to let me see some of this personally and to compare notes on multi-module projects, I'm happy to do so. Let's just coordinate a common time.

I'm going to be crashing for the evening soon and won't be responding until tomorrow. I'll be interested to hear what you find, though.

[quietopus]

Congratulations on your transition to full-time IC support!

Will post a ticket update momentarily.

[quietopus]

I set up some dummy code and ran through a couple scenarios, saving screen shots along the way.

The attached file (ic-bug-report-1266.zip) includes the following:

• screen-shots/single-module-project/
  • Screen shots taken while setting up a simplest-case, single-module project. Files are numbered in chronological order.
  • Didn't run into any issues doing this.
• screen-shots/multi-module-project/
  • Screen shots taken while setting up a project typical of my usual workflow. Files numbered in chronological order. Mouse position indicates item clicked.
  • Ran into some issues with items not being defined.
• workspaces/
  • Contains the full workspaces for the above cases.

Hope that is helpful.

[Scott Wells]

Aha! Those screenshots were INVALUABLE! Thank you. So...when you create the second module that depends on the contents of the first module, you also have to establish an explicit dependency relationship in IntelliJ IDEA between them. Open the project structure, select the dependent module (quietopus3-dev-ed__project), click the Dependencies tab, click the + button, and add a module dependency on the base module (quietopus3-dev-ed__generic). That will allow IC to resolve the dependencies across module boundaries. That should definitely eliminate the red that you're seeing around unresolvable references across modules.

Let me know how much of this is resolved by that change. Thanks for sending such detailed info!

[quietopus]

Yes, that fixed the unresolved references. Thanks!

I also tried it on my projects from Issue 1188 and it seemed to resolve that issue as well. I'll make a comment there shortly.

[Scott Wells]

That's great! Thanks for updating the other issue and for all of the help digging into this. Hopefully this resolves all of the issues you've been having, but if it doesn't, just let me know and we'll dig into the next set of them.

[quietopus]

Can't be sure at the moment if the freezing and sluggish code highlighting are solved, but I'll definitely add the dependency configuration to my current projects, continue working with my earlier performance-enhancing setup, and update you within the next few days (or probably sooner if I get another freeze), as I gain confidence in how the IDE is responding.

Thanks for all your help!

[quietopus]

More freezing, requiring forceful termination.

I suppose the good news is that the freezing seems to be repeatable (for the time being) by attempting the same code edit, describe in an earlier comment.

To review:

1. Opened up an Apex class which had previously been prone to triggering freezes.
2. Highlighted a particular portion of code, which had previously taken multiple attempts to complete without triggering a freeze.
3. Pressed CTRL+X (cut).

The IDE froze, requiring a forcible termination.

Subsequent to the above, I implemented the solution of configuring the inter-module dependencies and then repeated the above steps. Another freeze.

The attached logs depict both of these freezes.

These freezes slightly differed from those described in the earlier comment in that the earlier one was immediate while these happened after a noticeable delay, long enough for five or six cursor blinks.

[Scott Wells]

Sorry, this weekend was a bit of a lost one for me. Let me take a look at the latest logs/thread dumps. Any chance you could create a standalone project that reproduces this (semi-)reliably? In particular one without any sensitive info that you could share with me. Being able to reproduce this locally will certainly be the best way to get to a full resolution.

[quietopus]

No problem. Had to continue working on that piece of code, but I'll do what I can to isolate the circumstances if the issue re-emerges. Thanks for your help.

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.