SmartApp Latency issues?

[tgauchat (ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)]

@jrivera

The others seem to just stop in their tracks and never execute (live logs). It’s as if the server gets locked up and can’t execute more than one at a time.

If I do one manually and wait about 30 seconds for each hub the requests go through without a problem.

Any ideas on if this is related to the smart app issues currently?

There are some very serious performance issues right now, so I’d say this is highly likely the cause of any sudden change in behavior.

What you described seems perfectly reasonable; however, multiple SmartApps instances do share the same JVMs (to the best of my knowledge) … and for good reason … and I think there is some effort underway to make this even more prevalent in order to optimize resource utilization.

Perhaps it is having unintended side effects like the wait/blocking you notice.

Trying to think of who to tag… @vlad?

Reference:

SmartApp Caching update

Not quite - there is only one JVM in play per Scheduler node. The actual executions are sandboxed within that JVM. That hasn’t changed. Think of it like this: User A & B both have a community SmartApp. The code for the SmartApp is the exact same, meaning that the code gets compiled into the same Class. Previously we would create 2 Classes (One for each user) - each taking up its own memory. Now when user B executes (given that user A already did) when we look up the SmartApp to execute in the cache, we see that there is already a SmartApp with the same checksum in the cache (aka the code is the same) so instead of creating a new class for user B we just reuse the one that was created for user A. GC comes into the picture when we multiple this situation by thousands or tens of thousands o…