Hi Wenxing,
You can check all the attached core dumps yourself. All of them (even
the three from 14/Dec/18) have the following lines:
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build
1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode
linux-amd64 compressed oops)
...meaning, they are all result of running an old JDK 8. No core dumps
with newest JDK 8...
Regards, Peter
On 1/13/19 11:20 AM, wenxing zheng wrote:
Hi Ismael,
Do you mean the ticket: https://issues.apache.org/jira/browse/KAFKA-7625.
If so, from the description, it seemed even upgrading latest version of JDK
8, there were 3 core dumps. Isn't it?
Kind Regards, Wenxing
On Sun, Jan 13, 2019 at 1:14 AM Ismael Juma <ism...@juma.me.uk> wrote:
It's been explained that this is a bug in the JDK and updating to the
latest release of Java 8 fixes it.
Ismael
On Thu, Jan 10, 2019 at 6:46 PM Ankur Rana <ankur.r...@getfareye.com>
wrote:
But G1GC is the default garbage collection algo used in kafka, it'll
still
be using G1GC.
Did you add remove/add other parameters as well?
Also, which kafka version are you using?
On Fri, Jan 11, 2019 at 2:34 AM wenxing zheng <wenxing.zh...@gmail.com>
wrote:
Previously we added G1GC option to the JVM options when starting the
Kafka, and now we remove this option and it works fine up to now.
On 2019/01/08 07:58:01, Car Devops <cardev...@gmail.com> wrote:
Hi folks :)
Can you please Wenxing comfirm that removing G1GC really solved the
problem.
Unfortunately I faced that issue last night.
And what do you mean by " remove the G1GC"? How did you do that?
Thanks!
-----Original Message-----
From: wenxing zheng [mailto:wenxing.zh...@gmail.com]
Sent: 28 grudnia 2018 04:05
To: Peter Levart <peter.lev...@gmail.com>
Cc: users@kafka.apache.org
Subject: Re: SIGSEGV (0xb) on TransactionCoordinator
Hi Peter, we didn't upgrade the JDK8, but just remove the G1GC. And
now
it
seemed stable, but we need to keep monitoring the status to finally
confirm.
Kind Regards, Wenxing
On Thu, Dec 27, 2018 at 9:43 PM Peter Levart <peter.lev...@gmail.com
wrote:
Here's a report on the Jira with exactly the same crash and the
reported was using the same JDK 8u92...
https://issues.apache.org/jira/browse/KAFKA-7625
...the reporter upgraded to latest JDK 8 and it seems to be stable
since then.
Regards, Peter
On 12/27/18 11:29 AM, wenxing zheng wrote:
Thanks to Peter.
We did a lot of tests today, and found that the issue will happen
after enabling G1GC. If we go with default settings, everything
looks
fine.
On Thu, Dec 27, 2018 at 4:49 PM Peter Levart
<peter.lev...@gmail.com>
wrote:
Hi,
It looks like a JVM bug. If I were you, 1st thing I'd do is
upgrading the JDK to the latest JDK8u192. You're using JDK8u92
which is quite old (2+ years)...
Regards, Peter
On 12/27/18 3:53 AM, wenxing zheng wrote:
Dear all,
We got a coredump with the following info last night, on this
environment,
we enable the
transaction. Please kindly advice what would be the problem
here.
#
# A fatal error has been detected by the Java Runtime
Environment:
#
# SIGSEGV (0xb) at pc=0x00007f546a857d0d, pid=13288,
tid=0x00007f53701f9700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14)
(build
1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed
mode
linux-amd64 compressed oops)
# Problematic frame:
# J 9563 C1
*kafka.coordinator.transaction.TransactionCoordinator.$anonfun$handleE
ndTransaction$7(Lkafka/coordinator/transaction/TransactionCoordinator;
Ljava/lang/String;JSLorg/apache/kafka/common/requests/TransactionResul
t;Lkafka/coordinator/transaction/TransactionMetadata;)Lscala/util/Eith
er;
(518 bytes) @ 0x00007f546a857d0d [0x00007f546a856b40+0x11cd]*
#
#
Failed to write core dump. Core dumps have been disabled. To
enable
core
dumping, try "ulimit -c unlimited" before starting Java again
#
#
If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
--------------- T H R E A D --------------- Current thread
(0x00007f547a29e800): JavaThread
"kafka-request-handler-5"
daemon [_thread_in_Java, id=13722,
stack(0x00007f53700f9000,0x00007f53701fa000)]
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR),
si_addr:
0x00000000dd310c13
Registers:
RAX=0x0000000000000001, RBX=0x00000006e9072fc8,
RCX=0x0000000000000688,
RDX=0x000000075e026fc0
RSP=0x00007f53701f7f00, RBP=0x00000006e98861f8,
RSI=0x00007f53771a4238,
RDI=0x00000006e9886098
R8 =0x000000000000132d, R9 =0x00000000dd310c13,
R10=0x00000007c010bbb0,
R11=0x00000000dd310c13
R12=0x0000000000000000, R13=0x00000000dd310b3d,
R14=0x00000000dd310c0c,
R15=0x00007f547a29e800
RIP=0x00007f546a857d0d, EFLAGS=0x0000000000010202,
CSGSFS=0x002b000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Thanks,
--
Thanks,
Ankur Rana
Software Developer
FarEye
