Throttling Files

Throttling Files

I'm sure everyone has been tempted to grab a file by the throat and squeeze it until it departs for that great filing cabinet in the sky, but that is something to discuss quietly with your psychiatrist.  In this entry I would like to investigate how to limit the concurrency of file handling procedures.

A Concurrency Problem

By default the interaction with the file adapter is a one way interaction.  The file adapter posts a message into the queue for a process and then carries on about its business.  This is good because it allows multiple files, or multiple batches from a single file to be processed concurrently.  However if there are a large number of concurrent processes started then this can cause performance problems as the process manager starts to worry about which process to execute when.  One sympton of this is undelivered messages visible on the BPEL console.

This is bad because it means we are feeding BPEL process manager faster than it can consume, and so it gags a little and throughput is reduced as it gags.

Stopping Force Feeding

So how do we tell the file adapter that BPELs mouth is full and please wait until I have eaten this bit.  Well the answer is in the observation that interactions with the file adapter are usually one way.  They do not need to be!  It is possible to modify the WSDL generated by the file adapter wizard to support a two way interaction.  This causes the file adapter thread to wait until the reply before sending another message.  For the reasons why changing from a one-way to a two-way interaction causes this behaviour look at my earlier entry on BPEL threading.  The answer is left as an exercise to the reader.

Changing the File Adapter WSDL

To change the one-way interaction to a two-way interaction we do the following in the generated WSDL file:
  • Make sure that the definitions root element has a namespace reference to XML schema by adding the following
    • xmlns:xsd=""
  • Add a dummy message that will be used in a reply.
    • <message name="Dummy_msg">
          <part name="PhoneRecords" type="xsd:string"/>
  • Add a reply to the read operation
    • <output message="tns:Dummy_msg"/>
  • Add a reply to the binding
    • <output/>
This gives a file like the one below
    <message name="PhoneRecords_msg">
        <part name="PhoneRecords" element="imp1:PhoneRecords"/>
    <message name="Dummy_msg">
        <part name="PhoneRecords" type="xsd:string"/>
    <portType name="Read_ptt">
        <operation name="Read">
            <input message="tns:PhoneRecords_msg"/>
            <output message="tns:Dummy_msg"/>
    <binding name="Read_binding" type="tns:Read_ptt">
    <pc:inbound_binding  />
        <operation name="Read">
          OpaqueSchema="false" >
        <jca:header message="hdr:InboundHeader_msg" part="inboundHeader"/>

Modifying the BPEL Process

Having modified the WSDL we must modify the BPEL to now do a reply.  The reply will release the file handling thread in the adapter to do further work.  The modified process is available as project BigBatchProcess1.2 in the file.  Details of using this process can be found in an earlier entry on batch processing of files.  Note that there is an additional test file included in the src directory - phonebook2.csv - that has 5000 records in it to give a larger test case.

Other Scenarios

The above scenario is not the only one where we may wish to use a two-way interaction with the file adapter.  The following additional scenarios may also occur.

Reading a File Sequentially

We may need to process a file in strict record order yet still want to have it batched because it is a large file.  In this case the problem is that we may have multiple batches submitted concurrently and there is no guarantee of the order that they will be processed in.  In this case just making the interaction two-way is not enough because there may be more than one file processing thread.

Controlling the Number of File Processing Threads

The number of threads used to process files in the file adapter is controlled by a setting in the file $ORACLE_HOME/bpel/system/services/config/  To alter the number of threads change the following property:
  • oracle.tip.adapter.file.numProcessorThreads=1
Note that this is a global setting and so may impact other file activation agents that have been configured in the system.  The net result of this is to limit file processing to a single thread.  Hence by using a single thread and a two-way interaction we can single thread the file processing and so guarantee processing of records in order in a file.

Processing Files in Date Order

Another scenario where these techniques are applied is when there is a requirement to process files in order of last modification date, for example when later files may contain reversing transactions for earlier files.  This can currently only be achieved in via a patch but it should also be available at some point in and later releases.

Final Thoughts

The use of two-way interactions and limiting threads processing files is very powerful but it needs to be considered in the context of other file interactions in the system.  One way to limit the impact is to use singleton processes to receive the processing requests, enabling messages to be queued in order, releasing the file processing threads for other processes to use whilst still ensuring correct ordering in the required processes.
Hope this helped.


Post a Comment:
Comments are closed for this entry.

Musings on Fusion Middleware and SOA Picture of Antony Antony works with customers across the US and Canada in implementing SOA and other Fusion Middleware solutions. Antony is the co-author of the SOA Suite 11g Developers Cookbook, the SOA Suite 11g Developers Guide and the SOA Suite Developers Guide.


« July 2016