The HDFS write operator is partitioned and receive data from another data
generator operator of partitioned running in an other container..
What is the reason for window id getting stuck in 3.2 version.
On Wed, May 10, 2017 at 9:05 PM, Vlad Rozov <v.ro...@datatorrent.com> wrote:
> Is HDFS write operator partitioned? If not, in 3.2 release Apex deploys
> unifier for Nx1 partitioning in a separate upstream container. Check that
> container log.
>
> In any case my recommendation is to upgrade to 3.6.0 that has fix for
> APEXCORE-641.
>
> Thank you,
>
> Vlad
>
> On 5/10/17 02:20, chiranjeevi vasupilli wrote:
>
> The upstream operator processing fine, there are no exceptions and window
> id keep moving.
> Apex version: 3.2.2-incubating-SNAPSHOT
>
> Thanks
> Chiranjeevi V
>
> On Tue, May 9, 2017 at 10:12 PM, Vlad Rozov <v.ro...@datatorrent.com>
> wrote:
>
>> Sorry, I mean upstream. Can you also provide Apex version.
>>
>> Thank you,
>>
>> Vlad
>>
>> On 5/8/17 21:57, chiranjeevi vasupilli wrote:
>>
>> 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 <v.ro...@datatorrent.com>
>> 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 <
>>> chiru....@gmail.com> 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
>>
>>
>>
>
>
> --
> ur's
> chiru
>
>
>
--
ur's
chiru
