Bhupesh Chawda commented on APEXMALHAR-2284:

As far as I understand, the issue is with race conditions involved in 
simultaneous get() and put() on a store based on managed state.
For the join use case, asynchronous get() is important for efficiency reasons.

Upon some discussion with Chaitanya, here are the possible options:
1. Make all get() and put() calls blocking. That way the issue is avoided at 
the cost of decreased throughput.
2. Allow an option to specify the source (Bucket.ReadSource).
3  All data inserted by the put() call is stored in a separate space and 
synched with managed state at end window. This ensures that put() does not 
interfere with asynchronous get() calls. This is similar to the way 
SpillableArrayListMultimap works, but which cannot be used directly as it lacks 
some functionality like asynchronous get.
4. Override the getAsync() method to achieve the desired functionality.

> POJOInnerJoinOperatorTest fails in Travis CI
> --------------------------------------------
>                 Key: APEXMALHAR-2284
>                 URL: https://issues.apache.org/jira/browse/APEXMALHAR-2284
>             Project: Apache Apex Malhar
>          Issue Type: Bug
>            Reporter: Thomas Weise
>            Assignee: Chaitanya
>            Priority: Blocker
>             Fix For: 3.6.0
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/166322754/log.txt
> {code}
> Failed tests: 
>   POJOInnerJoinOperatorTest.testEmitMultipleTuplesFromStream2:337 Number of 
> tuple emitted  expected:<2> but was:<4>
>   POJOInnerJoinOperatorTest.testInnerJoinOperator:184 Number of tuple emitted 
>  expected:<1> but was:<2>
>   POJOInnerJoinOperatorTest.testMultipleValues:236 Number of tuple emitted  
> expected:<2> but was:<3>
>   POJOInnerJoinOperatorTest.testUpdateStream1Values:292 Number of tuple 
> emitted  expected:<1> but was:<2>
> {code}

This message was sent by Atlassian JIRA

Reply via email to