Java workloads can seem to be the root cause of performance lags in your JDA RedPrairie WMS. But the answer may be elsewhere
JDA RedPrairie WMS relies heavily on Java for most of its core processing. Sometimes it may appear that Java processes are the cause of performance problems, but it is important to understand what those Java processes are and how they function in JDA WMS.
There are a couple reasons why Java processes would be created. The cause of Java-related performance issues can also vary depending on your software and server setup. One reason you see a Java.exe process is to run MTF Server (2009.1 and later). If you have a multi-warehouse instance, you will see one Java.exe process per Warehouse ID. These processes are responsible for providing connectivity to the RF guns and are important to overall system function, but they do not usually cause performance problems.
MOCA Commands and Java Workloads in JDA WMS
In any release since 2010.1, the core of MOCA uses Java as well. If you have one of these newer versions, you will see one Java process that uses a significant amount of memory and CPU time. This Java process is critical to the operation of your environment and your system will crash if you kill it.
Sometimes it may appear that Java processes are the cause of performance problems, but it is important to understand what those Java processes are and how they function in JDA WMS.
– Paul Patin, Vice President of Technology
Due to its heavy workload, however, this process is also the most likely to look like the “cause” of performance problems. While this process may appear suspicious, the real issue is most likely somewhere else because every MOCA command your system runs will interact with that Java process. If MOCA code or WMS configuration is flawed or inefficient, that Java process will be the system process that shows the performance issue.
The most common culprit we have seen for general Java-based performance problems is insufficient WMS instance heap size. You can configure the Java heap size in the MOCA Registry (MOCA_JAVA_VMARGS Environment Variable up to 2009.2 and VMARGS/VMARGS32 in 2010.1+), but that will only improve things if the real problem is Java memory starvation. If the problem is actually in bad code, database configuration, WMS configuration, server sizing, or anywhere else, then changing the Java heap won’t help much.
We’re Here to Help
If you need assistance getting to the bottom of performance issues, Accelogix’s team can help you identify and resolve the root causes of inadequate system performance. Contact us today to learn how.
- Avoid Common Warehouse Automation Pitfalls by Optimizing Your Processes - August 20, 2021
- How AI & Machine Learning Will Transform Supply Chain Management Through Software-Driven Automation - August 12, 2020
- 5 Shipping Software Implementation Strategies to Minimize Risk - May 28, 2017
- How to Reset a Stuck JDA RedPrairie RF Gun - August 29, 2016
- 5 Ways WMS Can Help Your Mid-Sized Business - October 1, 2015
- Why Mobile Bluetooth Printers Won’t Work with JDA WMS - January 26, 2014
- Is the Java Process Hurting RedPrairie WMS Performance? - January 17, 2014
- RedPrairie WMS Discrete Performance and SQL Server - February 15, 2013
- Printer Management in RedPrairie Discrete WMS - January 29, 2013