# Java mission control/Client slowdown

**URL:** <https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147>\
**Category:** Ignition\
**Created:** [March 7, 2019, 10:50pm UTC](https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147 "2019-03-07T22:50:20Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![akettner](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@akettner](https://forum.inductiveautomation.com/u/akettner)\
**Post date:** [March 7, 2019, 10:50pm UTC](https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147/1 "2019-03-07T22:50:20Z")

</div>

The first time I posted this was in General Discussion, which might be the wrong place so I will try here.

I have a small Ignition application that has been running fine for about a month, and now things seem to be slowing down over time, as in screen changes taking 4-6 seconds. A restart of the Ignition app seems to speed things up but only for 8-10 hours. The client is doing very little, \<20 client expression tags looking at a UDT, and only updates two SQL records every 5-10 minutes. There are two other very similar applications that are not having any trouble. I have increased the maximum memory to 1024M but still have problems.

I was wondering if JMC might be able to connect to the client and provide some info. I have not been able to connect to the client. Does anyone have any thoughts on using JMC or how to connect to a client, or what might be my client issues?

ALan

---

<div class="post-metadata">

**Author:** ![diat150](https://avatars.discourse-cdn.com/v4/letter/d/a587f6/32.png) [@diat150](https://forum.inductiveautomation.com/u/diat150)\
**Post date:** [March 8, 2019, 1:28am UTC](https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147/2 "2019-03-08T01:28:35Z")

</div>

what is your memory doing? perhaps you have a memory leak?

---

<div class="post-metadata">

**Author:** ![akettner](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@akettner](https://forum.inductiveautomation.com/u/akettner)\
**Post date:** [March 8, 2019, 3:46am UTC](https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147/3 "2019-03-08T03:46:06Z")

</div>

In the diagnostics on the client shows memory any where from 50 to 150 Meg and no other high numbers in the other panels. Compared to other apps it looks normal.

---

<div class="post-metadata">

**Author:** ![akettner](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@akettner](https://forum.inductiveautomation.com/u/akettner)\
**Post date:** [March 8, 2019, 2:42pm UTC](https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147/4 "2019-03-08T14:42:51Z")

</div>

Looking at the client’s task manager the jp2launcher.exe process is using about 240,000K. These numbers seem to match the other running clients. This client does not have a lot of memory, but either do the other clients.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [March 8, 2019, 2:46pm UTC](https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147/5 "2019-03-08T14:46:40Z")

</div>

You might have problems in your scripting or bindings that yield infinite (or near-infinite) loops or recursion. This usually shows up as 100% usage of one core on that client machine, and laggy UI actions.

---

<div class="post-metadata">

**Author:** ![witman](https://avatars.discourse-cdn.com/v4/letter/w/d2c977/32.png) [@witman](https://forum.inductiveautomation.com/u/witman)\
**Post date:** [March 8, 2019, 6:28pm UTC](https://forum.inductiveautomation.com/t/java-mission-control-client-slowdown/23147/6 "2019-03-08T18:28:33Z")

</div>

I’m guessing this isn’t the case, but is something else hogging the CPU cycles? Operators complained to me about Ignition being unresponsive. It turned out they had the computer running a live video viewing program trying to view sixteen full quality streams at once when two streams were enough to peg the CPU at 100%…