Resolution:
Here are more detailed pointers on the related EDI/Edifacs properties and their recommended utilization:

Firstly, the below two parameters should NOT be changed:

edi.inbound.tmpDir
edi.inbound.stepTimeout

Further, when downloading large emails, the memory footprint of the engine can be
hardly improved as the IM email channel keeps a significant portion of th emails in
memory for a while. What may still do is write the to-be-forwarded emails to disk
and prevent BC from sending large emails on the bus:


bc.dmz.email.skipContent._internal_relay_= true
bc.dmz.skipContent.saveLocation= &ltpath_to_the_temporary_location>
bc.dmz.skipContent.threshold= &ltmin_size_to_write_to_file>


Also, the property "bc.ediint.streamsize" can specify the size of the minimum message
that will be written (i.e. streamed) to disk while decrypting/verifying. This can help
processing on the inbound processing context with large payload, utilizing the security
servives.


Then, you should *primarily* consider changing the properties "edi.inbound.xDataStreamSize"
and "edi.inbound.xDataStreamCompressed". See all the descriptions below:


edi.LongRunningJob.ThreadPool.Count: Increasing this value would only increase the
number of XEngine conversions that can occur, but does not decrease memory. It might
actually increase the memory footprint since each thread resource increases memory.
This property also works hand in hand with the IM threadpool (set to 8 in BCMiscProperties.cfg)
that controls the number of active jobs in a BC instance.

edi.inbound.xDataStreamSize:  Decreasing the size from the default value of 50MB would
decrease memory consumption to some extend since the garbage collection in java would
take some time with this high value. When a few extra large emails are processed, you
would be utilizing 50MB in memory per Interchange. This Stream size is per Interchange
and if there are EDI documents received with lots of interchanges each with many transactions,
having a higher value would have the XDatas in memory.


edi.inbound.xDataStreamBuf: Currently, this property value is set to 10000 bytes which
is the amount of memory set for each Xdata. Not much use in increasing the value.


edi.inbound.xDataStreamCompressed: by default the XData is not compressed and has a
value of false. Setting this value to true would have the XData compressed in memory
before it reaches the xDataStreamSize. This would reduce the memory foot print of the
BC Instance.


edi.inbound.xDataMaxNumConsumer: This value limits the number of XDatas that can be
consumed. When processing a single large inbound file with multiple transactions, load
balancing is done when XML data (XData) for each transaction are produced by the validation
and conversion execution thread. XDatas are pushed in queue for consumption by individual
transaction XData subprocesses. The transaction XData subprocess takes care of the db audit
logging, duplicate dectection if enabled, construction of the responder request messages
and publication to the private process. These subprocesses are created and distributed
to multiple engines for processing if necessary but they can only consume as fast as the
validation and conversion execution thread can produce.


Increasing the  edi.inbound.xDataMaxNumConsumer beyond the default value of 100, might
not help if there is only one job request being received and processed that contains
very few interchanges/txns. A higher value would be useful only in the case of a EDI document
that can contain thousands of transactions. It will also increase the backlogs as the
conversion engine is producing fast enough, and the consumption is not fast. It will be
also useful to throttle processing if you receive a lot of EDI documents at the same time.
When selecting a higher value, one should also keep in mind how fast a backend processing
system can process these XDatas.


bc.dmztointerior.cmq.worker.task: Increasing the number of BC Instances thereby load
balancing the EDI loads to multiple instances would decrease the memory footprint of
each BC instance. Controlling this value would also throttle the distribution of EDI
payloads that each instance can handle.

Enabling the checkbox to output the XML to file system by suitably choosing a value of
threshold in the Trading Host-&gtAdvanced Tab in the config GUI would decrease memory to
some extent since each XData will be in disk instead of in memory.

Parameter meaning for some properties in EDI.cfg