[esb-issues] [JBoss JIRA] Updated: (JBESB-1153) File Gateway: verify that it can consume only a single file at a time

[Kevin Conner (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBESB-1153?page=all ]

Kevin Conner updated JBESB-1153:
--------------------------------

    Fix Version/s: 4.x
                       (was: 4.4)

> File Gateway: verify that it can consume only a single file at a time
> ---------------------------------------------------------------------
>
>                 Key: JBESB-1153
>                 URL: http://jira.jboss.com/jira/browse/JBESB-1153
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transports
>    Affects Versions: 4.2
>            Reporter: Burr Sutter
>         Assigned To: Tom Fennelly
>             Fix For: 4.x
>
>
> The current File gateway consumes files at a rate faster than the internal/native listener (typically JMS-based) and its associated action chain.   This request is for a configuration property that causes the rate of consumption of the file gateway to match the underlying internal/native listener.  Basically a file would not be pulled from disk until it has completely passed through the action chain.
> Here are some notes related to this use case:
>         I have 1000+ files which are very huge in size and when all the
> files are kept in the folder they are read at same time and placed in
> configured JMS Queue. 
> - When all the files are placed in Queue there is a chance that the size
> of messages in Queue may exceed and it may not accept new messages? 
> Or
> - Sometimes the case may be like the input folder is monitored by one
> person and the message processing is monitored by other person. In this
> case when all the files are read at once it gives a wrong assumption
> that all files are processed but where as due to some application
> failure the messages may still be in queue.
> Or
> - Its always a good option to be able to see how many messages are still
> in process in the folder rather than browsing the JMS queue and looking
> for Queue depth. In this case if you look at Queue depth sometimes it
> may be give you wrong count of messages as there is a chance that some
> other application also put message some messages into the same queue,
> when Queue is configured for application sharing.
> Or
> - If you want to replace a single file out of 1000+ files in the input
> folder while in middle of processing the files, it will be easy if the
> files are read one at a time rather going and deleting the messages from
> JMS queue after they are read at once and placed in Queue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira