用技术创造价值,用艺术塑造自我!
Posts tagged rmi
Spring的同集群内的远程调用的3种方法
Jul 26th
服务分离的方式有时候显得很高深,总是觉得API的方式不那么靠谱,所以,玩玩远程调用来让系统显得性感一点。性感的装扮有多种,总得找个适合自己的玩 法,虽然本人不善打扮,对打扮系统的方法还是知道那么几个滴。Spring做了远程调用的封装,为了假装自己不是一个轮子的重复制造者,还是让系统在 Sping框架上实现了。
Spring的远程调用大概有以下几种:RMI,HttpInvoker,Hessian,Burlap,JAX RPC,JAX-WS,JMS,Jetty+Servlet 。偶只玩过RMI,HttpInvoker,JMS。其他几种也是听说了下。当然,同集群内的的服务,用 RMI,HttpInvoker,Jetty+Servlet都是较好选择(限本人了解的情况)。
Spring RMI:
推荐你去看文档了解具体的配置细节,这种玩法的优点是:在远程启动服务后,你可以像调用本地bean一样调用远程的bean,如果考虑下安全问题加一个 taken或密钥,简单,实用,满足同集群的多数需求。
Spring HttpInvoker:
继续去看文档吧!这个需要依赖HttpClient包,有个依赖,总是觉得不爽,而且在web.xml中也需要配置相关的servlet的信息,所以总是 感觉有点麻烦,然后还需要在远程调用的时候返回做相关的bean,能用,不够简洁。
Spring + Jetty:
Ya!这个不是我想出来的,这样玩只是孙*的建议。启动Spring的时候,就能把相关的servlet服务暴露出去。当然,返回的就是 HttpServlet了,没有你渴望的bean,我有点忽悠你了,可是如果返回一个流行的json,是不是也算玩远程调用了。玩嘛……
首先你还是需要到jetty的官网上去下载个jetty来,把lib/jetty-6.1.24.jar,jetty-util- 6.1.24.jar,servlet-api-2.5-20081211.jar加入到你的工程的编译目录下面,如果你用maven的话,在 pom.xml配置一下:
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty</artifactId>
<version>6.1.24</version>
</dependency>
建一个servlet,简单的如下:
private static final long serialVersionUID = 1347334624L;
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String name = request.getParameter("name");
if (name != null) {
name = new String(name.getBytes("ISO-88590-1"),"utf-8");
} else {
name = "longhao";
}
PrintWriter out;
String title = "HelloWorld";
response.setContentType("text/html;charset=GB2312");
out = response.getWriter();
out.print("<html><head><title>" + title + "</title>");
out.print("</head><body>");
out.println("<h1><p> Hello " + name + "</p></h1>");
out.print("</body></html>");
out.close();
}
}
然后配置一把spring的xml,把相关的配置信息加上去。
- <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean name="WebServer" class="org.mortbay.jetty.Server"
init-method="start">
<property name="connectors">
<list>
<bean name="LocalSocket" class="org.mortbay.jetty.nio.SelectChannelConnector">
<property name="host" value="localhost" />
<property name="port" value="8080" />
</bean>
</list>
</property>
<property name="handlers">
<list>
<bean class="org.mortbay.jetty.servlet.Context">
<property name="contextPath" value="/" />
<property name="sessionHandler">
<bean class="org.mortbay.jetty.servlet.SessionHandler" />
</property>
<property name="resourceBase" value="d:/jetty" />
<property name="servletHandler">
<bean class="org.mortbay.jetty.servlet.ServletHandler">
<property name="servlets"> <!– servlet definition –>
<list>
<!– default servlet –>
<bean class="org.mortbay.jetty.servlet.ServletHolder">
<property name="name" value="DefaultServlet" />
<property name="servlet">
<bean class="org.mortbay.jetty.servlet.DefaultServlet" />
</property>
<property name="initParameters">
<map>
<entry key="resourceBase" value="d:/jetty" />
</map>
</property>
</bean>
<bean class="org.mortbay.jetty.servlet.ServletHolder">
<property name="name" value="HelloWorldServlet" />
<property name="servlet">
<bean class="com.longtask.spring.HelloWorldServlet" />
</property>
<property name="initParameters">
<map>
<entry key="resourceBase" value="d:/jetty" />
</map>
</property>
</bean>
</list>
</property>
<property name="servletMappings">
<list><!– servlet mapping –>
<bean class="org.mortbay.jetty.servlet.ServletMapping">
<property name="pathSpecs">
<list>
<value>/</value>
</list>
</property>
<property name="servletName" value="DefaultServlet" />
</bean>
<bean class="org.mortbay.jetty.servlet.ServletMapping">
<property name="pathSpecs">
<list>
<value>/hello</value>
</list>
</property>
<property name="servletName" value="HelloWorldServlet" />
</bean>
</list>
</property>
</bean>
</property>
</bean>
<!– log handler –>
<bean class="org.mortbay.jetty.handler.RequestLogHandler">
<property name="requestLog">
<bean class="org.mortbay.jetty.NCSARequestLog">
<property name="append" value="true" />
<property name="filename" value="d:/jetty/log/request.log.yyyy_mm_dd" />
<property name="extended" value="true" />
<property name="retainDays" value="999" />
<property name="filenameDateFormat" value="yyyy-MM-dd" />
</bean>
</property>
</bean>
</list>
</property>
</bean>
</beans>
打开你的浏览器,输入:http://localhost:8080/hello ,恭喜,看到了hello longhao 。什么原因,你懂滴!
由于个人不太喜欢用HttpInvoker的方式调用,所以推荐的排序是:RMI > Jetty + Servlet > HttpInvoker。环肥燕瘦啊!如果你的爱好不同,请低调的告诉我,保持低调。
序列化:serializable,hessian,protobuf性能对比
May 28th
分布式应用系统中,系统之间的通讯的质量决定了系统的可用性,当然很多可以选择的技术:XML-RPC,RMI,SOAP,CORBA,JMS,EJB,NIO等。在传输数据的过程中,数据包越小,占用的带宽就越少,同等条件下资源利用就会越小。目前基于SOA的ESB系统中,很多采用NIO来传输数据,就涉及到对象的序列化的问题。
本文主要讨论jdk自带序列化,hessian,Google的protobuf之间的性能比较,主要指标有以下三个:(执行序列化测试1次;1个数据对象,100个,1000个)
- 序列化文件大小
- 序列化的读取读取性能
- 序列化的平均写入性能
性能指标结果(纵坐标为耗时)
.jpg)
文件大小:hessian最小,传输带宽方面占有优势。
.jpg)
写操作:写操作在大批量的时候,protobuf比hessian和jdk有优势。

