By Antony Reynolds on Jun 13, 2008
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 ProblemBy 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 FeedingSo 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 WSDLTo 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
- 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
<part name="PhoneRecords" element="imp1:PhoneRecords"/>
<part name="PhoneRecords" type="xsd:string"/>
<binding name="Read_binding" type="tns:Read_ptt">
<jca:header message="hdr:InboundHeader_msg" part="inboundHeader"/>
Modifying the BPEL ProcessHaving 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 FileManipulation.zip 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 ScenariosThe 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 SequentiallyWe 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 ThreadsThe 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/pc.properties. To alter the number of threads change the following property:
Processing Files in Date OrderAnother 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 10.1.3.1 via a patch but it should also be available at some point in 10.1.3.3 and later releases.
Final ThoughtsThe 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.