NOTICE: Branded Content
NOTICE: Certain versions of content (“Material”) accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.
SMA Idea Exchange
cancel

Redesign Connect IT application to use 64-bit architecture

Currently Connect it uses 32-bit architecture which sets a certain limitations on memory which can be allocated to CIT process.

As CIT is a 32-bit software program, the memory a CIT process can use is limited to approximately 2 GB. In order to protect a CIT process from crashing, it checks every request to memory allocation. If a CIT process uses up the available memory, it would not be able to process the data and would throw out-of-memory error in the CIT log. There is a common issue when CIT is working with large files, then scenario stops with the out-of-memory error because the memory is used up. For example such issue was investigated in defects QCCR1E141645 and QCCR1E144507, most of memory was consumed by big attachments (> 50 MB). The bottom line is memory footprint of an attachment is much larger than its file size. It depends on how attachments are handled in a CIT scenario. Therefore, currently custom CIT scenario should be designed in a manner taking into account memory footprint of big attachments.

Adding up, for 2GB program, on Windows around 1GB memory is OS protected memory, so actually 32-bit application can only use around 1GB memory. And on CIT side , the attachment needs to get Unicode encoding first, so it has size increase at this step. Then, when attachment from source connector to mapping, then to destination connector, there’re several rounds of copy operation for the Unicode version attachment, so the duplicated Unicode objects exists in the application, which increase the memory again. For the Java connector (and most CIT connectors are written on Java), it consume lot of memory already, so when all these iterations happen, CIT can't get OS to allocate more memory. At this moment, the CIT memory protection mechanism is triggered to throw error popup windows to suspend the CIT process. Although there is a room for optimization of memory usage in current CIT engine, the more robust solution will be to redesign CIT to use 64-bit architecture.

4 Comments
Micro Focus Expert
Status changed to: New Idea

Ditto for Service Manager. 

New Member.

I support this sentence

Respected Contributor.
Status changed to: Waiting for Votes

Thanx for your submission. this idea is opened for comment and additional votes.  

please provide your votes, thoughts, or other considerations.

 

thanx 

Acclaimed Contributor..
I support rewriting the CIT architecture to support 64 bit.