Thanks a lot for this information Steven. I learned again something :-)
Cheers,
Till
On Sat, Dec 12, 2020 at 9:02 PM Dan Hill wrote:
> Thanks! That makes sense.
>
> On Sat, Dec 12, 2020 at 11:13 AM Steven Wu wrote:
>
>> This is a performance optimization in JVM when the same exception is
>>
Thanks! That makes sense.
On Sat, Dec 12, 2020 at 11:13 AM Steven Wu wrote:
> This is a performance optimization in JVM when the same exception is
> thrown too frequently. You can set `-XX:-OmitStackTraceInFastThrow` to
> disable the feature. You can typically find the full stack trace in the
This is a performance optimization in JVM when the same exception is
thrown too frequently. You can set `-XX:-OmitStackTraceInFastThrow` to
disable the feature. You can typically find the full stack trace in the log
before the optimization kicks in.
On Sat, Dec 12, 2020 at 2:05 AM Till Rohrmann
Ok, then let's see whether it reoccurs. What you could do is to revert the
fix and check the stack trace again.
Cheers,
Till
On Sat, Dec 12, 2020, 02:16 Dan Hill wrote:
> Hmm, I don't have a good job I can separate for reproduction. I was using
> Table SQL and inserting a long field (which
Hmm, I don't have a good job I can separate for reproduction. I was using
Table SQL and inserting a long field (which was null) into a table that
sinked out to avro. The exception was being thrown from this Avro
function. I can watch to see if it keeps happening.
Hi Dan,
Do you have an example job and some sample data to reproduce this problem?
I couldn't reproduce it locally with a simple example job.
Cheers,
Till
On Thu, Dec 10, 2020 at 5:51 PM Dan Hill wrote:
> Yea, the error makes sense and was an easy fix.
>
> Any idea what happened with the
Yea, the error makes sense and was an easy fix.
Any idea what happened with the hidden stacktrace? The hidden stacktrace
made this 100x more difficult.
On Thu, Dec 10, 2020 at 12:59 AM Flavio Pompermaier
wrote:
> It looks like the problem is that there's a problem in reading a null
> value in
It looks like the problem is that there's a problem in reading a null value
in the AvroRowDataDeserializationSchema (see below for the snippet of code
from Flink 1.11.1).
The problem is due to the fact that there's a bad typing of the source so
the call to createConverter() within the
One of the Exception instances finally reported a stacktrace. I'm not sure
why it's so infrequent.
java.lang.NullPointerException: null
at
org.apache.flink.table.data.GenericRowData.getLong(GenericRowData.java:154)
~[flink-table-blink_2.12-1.11.1.jar:1.11.1]
at
In the Flink dashboard, my job is failing with a NullPointerException but
the Exception is not showing a stack trace. I do not see any
NullPointerExceptions in any of the flink-jobmanager and flink-taskmanager
logs.
Is this a normal issue?
[image: Screen Shot 2020-12-09 at 4.29.30 PM.png]
10 matches
Mail list logo
