Hi, I cannot see the CI detail as I click the link.
It was like:
[cid:image001.png@01D0CF8B.60774F60]
Does anyone help me?
fangfengbin created FLINK-2486:
--
Summary: Remove unwanted null check in removeInstance function
Key: FLINK-2486
URL: https://issues.apache.org/jira/browse/FLINK-2486
Project: Flink
Issue Type: B
Henry Saputra created FLINK-2485:
Summary: Handle removal of Java Unsafe in Java9
Key: FLINK-2485
URL: https://issues.apache.org/jira/browse/FLINK-2485
Project: Flink
Issue Type: Task
I've also seen the BufferSpillerTest fail:
https://travis-ci.org/apache/flink/jobs/74057503
On Tue, 4 Aug 2015 at 14:10 Robert Metzger wrote:
> I've assigned https://issues.apache.org/jira/browse/FLINK-1680 to myself.
> Maybe Tachyon 0.7 will fix the issues.
>
> On Tue, Aug 4, 2015 at 1:57 PM,
Stephan Ewen created FLINK-2484:
---
Summary: BarrierBuffer does not properly clean up temp files
Key: FLINK-2484
URL: https://issues.apache.org/jira/browse/FLINK-2484
Project: Flink
Issue Type: B
I set parallelism of map to 4 (and I double checked, that the 4 mappers
are running on different machines). Furthermore, fromElements() source
has parallelism of 1. Thus, some data is going over the network for sure.
On 08/04/2015 02:31 PM, Chesnay Schepler wrote:
> i think this job would be chai
i think this job would be chained completely and never do any serialization.
On 04.08.2015 14:25, Matthias J. Sax wrote:
Works for batch job, too. See enclosed.
On 08/04/2015 01:34 PM, Matthias J. Sax wrote:
Yes, that is was the program does. However, streaming is not lazy so
deserialization s
Works for batch job, too. See enclosed.
On 08/04/2015 01:34 PM, Matthias J. Sax wrote:
> Yes, that is was the program does. However, streaming is not lazy so
> deserialization should have happened.
>
> I will try a batch job, later today.
>
> On 08/04/2015 01:27 PM, Chesnay Schepler wrote:
>> so
fangfengbin created FLINK-2483:
--
Summary: Add default branch of switch(scheduleMode) in
scheduleForExecution function
Key: FLINK-2483
URL: https://issues.apache.org/jira/browse/FLINK-2483
Project: Flink
I've assigned https://issues.apache.org/jira/browse/FLINK-1680 to myself.
Maybe Tachyon 0.7 will fix the issues.
On Tue, Aug 4, 2015 at 1:57 PM, Stephan Ewen wrote:
> Yes.
>
> We should know, though, whether this is a Java 6 bug, or a bug in our
> system that just happens to occur only with Java
Márton Balassi created FLINK-2482:
-
Summary: Document sreaming processing guarantees
Key: FLINK-2482
URL: https://issues.apache.org/jira/browse/FLINK-2482
Project: Flink
Issue Type: Bug
Márton Balassi created FLINK-2481:
-
Summary: Test at least once processing guarantee for streaming
Key: FLINK-2481
URL: https://issues.apache.org/jira/browse/FLINK-2481
Project: Flink
Issue T
Yes.
We should know, though, whether this is a Java 6 bug, or a bug in our
system that just happens to occur only with Java 6 (because of different
timings in this other engine)
On Tue, Aug 4, 2015 at 12:27 PM, Chesnay Schepler <
chesnay.schep...@fu-berlin.de> wrote:
> Aren't we dropping java 6
Yes, that is was the program does. However, streaming is not lazy so
deserialization should have happened.
I will try a batch job, later today.
On 08/04/2015 01:27 PM, Chesnay Schepler wrote:
> so I'm not to much into the streaming API, but as i see it this program
> creates an infinite number of
Yes, that is was the program does. However, streaming is not lazy so
deserialization should have happened.
I will try a batch job, later today.
On 08/04/2015 01:27 PM, Chesnay Schepler wrote:
> so I'm not to much into the streaming API, but as i see it this program
> creates an infinite number of
Yes, that is was the program does. However, streaming is not lazy so
deserialization should have happened.
I will try a batch job, later today.
On 08/04/2015 01:27 PM, Chesnay Schepler wrote:
> so I'm not to much into the streaming API, but as i see it this program
> creates an infinite number of
I think in the Streaming Case it works because every Serializer ends up
being wrapped up in a StreamRecordSerializer. When the
StreamRecordSerializer serializes/deserializes stuff it should be ok that
the Tuple0 doesn't actually serialize/deserialize anything.
On Tue, 4 Aug 2015 at 13:27 Chesnay S
so I'm not to much into the streaming API, but as i see it this program
creates an infinite number of tuples and then counts them, right?
The problem with serialization as i understand it is that the receiver
can't tell how many Tuple0 are sent, since you never actually read any
data when dese
Huang Wei created FLINK-2480:
Summary: Improving tests coverage for
org.apache.flink.streaming.api
Key: FLINK-2480
URL: https://issues.apache.org/jira/browse/FLINK-2480
Project: Flink
Issue Type
Hi,
I just opened a PR for this. https://github.com/apache/flink/pull/983
However, I was not able to "reproduce" serialization issues... I tested
Tuple0 (see enclosed code) in a cluster, and the program worked. Do I
miss anything?
-Matthias
On 08/03/2015 01:01 AM, Matthias J. Sax wrote:
> Tha
Aren't we dropping java 6 support?
On 04.08.2015 12:21, Stephan Ewen wrote:
The "StateCheckpointedITCase" has not failed so far, which also test these
guarantees thoroughly.
But we need to first rule out the BarrierBuffer. The problem is that the
bug occur only on Java 6 and cannot be reproduce
The "StateCheckpointedITCase" has not failed so far, which also test these
guarantees thoroughly.
But we need to first rule out the BarrierBuffer. The problem is that the
bug occur only on Java 6 and cannot be reproduced locally...
On Tue, Aug 4, 2015 at 12:14 PM, Gyula Fóra wrote:
> Honestly I
Honestly I don't think the partitioned state changes have anything to do
with the stability, only the reworked test case, which now test proper
exactly-once which was missing before.
Stephan Ewen ezt írta (időpont: 2015. aug. 4., K, 12:12):
> Yes, the build stability is super serious right now.
Yes, the build stability is super serious right now.
Here are the problems in question, and what we could do about this:
BarrierBuffer:
Barrier Buffer tests fail in Java 6 builds.
I have not found a way to diagnose that problem, yet, but if we cannot find
the issue today,
I've also seen this fail: https://travis-ci.org/apache/flink/jobs/74025862
in SuccessAfterNetworkBuffersFailureITCase
Build seems quite flaky recently.
On Tue, 4 Aug 2015 at 10:27 Matthias J. Sax
wrote:
> Rebased on:
>
>
> https://github.com/mjsax/flink/commit/fab61a1954ff1554448e826e1d273689e
Ricky Pogalz created FLINK-2479:
---
Summary: Refactoring of
org.apache.flink.runtime.operators.testutils.TestData class
Key: FLINK-2479
URL: https://issues.apache.org/jira/browse/FLINK-2479
Project: Flink
Rebased on:
https://github.com/mjsax/flink/commit/fab61a1954ff1554448e826e1d273689ed520fc3
But if the gap between two rebases is large, it's hard to say what the
problem might be...
The old parent commit (ie, rebase before last rebase) was
https://github.com/mjsax/flink/commit/148395bcd81a93bcb1
27 matches
Mail list logo
