That's absolutely no problem Tzu-Li. Either of them would work. Thank you!
On Thu, Apr 19, 2018 at 4:56 PM Tzu-Li (Gordon) Tai
wrote:
> @Alexander
> Sorry about that, that would be my mistake. I’ll close FLINK-9204 as a
> duplicate and leave my thoughts on FLINK-9155.
@Alexander
Sorry about that, that would be my mistake. I’ll close FLINK-9204 as a
duplicate and leave my thoughts on FLINK-9155. Thanks for pointing out!
On 19 April 2018 at 2:00:51 AM, Elias Levy (fearsome.lucid...@gmail.com) wrote:
Either proposal would work. In the later case, at a minimum
Either proposal would work. In the later case, at a minimum we'd need a
way to identify the source within the metric. The basic error metric would
then allow us to go into the logs to determine the cause of the error, as
we already record the message causing trouble in the log.
On Mon, Apr 16,
offset of the corrupted message for further investigation.
Looks like the only option is to write messages into a log file
On Fri, Apr 6, 2018 at 9:12 PM Elias Levy <fearsome.lucid...@gmail.com> wrote:
I was wondering how are folks tracking deserialization errors. The
AbstractDeseriali
@gmail.com>
> wrote:
>
>> I was wondering how are folks tracking deserialization errors. The
>> AbstractDeserializationSchema
>> interface provides no mechanism for the deserializer to instantiate a
>> metric counter, and "deserialize" must return a null in
:
> I was wondering how are folks tracking deserialization errors.
> The AbstractDeserializationSchema interface provides no mechanism for the
> deserializer to instantiate a metric counter, and "deserialize" must return
> a null instead of raising an exception in case of
I was wondering how are folks tracking deserialization errors.
The AbstractDeserializationSchema interface provides no mechanism for the
deserializer to instantiate a metric counter, and "deserialize" must return
a null instead of raising an exception in case of error if you wan