NOT AwareIM issue but WTF?

kklosson

The is the startAwareIM.bat file, right?

kklosson

This could be key. I had it set at 1024 in V6 and did not update the setting when I went to V7. Giving it a shot...

BenHayat

Yes Sir... You really need it in V7.

BenHayat

I had recently been reading up on GC (garbage collection) of Java and .Net, which both release "disposed memory by app". .Net version 1.x had a huge time delay releasing this memory. As of recent versions, .Net had become more responsive to give back memory to OS. In Java, it uses a different technique to give back memory to OS. It tries to use it internally before giving it back it back to OS, more like a cache memory. But this delay can cause problem for servers sometimes when then need memory. In our case Aware server (as service) can suffer low heap memory which is vital.
The 64-bit give us the ability to expose more memory to Aware at runtime, so even if Java GC doesn't immediately release memory, Aware has enough allocation to work with.
This was my understanding from reading different materials.

kklosson

The issue continues. After about 20 minutes, the app seems to slow, only in their session. They report that simple things, like clicking into a text box for typing, and the cursor is slow and unresponsive and they can't even highlight text without some sluggishness. So I just don't know what to make of it. This is all since V7. However, when I installed V7, I opted to stay with the 32 bit just to get a performance baseline. I provide AwareIM and Tomcat 1024m each. In the task manager, neither ever gets above 600m. I run as a service so the memory settings are set in the following files:

awareim\bin\awareim.conf:

Initial Java Heap Size (in MB)

wrapper.java.initmemory=500

Maximum Java Heap Size (in MB)

wrapper.java.maxmemory=1024

awareim\bin\tomcat.conf:

Initial Java Heap Size (in MB)

#wrapper.java.initmemory=3

Maximum Java Heap Size (in MB)

#wrapper.java.maxmemory=64

awareim\tomcat\conf\wrapper.conf:

Initial Java Heap Size (in MB)

#wrapper.java.initmemory=500

Maximum Java Heap Size (in MB)

#wrapper.java.maxmemory=1024

I'm a little unclear on which of these files are actually necessary so if you can shed light on that please do. All other recommendations are welcome.

BenHayat

I have run into the exact thing you're talking about with this site
https://directnic.com/

After a few search it starts getting slower and slower to the point you can't even type anymore. The only solution is to hit F5 and will snap back again.
While getting slow, when I look at task manager, I see FF memory and CPU is increasing more and more. So something in the client JS is just eating up more resources until refresh.

Who knows, maybe one of Kendo's widgets is eating up too much memory.

johntalbott

They report that simple things, like clicking into a text box for typing, and the cursor is slow and unresponsive and they can't even highlight text without some sluggishness.

I agree with Ben. Based on the above, this appears to be a client-side (JS code loaded in the browser) issue. If that is the case, server-side configuration is irrelevant.

What has to happen for the user to get back to normal performance ... close the browser and start over? Or can the user just refresh the browser?

kklosson

Yes. They log out/in and performance returns to normal.

BenHayat

johntalbott wrote
What has to happen for the user to get back to normal performance ... close the browser and start over? Or can the user just refresh the browser?

I'm pretty sure a refresh (F5) will do. I tested it today. Closing browser will clear more memory than refresh.
That was in FireFox

I also run into the same issue with SquareSpace Web editor in Chrome. I have to press F5 routinely or it gets slow.

Tell user, as soon as it gets a bit slow press F5 and they don't need to logout.

johntalbott

Right ... I was wonder if refreshing would be enough.

Is this happening in all browser flavors and/or versions?

Here is an interesting blog post regarding a memory leak in the Kendo grid. This guy was using an older version of the library, so this could be fixed by now. But possibly not.
http://scottsjewels.blogspot.com/2013/03/javascript-memory-leaks-and-kendo-grid.html

Here is a very recent article that in the Kendo UI Update section mentions a fix going in for an IE specific memory leak
https://dzone.com/articles/tips-for-becoming-a-javascript-dev

I have no idea if these specific memory leaks are related to your issue, but they are things to consider.

BenHayat

Kingsley, could you also ask your user to try F5 when it's slow?

If the F5 doesn't solve it, then it's your session memory getting large and that goes to server side. But if F5 solves it, then it's browser memory.
Note: Logout almost does the same thing as F5, because it kills Aware client side. So testing F5 is vial here. Let's keep our finger crossed that F5 fixes it.

Please keep us in the loop, because we're getting close... 😃

kklosson

F5 fixes it (at least in one case) but this does log the user out. So to the user, it's the same as having to log out/in. This simply should not be the new normal.

BenHayat

kklosson wrote
F5 fixes it (at least in one case) but this does log the user out. So to the user, it's the same as having to log out/in. This simply should not be the new normal.

I use F5 all day in Aware apps during testing and never logs me out... Huh!

If F5 fixes it, then it's really a browser memory issue and not Aware's server. I see Browser memory in intensive apps, i.e, the complex editor that SquareSpaces provides it's customer to create web pages with drag & Drop. I have to do F5 every 2 to 3 minutes or after every save, to stay fast.

« Previous Page