In the killed container we have one writer operator to HDFS and default Unifier. The writer operator receives data from other upstream operators(32 partitions) running in a separate containers. There is no functional processing happening in the blocked operators.
There is no downstream operators. Please suggest. On Mon, May 8, 2017 at 8:58 PM, Vlad Rozov <[email protected]> wrote: > The exception below means that a downstream operator abruptly > disconnected. It is not an indication of a problem by itself. Please check > downstream operator container log for exceptions and error messages. > > Thank you, > > Vlad > > On 5/8/17 07:12, Pramod Immaneni wrote: > > Hi Chiranjeevi, > > I am assuming the operator that is upstream and feeding data to this one > is progressing properly. What is this operator doing? Is it doing any > blocking operations, for example, communicating with some external systems > in a blocking fashion? Do you see any other exceptions before the above one > you mentioned? > > Thanks > > On Mon, May 8, 2017 at 3:41 AM, chiranjeevi vasupilli <[email protected] > > wrote: > >> Hi Team, >> >> In my use case , one of the operator window id got stuck and after >> timeout it is getting killed. >> In the logs we can see >> [ProcessWideEventLoop] ERROR netlet.AbstractLengthPrependerClient >> handleException - Disconnecting >> Subscriber{id=tcp://hostname:57968/323.rsnOutput.1} >> because of an exception. >> java.io.IOException: Connection reset by peer >> at sun.nio.ch.FileDispatcherImpl.read0(Native Method). >> >> Before container getting , we see the above exception in the logs. >> >> Please suggest , reasons for window id getting stuck and how to debug it >> further. >> >> Thanks >> Chiranjeevi V >> > > > -- ur's chiru
