If you’ve ever spent hours allocating a 40K line wave or waited restlessly looking at the hour glass for your picks to get cancelled, you are not alone. One way to tackle this is to take advantage of the multi-threading capabilities that the new MOCA architecture supports in JDA WMS (formerly RedPrairie).
With the introduction of next generation MOCA (i.e. MOCAng ), some core WMS functionalities like allocation and release that are still implemented in legacy C code became sluggishly slow. This is mainly due to MOCA now being Java-based; native C components incur overhead from communicating back and forth with MOCA processes when trying to invoke SQL or other C components. As a result, we witness a general slowdown in components like allocation and pick release where the majority of code is still in C. The good news is that the new Java-based architecture of MOCA supports multi-threading, and with the right approach there is great opportunity for performance enhancement.
One area to take advantage of multi-threading is allocation. Success of this approach has led product to include the feature in its 2012 release. Basically, instead of having one single-threaded process going through all shipment lines for a wave and allocating them one by one, we split these lines into multiple temporary waves, so each is processed by a separate thread within the MOCA server process. The key to success here is to split the wave in a manner that minimizes contention between threads. One logical way to split the lines is by part number where we ensure that allocation threads are not competing for the same piece of inventory. We have witnessed impressive results with this approach; in some cases where allocation was taking over 1.5 hours to process our 40K wave, we managed to reduce it to under 10 minutes.
Allocation is not the only place where multi-threading can be beneficial. Although an exception case, “Pick Cancellation” is an activity that can be very time-consuming using the standard WMS approach. If we look at a trace of pick cancellation, we see that standard logic basically serializes cancellation of picks one after the other and performs rollbacks when errors occur. A better approach would be to take advantage of the deferred execution mechanism in conjunction with multi-threading to achieve speed up.
Basically, instead of cancelling the picks inline, we create deferred execution records for each cancellation and a set of background thread jobs. These threads will poll the table and look for records to cancel. Again, the key here is to ensure that there is a minimum number of contention points between thread jobs. To control this, we can use a Key Value field within the deferred records to hash the record into threads where no two threads are trying to cancel the same set of picks. We again witnessed remarkable improvement in performance using this approach, where we were able to cancel 40K picks in fewer than 20 minutes.
Taking advantage of the multi-threading capabilities of new MOCA architecture is by no means limited to the cases described above. We have successfully used it to improve performance of integrator transaction processing, archiving and much more. However, there are a couple of caveats that are worth outlining:
Contention: in general, as we increase the number of processing threads, we increase the opportunity for contention between threads. We usually need to identify the contention points and take measures to resolve them if possible. But keep in mind that the law of “diminishing returns” applies and after a certain point adding threads will not produce any more gains.
Concurrency Issues: If concurrency issues still exist in standard WMS code, then a multi-threading approach will magnify them big time. The code that works correctly 99.95% of the time now is being concurrently invoked by many threads, so the likelihood of the 0.05% happening becomes much higher.
Hardware Limitations: When trying to determine how many threads to use, we need to take into consideration available hardware, including the number of CPUs and memory.
Fine-tuning MOCA Parameters: Some of the parameters that we need to adjust to support multi-threading include: Native process pool, database connections and maximum heap size for Java virtual machine.
The next generation of MOCA provides exciting opportunities to improve WMS performance and take better advantage of your hardware server capabilities. With the right approach, you can take an advantage of both and increase your ROI.
To discover more ways to help enhance JDA WMS performance, download our business brief entitled "Five Musts to Maximizing Your JDA Performance". Click on the link below to retrieve your free paper: