Aaron, > On 2. 8. 2024, at 2:33, Aaron Rosenzweig <aa...@chatnbike.com> wrote: > How is your RAM headspace? Is it possible you are running out of runway? > Maybe it’s doing lots of garbage collection.
Alas, not probably. I forgot to mention that at the very same time when _some_ R/Rs sport the terrible tens- or even hundreds-second lag, most _other_ ones run concurrently with that and work quite normally (their component-level logged-out awake comes just a couple of millis after the app-level one). Far as I understand Java, it suspends all threads while GCing, so all R/Rs would be affected the same way, would they not? Besides we happen to log the memory state, too, and most time (especially when the worst lag happened) we are well below 20 % of the max available Java memory (-Xmx), which itself is well below the physical RAM. Far as I can say, there was no other memory-consuming task at the same moment (but for FrontBase, I understand there's essentially nothing other of importance running on that machine than the WO app). Thanks a lot! OC > >> On Aug 1, 2024, at 8:32 PM, ocs--- via Webobjects-dev >> <webobjects-dev@lists.apple.com> wrote: >> >> Hi there, >> >> we are encountering another weird problem: a (very) long lag awake-time. >> >> We happen to log the application-level awake and some of the component-level >> awakes. Normally, the latter happen just a couple milliseconds from the >> former. Nevertheless _sometimes_ when the load gets higher and more R/R >> loops run concurrently, this lag grows up to a complete nonsense — tens or, >> in the worst cases, hundreds of seconds (between Application.awake and some >> Component.awake). >> >> The most obvious answer that either the session-level awake or some of the >> non-logged component-level awakes might take an eternity upon a higher load >> is still an open possibility, but quite improbable one: we have profiled our >> application when the problem did happen with a smaller load, a couple of >> times the lag grew up to about 5-7 s, and still none of the awake methods >> ever took more than 40 ms. >> >> Has perhaps anyone here encountered a similar problem and might suggest a >> solution or at least a reasonable way to find the culprit? >> >> Thanks and all the best, >> OC >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >> >> This email sent to aa...@chatnbike.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com