Jiwa

OnJIWA 7.0.175, We are trying to active a 6000 line stock take and find JIWA has used 3,6 GB of memory, before timing out with a memory error.

Per Dev-4297 This behaviour can be overridden by plugins. The JiwaCollection class now has a new property "MultiThreadSave" which is true by default. Plugins can set his to false if needed and the behaviour will be as before this change.

We though this multithreading was chewing up all the memory.

Have you got a sample plugin that will switch the multithread save off, as per the Dev-4297.

Thanks

I do not think forcing multi-thread save to off will help, but I've supplied a plugin for you to try anyway.

The limit you are hitting is imposed by the .NET framework for 32-bit systems.

Are you able to split up the Stock Take? i.e. print or export out the grid data, then create a new stock take. Use the ranges grid to limit the inventory items that appear in the stock take. Re-enter the data and then activate the smaller stock take. Repeat until the full range of parts are covered, but across multiple stock takes. If you don't want to re-key data you could even write a plugin to do this for you.

We erroneously called it Multi-Thread in Dev-4297 , but what it actually is, is asynchronous. The property in the JiwaCollection class is also called AsynchronousSave - it was renamed from to MultiThreadSave to AsynchronousSave a few years ago.

Multi threading and asynchronous are two different beasts.

It is actually possible the default Asynchronous nature of our collection saves would consume more memory resources - and altering that behaviour with the plugin Scott provided may help - but it will be slower.

In simple terms, when AsynchronousSave is true, collections will issue a SQL INSERT or UPDATE or DELETE asynchronously for each item in the collection. By doing so, you''ll see a performance increase over doing that synchronously, especially when the latency between the application and the SQL Server is higher than a few milliseconds. But it also means there are many more .NET SqlCommands running at one time - and they would all consume memory resources.

As developers we thought shouldn't be concerned about how many asynchronous operations occur concurrently - the .NET Framework and operating system are supposed to manage that for us - so I'm keen to see if the plugin Scott provided addresses this, as it will mean we might have issues in other areas of the software with collections saving with many items.

Ernst - let us know if the plugin Scott provided addresses the issue - we can then look at batching SQL updates asynchronously with an upper limit on the number of asynchronous operations per batch to rein in memory usage, and negate the need for the plugin in future versions.

Mike

Hi Guys, Thanks for the help, It was looking promising for about 60 seconds, with CPU at 25% and memory at 100meg, then memory just crept up to 1,GB,2GB, and then eventually out of memory at 3.6GB. We have about 6000 items on the stock take.
See attached, Picture. PS. We have this logged as a bug also.
If you have other suggestion we can try. Please let us know, Have found in the past, If I do a script to delete all the lines where qtyfound=QtySOH, it sometimes goes through, else, I will need to SQL script to move half the changed lines to a new stock take.
Would be good to get a better solution though.
The term and SQL server we are running this on are both 64 bit.

Ernst wrote:PS. We have this logged as a bug also.

We'll deal with it in that system then.