SYMPTOMS
Consider the example of a file proxy (file transport) but issue is presumably similar for all polling proxies.
Customer had a file proxy set up to poll for certain files. In the pipeline of the proxy, another proxy service is invoked to check the format of the incoming file. This is done within a transaction. If the file is good, execution completes as expected. If the file is deemed bad, an error is raised. The file proxy executes twice every time an exception is raised, causing undesirable twofold compensatory actions.
Customer had a file proxy set up to poll for certain files. In the pipeline of the proxy, another proxy service is invoked to check the format of the incoming file. This is done within a transaction. If the file is good, execution completes as expected. If the file is deemed bad, an error is raised. The file proxy executes twice every time an exception is raised, causing undesirable twofold compensatory actions.
CAUSE
The polling is done by an MDB (PolledMessageListenerMDBEJB - see "File Transport Provider" under deployments) listening to a dedicated queue, which in the case of the file transport is called:
wlsb.internal.transport.task.queue.file
and lives in the JMS module called: "jmsResources".
This queue has a "Redelivery Limit" parameter (see under "Delivery Failure" tab) which is set to 1 by default .
SOLUTION
If you set this Redelivery Limit to zero, the proxy will always execute once, regardless of whether an exception is raised in the pipeline or not.
Polling proxies in OSB and Event Generators in WLI in most cases are implemented through this kind of architecture, i.e. a message with delayed delivery is put on a dedicated JMS queue. After the allotted polling interval, the message fires an MDB belonging to proxy and a new delayed delivery message is placed on the queue to fire the next polling action. Similar queues for other transports in OSB are:
Polling proxies in OSB and Event Generators in WLI in most cases are implemented through this kind of architecture, i.e. a message with delayed delivery is put on a dedicated JMS queue. After the allotted polling interval, the message fires an MDB belonging to proxy and a new delayed delivery message is placed on the queue to fire the next polling action. Similar queues for other transports in OSB are:
wlsb.internal.transport.task.queue.email
wlsb.internal.transport.task.queue.ftp
wlsb.internal.transport.task.queue.sftp
