Hi,
Yes, that should work. But suppose first operator rolled back to
previous checkpoint due to some fail over, the state of application would
be reset. Except the part that the 2nd file reader which was not emitting
anything in those windows, now will continue to emit tuples. That will make
the state inconsistent.
May be I can create the link from downstream operator after first reader is
done to handle that.
Thanks,
Isha
On Wed, Dec 2, 2015 at 5:02 PM, Munagala Ramanath <[email protected]>
wrote:
> One way (a bit hacky) is to have the 2nd operator monitor an empty
> directory. Then, when the
> 1st is done reading, it sends a control tuple to a "file-link" operator;
> that operator creates
> symbolic links from the directory monitored by the 2nd operator to the
> actual input files.
> That should then trigger the 2nd input operator to do its thing.
>
> Ram
>
> On Wed, Dec 2, 2015 at 4:43 PM, Isha Arkatkar <[email protected]>
> wrote:
>
> > Hi all,
> >
> > I have an application with 2 input file reader operators. In this
> case,
> > want to trigger start reading from 2nd input location, only after 1st
> > operator is done reading. What is the best way to do this?
> >
> > Thanks!
> > Isha
> >
>
