I checked, but JVMs didn't crash. No puppet or other services like that.
One thing I found is that things work OK when I have a smaller number of
slaves. For example, here I was trying to run on 16 nodes giving 2 TMs
each. Then I reduced it to 4 nodes each with 2 TMs, which worked.
On Fri, Jul
Hi,
from the TaskManager logs, I can not see anything suspicious.
Its a bit weird that the TaskManager logs just end, without any shutdown
messages. Usually the TMs log some shut down stuff when they are stopping.
Also, if they would be still running, I would expect some error messages
from akka ab
Hi Yukun,
can you also post the code how you are invoking the GenericFlatMapper on
the mailing list?
The Java compiler is usually dropping the generic types during compilation
("type erasure"), that's why we can not infer the types.
On Fri, Jul 8, 2016 at 12:27 PM, Yukun Guo wrote:
> Hi,
> W
Yes Robert is right!
Although it is set only once and not per-operator,
so it looks closer to ingestion time, which is when an
operator enters the pipeline.
Setting the timeCharacteristic to ingestion time
could also be an option, if this is what you want to do.
Kostas
> On Jul 8, 2016, at 11
Hi,
After some debugging we have found that this was actually a problem with 2
of our Kafka brokers which for some reason held invalid metadata for this
specific topic. We are still investigating how this could even happen but
the point is that nothing seems to be wrong with the Flink Kafka produc
Hi,
Guyla and I had some offline discussion about this issue. We'll report here
once we've found the cause.
On Wed, Jul 6, 2016 at 12:01 AM, Gyula Fóra wrote:
> Hi,
>
> I have ran into a strange issue when using the kafka producer.
>
> I got the following exception:
>
> Caused by: java.lang.Ill
Hi,
When I run the code implementing a generic FlatMapFunction, Flink
complained about InvalidTypesException:
public class GenericFlatMapper implements
FlatMapFunction, Tuple2> {
@Override
public void flatMap(SortedMap m, Collector> out) throws Exception {
for (Map.Entry entry : m.
Stephan,
Thank you so much for your advise.
I have modified FlinkKafkaConsumer09 source code and running the job
again. It is working well so far (just a few hours.)
I will keep it running this weekend.
Here is the modification detail.
https://gist.github.com/ogibayashi/e5e72e7d47046cbf46cdc897e4
One thing I would like to add is that your timestamp extractors are not
really extracting the event time from your events. They are just returning
the current system time, which effectively means you are falling back to
processing time.
On Fri, Jul 8, 2016 at 10:32 AM, Kostas Kloudas wrote:
> Ca
This Blog post goes into the direction of what Jamie suggested:
https://techblog.king.com/rbea-scalable-real-time-analytics-king/ The folks
at King developed a system where users can dynamically inject scripts
written in Groovy into a running general-purpose Flink job.
On Thu, 7 Jul 2016 at 20:34
Can it be that when you define the ‘right’ steam, you do not specify a
timestamp extractor?
This is done the same way you do it for the ‘left’ stream.
Kostas
> On Jul 8, 2016, at 6:12 AM, David Olsen wrote:
>
> Changing TimeCharacteristic to EventTime the flink still throws that
> runtime exce
Can you please share all available logs?
On Fri, Jul 8, 2016 at 5:57 AM, Saliya Ekanayake wrote:
> Hi,
>
> I've been trying to run the provided KMeans example on a 16 node cluster. I
> was testing with 2 Task Managers (TM) per node because each node has 2
> sockets (CPUs). A socket contains 12 co
12 matches
Mail list logo
