Looks like a problem with that layout. You could manually rename an "Application Closed" layout that represents your "active" and then try Update Active after making changes.
Laptop only has 8GB RAM - not enough for 10K resources?
8 GB of ram should be sufficient... unless you had all 10K resources open at once. [:D]
It happens regularly with a variety of layouts. Logs always show a "system out of memory exception" when it happens.
The issue isn't likely the number of resources... but what features are you using in the layouts? Any guides? If so, which ones? What else?
Thanks, Dave. It happens regularly with a variety of layouts. Logs always show a "system out of memory exception" when it happens. Maybe a RAM problem? Laptop only has 8GB RAM - not enough for 10K resources?
Can you post a screenshot of one of the layouts it has crashed on?
I've been investigating this problem and have found a memory leak in the Cited By panel for users who have lots of collections. My recommendation (while we investigate this further) would be to rebuild frequently-used layouts without the Cited By tool open.
Just so we're clear, L5 easily handles over a hundred resources open, most linked, along with multiple CitedBys also open and linked, with multiple collections per CitedBy. Coordinated across 5 windows. L5 is impressive.
Most likely a glitch. I usually don't 'defend' the competition but Logos staff under-rating Logos prowess seemed unfair.
Ok, back to Pam's struggle.
Only one of them had the Cited By panel open. One suggestion tech support had when I called Friday was not to check off Parallel Resources on large collections, as these burn up memory. I went through my collections over the weekend and removed all the Parallel Resource check marks so that wasn't the problem this morning. Wondering if having a lot of Visual Filters active is a problem?
The memory leak that I found after trying to reproduce the scenario reported in your logs was quite insidious. If you've ever had the Cited By panel open at all (during the lifetime of the application), it probably has leaked some memory and has contributed to the crash.
I'd have to check on it, but I don't think checking "Show in parallel resources" on a collection would use additional memory. It might slow Logos 5 down, so it could be a performance improvement to uncheck it for non-parallel collections, but I'm not aware of it being a contributor to high memory usage.
Having a lot of visual filters active can use up memory. There were some lines in your log file that potentially indicated that an "expensive" visual filter was being run. However, this tends to indicate that the visual filter (or search) is trading memory usage for increased runtime (so it shouldn't contribute to the crash, but may make Logos 5 run more slowly). If you have a visual filter that uses a very broad wildcard term (e.g., anything involving "*"), you should consider disabling it to see if Logos 5 runs more smoothly without it.
along with multiple CitedBys also open and linked
Thanks for the vote of confidence!
In most cases, having Cited By open isn't a problem. However, if you do have thousands of collections (created explicitly through the Resource Collections panel, or created implicitly through tagging), Cited By can use much more memory than we ever intended. If it's opened and closed repeatedly, or navigated to many different references, it can leak memory that will cause an OutOfMemoryException and crash the app.
This is a bug in Logos 5 that we plan to fix, perhaps in the next release or possibly in a 5.2 Service Release.
