JMS outbound adapter - delete original message

[arungn]

how to delete the original file/message once its delivered to a JMS queue. I have got file:inbound to read and transform / validate then finally uses jms:outbound to deliver to a jms queue.

For all sucessfuly delivery I need to delete the original file/message from the inbound folder?

any thoughts pls ?

Thanks

[Mark Fisher]

What is it that you are actually delivering in the body of the JMS Message?

The reason I ask is that the payload of the Spring Integration Message when using file:inbound-channel-adapter is just a java.io.File object. In other words, it's a pointer to a file and nothing more. Are you reading that as bytes or String and then passing that to the JMS outbound adapter?

[arungn]

I am converting the file as a string

[oleg.zhurakousky]

For all sucessfuly delivery I need to delete the original file/message from the inbound folder?

What constitutes a successful delivery in your environment? The fact that the message was sent to JMS? or that the Message was acknowledged by the consumer on some reply destination?

[Mark Fisher]

If you are using the "file-to-string-transformer" element, then you can also provide the "delete-files" attribute with a value of "true". In that case, it would delete the File immediately after reading it into a String. There is a danger of losing the File and its content, however, if the JMS publish fails.

[arungn]

as far as the application is concerned the message is read, validated and delivered to the end point queue - means success.

In my dev env (windows) I have local mq/manger running and have been testing to see the flow working (namespace based) -

steps i did so far.

1. read file inbound adapter into a direct channel
2. run through - file name validation and some transformation using couple of direct channels
3. finally, outbound jms adapter to send the message as its without any payload conversion to string etc.

That is working. but original file remain in the folder.

I couldnt find a delete option straight so I hv configured, for testing as of now, a file outbound adapter to write to a processed folder with delete source option enabled - kind of move. that is working locally.

[arungn]

:-)

with a final file:outbound adapter moving file to the process folder the message is not delivered. that am sure is because the file pointer you have mentioned before.

[arungn]

mark

what is the best way to go ahead if i wanted to move the file to a processed folder once its delivered successfully.?

thanks

[Mark Fisher]

I think the "best way" to handle this type of requirement would be to have the file operations as part of the transaction such that your move (or delete, or whatever action you want to take) would be triggered only if the JMS publisher's transaction commits.

The problem of course is that the File operations are not themselves transactional. However, Spring does provide support for registering a TransactionSynchronization. That can be done statically via TransactionSynchronizationManager. For example, you could register an action to occur only onCommit(), and that would then be applied if the JMS transaction commits.

We have considered adding such a hook directly into Spring Integration, and I have a prototype that I just refreshed with your particular use-case. The basic idea would be to include either a "synchronization" attribute on our <transactional> sub-element (within the <poller> of the inbound-channel-adapter) or to provide simpler callback reference attributes (to Runnable instances), such as "on-commit" and "on-rollback". The reason we have not yet provided this functionality is that there are a few caveats:
1) only truly useful for simple cases with a single transactional resource and a single non-transactional resource
2) most useful actions to be triggered would require some context (e.g. in this case, the File instance)
3) only applicable in the original thread's transactional context (as with anything depending on a transactional scope, this might create confusion)

All that said, I still think it's worth pursuing something along those lines for 2.1 or beyond. In the meantime, maybe you can also experiment with a TransactionSynchronization based approach.

Otherwise, moving to the intermediate directory would prevent the same File from being read again, and then you can schedule a periodic purger for that intermediate directory. The main challenge is how to keep certain Files around if they were being processed when the JMS publisher's transaction failed.