Hotfix 10: Memory optimization and management

  • 16 February 2021
  • 0 replies
  • 11 views

 

Hotfix 10: Memory optimization and management

KB000676

PRODUCT
K2.net 2003
LEGACY/ARCHIVED CONTENT
This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.

 

K2.net 2003 Hotfix 10 contains various enhancements as far as memory usage is concerned

 

 

In cooperation with Microsoft consultants specializing in memory optimization and management, K2.net 2003 Hotfix 10 contains various enhancements as far as memory usage is concerned.

It is important to note that the K2.net 2003 workflow server engine, apart from enforcing the core business process logical flow, executes custom developed code behind Events, Activities and various types of Rules.

These include but are not limited to: Client Events, Server Events, Preceeding Rules, Start Rules, Escalation Rules, Destination Rules, Succeeding Rules and Line Rules.

The K2.net 2003 Server component has no control over the memory management of the custom code executing behind these artifacts.

It is therefore imperative for the developer of these code blocks to enforce best coding practises as far as memory management is concerned.

This will include things like Disposing of Objects, Closing of Connections and using String Builders to implement String concatenation.

 

 

Implementation

This Hotfix is only applicable to and intended for K2.net 2003 SP4.  Please follow the steps below for implementation:

Step 1

Stop the K2 Server Service(s)

Step 2

Run the following scripts against the K2 (transaction) database:

a.            kIPCAsync.sql

b.            kIPCFetchStart.sql

c.            kIPCRemoveStart.sql

d.            kIPCReturnSave.sql

e.            kIPCSendFinish.sql

Step 3

Make backups of the existing files in your environment by copying them to a different location (only the files which will be replaced by this hotfix) from the [install directory]Bin folder. The list of files include:

a.            K2Server.exe

b.            ADUM.dll

c.            K2CSC.dll

d.            K2ROM.dll

e.            K2STXH.dll

f.            KO.dll

g.            SourceCode.Logging.dll

Step 4

Replace the existing files with the files contained within the archive.

Step 5

If any custom applications are used (also intended for the K2.net 2003 Workspace), the K2ROM and any other K2 assemblies referenced by these applications will also need to be backed up and replaced.

Step 6

If the K2 Service Manager is installed on separate machines, the K2CSC and ADUM dlls on these machines will also have to be backed up and replaced.

Step 7

Start the K2 Server Service(s) again.

 

 

Enhancements

Release of AppDomains

Description: The K2 Server will now unload AppDomains if no activity on any ProcessInstance within that AppDomain has occurred for a period of 15 minutes.  Default time period is 15 minutes but this value is configurable.

Implementation: For Logging purposes, to see when AppDomains are being unloaded either in the console or in a log file, add the following line to the file:  Logger.config  (located in [InstallDir]Bin)

  <configuration>

    <MessageList>

      <Message MsgID="7122" Severity="Info" Category="1">Unloading AppDomain for Proc:{0}({1})</Message>

    </MessageList>

  </configuration>

To configure the time period after which an AppDomain should be unloaded, add the following line to the file:  K2Server.config  (located in [InstallDir]Bin)

  <K2Server>

    <AppDomainUnload Minutes="15" />

  </K2Server>

It is important to note that a validation check for activity on an AppDomain is executed every 10 minutes.  Setting the ‘AppDomainUnload’ flag to 15 minutes  does not mean that an inactive AppDomain will be released exactly 15 minutes after the last interaction with a ProcessInstance within an AppDomain. This can take anything from 15 to 25 minutes.

Impact: K2 Server memory should decline during off-peak hours – provided that all activity for ProcessInstances within an AppDomain have completed for a period longer than 15 minutes.

Threading Improvements

Description: The threading system inside of K2 Server has been improved.

Implementation: Apart from changes within KO.dll, the following SQL scripts should be executed against the K2 (transaction) database:

kIPCAsync.sql

kIPCFetchStart.sql

kIPCRemoveStart.sql

kIPCReturnSave.sql

kIPCSendFinish.sql

Impact: Less threading contention and objects are locked for less time.

Multiple-Open Connections

Description: A memory leak occurred when the Open() method was called more than once on a Connection object.  Connections will now automatically close the connection if Open() is called twice.

Impact: A small amount of memory growth if the connections are opened twice should now be negated.

Pre-allocated Memory for Worklist Queries

Description: The K2 Server uses a heuristic to allocate a byte array for serializing worklist query results. Previously it grew at 4096 bytes each time it was depleted.

Impact: Less heap fragmentation in memory.

String Intern User Names

Description: Previously, User Names were duplicated in memory.  Interning strings means that duplicates are prevented.

Impact: Fewer duplicated user name strings in memory.

Freed Objects During Deserialization

Description: A byte array was being allocated and pinned for deserialization. It was not being unpinned when it was no longer in use.

Impact: A small amount of memory for each connection is freed.

ADUM Memory Leaks

Description: Previously undisposed objects are now disposed within ADUM.

Impact: Unmanaged memory is freed for certain ADUM calls.

ADUM String Buffer Usage

Description: ADUM was allocating too much temporary space for Win32 API calls that used strings. This has been rectified by first querying how much space is actually needed.

Impact: Large temporary strings are no longer allocated.

String Manipulation (Logger)

Description: A large number of temporary strings pertaining to the logging framework was left in memory. This has been amended.

Impact: A large amount of temporary strings in memory should now be cleared.

Releasing of Remoting Objects

Description: Objects in memory were kept alive when they were deserialized from network data, especially when working with Data/XML Fields.

Impact: A memory leak each time a call was made to the server.

 


0 replies

Be the first to reply!

Reply