读操作:读取方面protobuf仍然占有优势,但是总体上来书,hessian和protobuf差距不大。
性能外的问题:
1:易用性:hessian比protobuf使用起来要简单的多,google需要预先生成一个*.proto文件,使用的时候需要依赖它的build接口,和GAE中的web.py的模板文件一样,预处理真是方便的框架,并没有让用户觉得爽。这方面hessian占优势。
2:学习成本:老牌hessian在java平台上广结良缘,文档和FAQ相当齐全,学习成本相对较低。google搜索protobuf google显示21.1W条,而hessian java却有54.4W条。
3:跨平台:hessian支持的语言:java,c++,python,php,erlang,ruby等,主要是针对java平台的,C++版本是05年的和python版本是07年的,更新都较慢;protobuf这块做的就比较好,如果系统中需要不同语言的就选择protobuf了,单java语言的还是选择hessian比较好。
其他方面的知识:
二进制协议比基于xml协议(Burlap和apache XML-RPC)的效率要高的多(ORMI的HTTP隧道启用除外),XML-RPC经过测试无论是文件大小和速度都没有优势。
Java多线程的监控分析工具(VisualVM)
Mar 11th
在java多线程程序运行时,多数情况下我们不知道到底发生了什么,只有出了错误的日志的时候,我们才知道原来代码中有死锁。撇开代码检查工具,我们先讨论一下利用VisualVM监控,分析我们的多线程的运行情况。(注:实践本文内容的JDK的版本需要1.6.07以上)
什么是VisualVM

VisualVM是JDK的一个集成的分析工具,自从JDK 6 Update 7以后已经作为Sun的JDK的一部分。
VisualVM可以做的:监控应用程序的性能和内存占用情况、监控应用程序的线程、进行线程转储(Thread Dump)或堆转储(Heap Dump)、跟踪内存泄漏、监控垃圾回收器、执行内存和CPU分析,保存快照以便脱机分析应用程序;同时它还支持在MBeans上进行浏览和操作。尽管 VisualVM自身要在JDK6以上的运行,但是JDK1.4以上版本的程序它都能被它监控。
在JDK1.6.07以上的版本中:到$JAVA_HOME/bin,点击jvisualvm.exe图标就可以启动VisualVM;当然也可以点击这里获取官方的最新版本,支持:英文,中文,日文。
VisualVM功能集成较多,我们这里只讨论它对象线程的监控分析。
VisualVM监控线程
当我们运行VisualVM的时候,可以在应用程序》本地中看到VisualVM和eclipse的运行程序,然后我们启动eclipse中的一个线程:com.longtask.thread.TestVisualVm,可以看到在菜单中多了一个该线程的显示。点击右边的 线程 菜单,可以看到线程运行的跟踪情况。

点击 thread dump,可以生成该线程的运行情况的tdump文件,通过thread dump提供的相关信息,我们可以看到线程在什么地方被阻塞了以及线程的其他状态。

把日志另存为文件,到Thread Dump Analyzer的主页点击
图标下载TDA,然后用TDA打开刚才VisualVM保存的 thread dump文件,查看相关的分析结果。

我们也可以用VisualVM来监控远程java线程的运行情况。
远程监控:启动RMI服务
1:新建一个jstatd.all.policy文件,在里面添加以下内容来保证jstatd服务启动的时候不报异常:
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
2:netstat -ano | grep -i 1099 查看1099端口是否被占用了,如果被占用,则需要选择其他端口来启动jstatd服务
3:如果端口被占用,用以下方式启动jstatd服务:
rmiregistry 2020 & jstatd -J-Djava.security.policy=jstatd.all.policy -p 2020
更多jstatd的文档请参考sun公司的官方文档 这里
远程监控Jboos服务

1:修改JDK下面的jmx的配置文件:
切换至$JAVA_HOME所在目录/jre/lib/management下,
I:将jmxremote.access、jmxremote.password.template权限调整为读写:
#cp jmxremote.password.template jmxremote.password
#chmod 600 jmxremote.password
#chmod 600 jmxremote.access
II:vi jmxremote.password去掉
# monitorRole QED
# controlRole R&D
的#号
2:在Jboss的启动文件中添加以下信息:
JAVA_OPTS="-Dcom.sun.management.jmxremote.port=2899 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Djava.rmi.server.hostname=10.212.20.9 其他配置"
3:检查启动情况:
netstat -a | grep -i 2899 查看端口占有情况
如果2899端口被其他程序占用,在jboss配置文件中调整端口-Dcom.sun.management.jmxremote.port=****
而后在VisualVM中就添加远程连接,选择jmx方式,就可以监控jboss的运行情况了。
参考文档:
