分类目录归档：技术文章

Netty ChannelHandler使用报错

2条回复

最近在研究和学习Netty，按照书上的教程写了一个很简单的demo，但是运行却报错了，代码如下：

package com.fan3cn.netty;

import java.net.InetSocketAddress;

import io.netty.bootstrap.ServerBootstrap;

import io.netty.buffer.ByteBuf;

import io.netty.channel.ChannelFuture;

import io.netty.channel.ChannelFutureListener;

import io.netty.channel.ChannelHandlerContext;

import io.netty.channel.SimpleChannelInboundHandler;

import io.netty.channel.nio.NioEventLoopGroup;

import io.netty.channel.socket.nio.NioServerSocketChannel;

public class TestDemo {

//端口号

private static int port = 7777;

public static void main(String[] args) {

// TODO Auto-generated method stub

TestDemo testDemo = new TestDemo();

testDemo.startup();

}

public void startup(){

ServerBootstrap sb = new ServerBootstrap();

sb.group(new NioEventLoopGroup(), new NioEventLoopGroup());

sb.channel(NioServerSocketChannel.class);

sb.childHandler(new MySimpleChannelInboundHandler());

ChannelFuture future = sb.bind(new InetSocketAddress(port));

future.addListener(new ChannelFutureListener() {

@Override

public void operationComplete(ChannelFuture f) throws Exception {

// TODO Auto-generated method stub

if(f.isSuccess()){

System.out.println("bind success,listening on "+port);

}else{

System.out.println("bind failed");

}

});

}

/**

* handler

* @author Eric

public class MySimpleChannelInboundHandler extends SimpleChannelInboundHandler<ByteBuf>{

@Override

protected void channelRead0(ChannelHandlerContext ctx, ByteBuf data) throws Exception {

// TODO Auto-generated method stub

int readIdx = data.readableBytes();

byte[] bytes = data.readBytes(readIdx).array();

String msg = new String(bytes);

System.out.println("recevied data:\n"+msg);

}

启动好了之后，浏览器输入：http://127.0.0.1:7777?x=1&y=2 ,但是令人奇怪的是这个服务器只能接受一次请求，后面的请求均会产生如下的报错：

Oct 24, 2016 9:52:41 PM io.netty.channel.DefaultChannelPipeline$TailHandler exceptionCaught

WARNING: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.

io.netty.channel.ChannelPipelineException: com.fan3cn.netty.TestDemo$MySimpleChannelInboundHandler is not a @Sharable handler, so can't be added or removed multiple times.

at io.netty.channel.DefaultChannelPipeline.checkMultiplicity(DefaultChannelPipeline.java:461)

at io.netty.channel.DefaultChannelPipeline.addLast0(DefaultChannelPipeline.java:138)

at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:131)

at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:258)

at io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:245)

at io.netty.bootstrap.ServerBootstrap$ServerBootstrapAcceptor.channelRead(ServerBootstrap.java:232)

at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:372)

at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:357)

at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)

at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:87)

at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)

at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)

at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)

at java.lang.Thread.run(Thread.java:745)

按照报错的提示，原因就是这个channelHandler没有使用@Shareable注解，加上之后果然问题解决了。但是到这里我的疑问并没有得到解决，为什么这个handler必须要加上@Shareable注解？这一步步到底是怎么回事？经过几次断点，再结合阅读源码，总算是搞清楚为什么了。
首先来看抛出异常的方法DefaultChannelPipeline->checkMultiplicity，代码如下：

private static void checkMultiplicity(ChannelHandlerContext ctx) {

ChannelHandler handler = ctx.handler();

if (handler instanceof ChannelHandlerAdapter) {

ChannelHandlerAdapter h = (ChannelHandlerAdapter) handler;

if (!h.isSharable() && h.added) {

throw new ChannelPipelineException(

h.getClass().getName() +

" is not a @Sharable handler, so can't be added or removed multiple times.");

}

h.added = true;

}

这段代码很简单，如果这个handler被加过了，也就是h.adder=true，并且不是[……]

继续阅读

java进程coredump（二）

发表评论

上篇介绍了如何生成一个Java进程的coredump，今天则来总结下当Java进程挂掉之后应该怎么样一步一步来分析。

一、Fatal Error Log
接着昨天的例子继续看，在coredump之后目录里面的文件是这样的：

1 2	[xxxx@VM_72_32_tlinux ~/fanyy]$ ls core.23687 CoreDumpTest.class CoreDumpTest.h CoreDumpTest.java crash.c crash.so hs_err_pid23687.log

一般情况下当Java进程挂掉之后，在程序目录下面会生成一个错误日志：hs_err_pidxxxx.log。这个文件是你排查问题的过程中第一个应该阅读的日志，因为这个文件里面会记录很多有用的信息，比如：线程堆栈，堆的使用情况，JVM参数和环境变量，虚拟机状态，操作系统信息等。这里提供的信息非常多，也非常全面，为我们大致定位问题提供了很大的帮助。
先来看下文件开头的注释信息，这里的信息很粗略地指出了崩溃的原因：

# A fatal error has been detected by the Java Runtime Environment:

# SIGSEGV (0xb) at pc=0x00007f37956cd554, pid=23687, tid=139881182439168

# JRE version: 6.0_22-b04

# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode linux-amd64 )

# Problematic frame:

# C [crash.so+0x554] Java_CoreDumpTest_crash+0x18

# If you would like to submit a bug report, please visit:

# http://java.sun.com/webapps/bugreport/crash.jsp

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

第8,9行指出了出现问题的栈是在动态库crash.so的Java_CoreDumpTest_crash方法。接下来看下具体的堆栈信息：

Stack: [0x00007f38a020a000,0x00007f38a030b000], sp=0x00007f38a0309850, free space=3fe0000000000000018k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C [crash.so+0x554] Java_CoreDumpTest_crash+0x18

j CoreDumpTest.crash()V+0

j CoreDumpTest.main([Ljava/lang/String;)V+7

v ~StubRoutines::call_stub

V [libjvm.so+0x3e75fd]

V [libjvm.so+0x5f6fe9]

V [libjvm.so+0x3e7435]

V [libjvm.so+0x4206d1]

V [libjvm.so+0x40eb50]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j CoreDumpTest.crash()V+0

j CoreDumpTest.main([Ljava/lang/String;)V+7

v ~StubRoutines::call_stub

继续阅读

java进程coredump（一）

1条回复

上篇文章介绍了coredump的基本知识以及gdb调试core文件的相关操作，这篇文章主要介绍如何生成Java进程的coredump，也就是说如何写一段java代码使它被操作系统kill掉。我们都知道因为jvm的存在，java层面的代码无论你怎么写都是不太可能crash的，顶多是OOM或者stackoverflow，然而这些都会被jvm捕捉并抛出异常，而不是被操作系统直接kill掉。所以如果一个java进程crash掉，那肯定是挂在native code上了（当然JVM本身的bug就另说了），因此思路就是通过java的JNI（java native interface）调用本地方法，使进程挂掉。具体步骤如下：

1.编写java代码，调用本地方法

public class CoreDumpTest {

//native关键字修饰的方法是对本地方法的声明，具体实现由本地方法完成

public native void crash();

static {

//静态方法，载入本地动态库。load方法载入的是绝对路径下面的库

//也可以使用loadLibrary,调用的是"java.library.path"下面的库

//这个方法需要把生成的动态库加到目录里面，比较麻烦，我这边就直接使用绝对路径了。

System.load("/home/fanyy/crash.so");

}

public static void main(String[] args) {

new CoreDumpTest().crash();

}

2.编译，生成.class文件

1	javac CoreDumpTest.java

3.生成头文件：CoreDumpTest.h

1	javah CoreDumpTest

该文件的内容如下：
[cr[……]

继续阅读

core文件的生成和调试

发表评论

上一篇文章匆忙地记录了一次分析core文件报错的过程，今天则花点时间来认真总结下Linux下core文件的开启，生成，调试，以及堆栈定位。

一、什么是core文件？
进程在运行时可能会因为各种各样的原因（后面会细说）崩溃，而在崩溃前的一瞬间操作系统会像拍照片一样生成一个core文件，这个文件记录了程序运行时的状态，主要包括内存信息，堆栈指针，寄存器状态等，生成core文件的这一过程俗称为coredump。开发人员可以通过对core文件的分析来排查，定位问题，找到程序崩溃的原因。

二、core文件设置

a).如何开启

ulimit -c

这条命令输出的是允许生产core文件的最大size，如果是0则表示你没有开启coredump，如果是unlimited则表示不限制大小。所以如果要开启coredump，只需要输入：

1	ulimit -c unlimited

其中，unlimited可以换成具体的数字，比如1024（单位是KB）。

b).文件名及目录
默认设置下，
1.core文件是[……]

继续阅读

Can’t attach to the core file

发表评论

今天在使用jsadebugd调试core文件的时候又报错了：
Error attaching to core file or starting server: sun.jvm.hotspot.debugger.DebuggerException: Can’t attach to the core file
堆栈如下：

$ jsadebugd java core.48296 TempServer

Attaching to core core.48296 from executable java and starting RMI services, please wait...

Error attaching to core file or starting server: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the core file

at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)

at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:276)

at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:604)

at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:565)

at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:338)

at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:313)

at sun.jvm.hotspot.HotSpotAgent.startServer(HotSpotAgent.java:249)

at sun.jvm.hotspot.DebugServer.run(DebugServer.java:110)

at sun.jvm.hotspot.DebugServer.main(DebugServer.java:45)

at sun.jvm.hotspot.jdi.SADebugServer.main(SADebugServer.java:55)

之前碰到这个报错的时候甚至去看了jdk的源码，但还是一无所获。今天灵光一现，通过分析和不断尝试，大致可以总结出有以下几个原因：
1.core文件损坏

2.调试的command不正确，这个工具的使用格式是这样的：

1	jsadebugd executable core [ server-id ]

executable必须是java的全路径，而不能是java。
所以这样使用是会报错的：

1	jsadebugd java core.48296 TempServer

正确的使用方式是：

1	jsadebugd /usr/local/jdk/jre/bin/java core.28225 TempServer

3.调试用的jdk版本和当时出core的jdk版本[……]

继续阅读

永远的热河路

A man can be destroyed but Not Defeated.

分类目录归档：技术文章

Netty ChannelHandler使用报错

java进程coredump（二）

java进程coredump（一）

core文件的生成和调试

Can’t attach to the core file