Miles' Blog

通过JMX监控Tomcat/Weblogic|Weblogic/Tomcat/JMX/Monitoring

2008-05-29T00:08:00+08:00

接上篇：wlsmon程序升级为了gui_servmon。主要更新在两个方面：

数据采集上，搞定了tomcat的JMX监控问题。通过打开标准的Java JMX端口，就可以访问到Tomcat注册的MBean，从而获取Tomcat的运行数据，如ThreadPool这个Bean的BusyThreadCount属性；
在界面上进行了优化，加入了淡入淡出效果，以便突出显示重点（最近20s情况）；此外还监听了图例icon的Mouse Event和Key Event，单击icon或使用快捷键（1-9）时仅显示指定数据源的数据，以便对问题数据源进行更清晰的监控。

不废话了，上图：

图1：fade-out效果

图2：突出显示效果

如图，在进行突出显示的时候，会自动关闭fade-out效果。

应该说比上次有了不少进步，尤其是在看不到的代码扩展性方面。

主要参考资料：
http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html

通过JMX监控weblogic服务器Pending Requests|Weblogic/JMX/Monitoring

2008-05-15T22:11:35+08:00

在应用linux服务器后性能和稳定性方面有了比较大的提升。但同时带来的问题就是linux的易用性方面相对差一些，尤其是在系统计数器方面，缺乏GUI的实时监控能力：

图1：windows下的性能计数器

为了解决这个问题，开发了一个小程序，可以用JMX的方式从weblogic服务器中读取当前执行队列的情况，并用图表的方式表现出来：

图2：WlsMon

应该说效果还是不错的。其实还可以更进一步，监控更多细节。只不过时间有限加上比较懒，只能说是“除了想不到，还有做不到”。。

主要参考资料：
http://edocs.bea.com.cn/wls/docs92/jmx/accessWLS.html#wp1114746
http://edocs.bea.com/wls/docs92/wlsmbeanref/core/index.html
第二个文档还是比较详尽的，让我想起了MSDN。

jdk1.5/1.6下xslt时xalan版本问题|xalan version problem in XSLT under jdk1.5(jdk5) & jdk1.6(jdk6)

2007-08-11T13:16:38+08:00

在jdk1.5/1.6下，现有的xslt会失败。

错误类型：TransformerConfigurationException，此外还会有org.jdom.IllegalAddException:A DocType cannot be added after the root element
原因：新版jre中的xalan做了更新，产生了兼容性问题。
解决办法：打包时包括jdom1.0/lib下的xalan.jar。

A permission problem during MRTG intallation|MRTG安装中的权限问题

2007-03-05T14:10:13+08:00

今天给136配置了MRTG服务，用来监控流量。由于安装过太多次，所以整个过程都很顺利。安装到位后启动时出现如下错误：

2007-03-05 13:39:49 -- ERROR: Skipping webupdates because rateup did not return anything sensible
2007-03-05 13:39:49 -- WARNING: rateup died from Signal 0
 with Exit Value 1 when doing router '127.0.0.1_16777219'
 Signal was 0, Returncode was 1
2007-03-05 13:39:49 -- ERROR: Skipping webupdates because rateup did not return anything sensible
2007-03-05 13:39:49 -- WARNING: rateup died from Signal 0
 with Exit Value 1 when doing router '127.0.0.1_16777220'
 Signal was 0, Returncode was 1

上网搜了一下，没有找到贴题的文章，但是看到好几个由于权限问题导致的MRTG错误。所以检查了一下MRTG的output dir，把这个目录的权限设置为Everyone可写，问题解决。看来应该是启动MRTG的帐户对这个目录权限不足造成了写入文件失败。特此记录，一面日后重蹈覆辙。

Web Standards Addictive

2008-07-17T13:57:28+08:00

Web标准真是个好东西，越搞越上瘾，明明是很没逻辑的html，也能写得好像很有逻辑似的，讲起来头头是道。

正在酝酿中的Yup Movie就是完全按照xhtml 1.0 strict标准构建的，在流行的浏览器当中显示效果完美，关掉css以后效果仍然不错。看来通过css隔离内容和显示真的有点道理。可惜那个分离了显示的内容看上去还是不咋纯粹。更让人没法忍受的是始终没法找到TABLE排版的替代方法！

为了这最后1%的完美，花了一大把时间上下求索。直到有一天看到w3.org某页面源码以后长出了一口气。原来用了表格也能追上标准。。

(p.s. hibaidu咋样才能trackback涅？难道靠c-p大法？今天有人trackback了一下我的blog，人生第一次，眼泪哗哗地)

FTP server: the Passive & Port Mode|FTP的主动模式与被动模式

2006-12-25T17:58:34+08:00

ftp服务分主动(PORT)与被动模式(PASV)两种模式。其主要区别是由服务器端还是客户端开启动态端口。前两天刚刚了解过这方面的相关知识，但是没有想到这么快就用上了。

今天去机房给服务器那边配置了防火墙，总体来说算比较顺利，前后2个多小时就搞完收工，中间的网络中断也只有10s左右。最后测试了各项服务，就卡在ftp这里了。

服务器防火墙关闭的情况下：客户端直连网络，则port/pasv都可以正常访问，而客户端通过内网上网，只有pasv可以正常访问；
服务器防火墙开启，仅允许21端口的情况下：客户端直连网络，则port可以正常访问，而客户端通过内网上网，两种模式都无法访问。

又回过头研究了一下ftp的协议规范，确认了主动模式需要客户端开一个>1024的随机端口用于数据传输；而被动模式需要服务器端开启一个>1024的随机端口用于数据传输。而在办公环境下，两端都有防火墙，所以就出现了上述的问题。解决办法有两个：
1.客户端机器设置为DMZ，允许所有连接进入。这样一来，客户端可以任意开端口，主动模式自然也就不在话下；
2.服务器端关闭防火墙。如果这样的话服务器端可以开任意端口，被动模式就没有问题了。

可是如果采用方案一，则对客户端限制太多，对于需要多人、多点维护的服务器环境来说不现实；而如果采用方案二，防火墙岂不是摆设？又baidugoo了一轮，终于找到了折中方案：原来serv-u等ftp server是可以设置pasv模式下使用的端口范围的。这样一来，可以设定一个比较小的范围，然后在防火墙上开一个小口，问题就算解决了。可是为什么ftp协议非要这么BT呢？费解。。。

昨天找到一家不错的陕西餐馆

2006-03-20T16:50:36+08:00

老婆看到二环上有一家陕西餐馆打出了葫芦头和biangbiang面的招牌，想来应该不简单。于是昨天携百忙之中的夫君我一同前往鉴定。

餐馆名曰“食唐”，似乎是新开张，环境还不错，比较干净，桌椅摆放也不拥挤。店堂里面有剪纸和凤翔的彩绘泥塑的陈列，带出几分文化气息。坐定以后服务员拿上菜单，光是看一遍就留下不少口水。米皮面皮夹馍葫芦头biangbiang面腊牛肉一应俱全，很久没有看到这么有冲击力的菜单了！虽然不是很饿，但还是点了一个纯瘦肉夹馍两碗面皮一份精葫芦头和一盘腊牛肉，也就差不多三四个人的量。虽说暴饮暴食不利于身体健康，但是为了完成这次重要的人生体验，再累再苦只当自己是二百五——撑吧，撑死我算了！撑并快乐着！

养儿方知父母恩，吃撑才明白老邢苦。。。饿地肚肚啊。。不过这次体验收获还是不小地，至少以后多了一个忆京城苦思家乡甜的好去处。最后对这次活动评价一下：

环境：4.5分。干净整洁，装修也比较有品位，突出了一下下文化特色。希望能保持下去
服务：3.5分。态度还算不错，但是服务员不是很专业，似乎对流程不很熟悉。素质有待提高
味道：4.5分。算是北京吃过的最正宗的一家了！味道都靠谱就已经很不容易，面皮和以前我们3中校门口的比较像，腊牛肉也有些东新街夜市的风采
消费：如果只是吃特色的话人均20以内（昨天奔六了，不好意思）。在北京应该算是中低档消费。此外人均上20有每人一小杯稠酒送

地址：东二环光明桥北150m路东。有啥公车不清楚，我是靠一双勤劳的脚。

The performance of predefined objects in ASP|ASP内置对象的性能

2006-03-17T16:06:49+08:00

代码片断一：

<%
Dim localArray(5000)
for i = 0 to ubound(localArray)
  randomize
  localArray(i) = rnd()*1000
next

application("tester") = localArray

start = timer
for i = 0 to ubound(application("tester"))
  if application("tester")(i) > 800 then
    application("tester")(i) = 800
  end if
  if application("tester")(i) > 700 then
    application("tester")(i) = 700
  end if
  if application("tester")(i) > 600 then
    application("tester")(i) = 600
  end if
  if application("tester")(i) > 500 then
    application("tester")(i) = 500
  end if
next

response.write formatnumber((timer - start), 2, -1)
%>

代码片断二：

<%
Dim localArray(5000), localArray2
for i = 0 to ubound(localArray)
  randomize
  localArray(i) = rnd()*1000
next

application("tester") = localArray

start = timer
localArray2 = application("tester")

for i = 0 to ubound(localArray2)
  if localArray2(i) > 800 then
    localArray2(i) = 800
  end if
  if localArray2(i) > 700 then
    localArray2(i) = 700
  end if
  if localArray2(i) > 600 then
    localArray2(i) = 600
  end if
  if localArray2(i) > 500 then
    localArray2(i) = 500
  end if
next

response.write formatnumber((timer - start), 2, -1)
%>

猜猜看这两段代码性能差别会有多大？

至少从代码结构上看相差不大。第一段使用application存储数组并直接通过application来使用它；第二段则是将application中存储的数组拿出来做循环。前者应该是过集合方式取得内容，然后拿出来用，所以多了一个遍历集合和方法调用返回的过程。

可是实际每段代码执行3次时间如下：
第一段：9.14s 9.19s 9.91s
第一段：0.03s 0.03s 0.03s
不过5000次循环，可差距远比想象中大得多！而且随着循环次数增加，性能会急剧下降。1000次循环时候第一段不过是0.4s而已，5倍的循环次数就用了20多倍的时间。亲娘咧，真费解啊~~~

原因有时间再探查，结果算是记住了。。。估计request/session也好不到哪里去。

Another way to deadlock | 另类死锁

2005-10-08T17:41:45+08:00

前段时间系统频繁出现死锁。按照目前站点压力来看绝对不正常，但是一直也没有找到原因所在。今天翻代码的时候，无意中发现DBHandler类在open()方法中，从pool获取conn之后执行了conn.setAutoCommit(false);而之后没有任何地方有显式的conn.commit();。因为close时候实际只是把conn送回pool，所以这样一来，唯一的机会就在下次这个conn再被取出并执行conn.setAutoCommit(false);的时候隐式commit了（*根据规范，setAutoCommit()会提交当前所有trans）。

因此，压力越大这个BUG造成的问题就越不突出。因为频繁的访问会使得conn在pool中闲置的时间比较短，也就比较有机会频繁的调用到setAutoCommit();。而这个推测和实际观察结果也是吻合的。

综上，BUG不求多，求精。这一个就够把我整死了。

Get Ip Addr. From The HttpServletRequest Wrapped By The "iisforward" ISAPI Extension In Weblogic | 通过iisforward isapi ext访问weblogic的取ip问题

2005-10-02T12:46:42+08:00

在IIS+Weblogic整合系统中，像移动网关一样，iisforward这个ISAPI过滤器也会对request对象进行再包装，附加一些WLS要用的头信息。这种情况下，直接用request.getRemoteAddr()是无法取到真正的客户IP的。

实际的iisforward附加头如下：

WL-Proxy-Client-IP=211.161.1.239
Proxy-Client-IP=211.161.1.239
X-Forwarded-For=211.161.1.239
WL-Proxy-Client-Keysize=
WL-Proxy-Client-Secretkeysize=
X-WebLogic-Request-ClusterInfo=true
X-WebLogic-KeepAliveSecs=30
X-WebLogic-Force-JVMID=-327089098
WL-Proxy-SSL=false

综上，正确作法如下：

public String getIpAddr(HttpServletRequest request) {
    String ip=request.getHeader("X-Forwarded-For");
    if(ip == null || ip.length() == 0) {
        ip=request.getHeader("Proxy-Client-IP");
    }
    if(ip == null || ip.length() == 0) {
        ip=request.getHeader("WL-Proxy-Client-IP");
    }
    if(ip == null || ip.length() == 0) {
        ip=request.getRemoteAddr();
    }
    return ip;
}

如此一来，就可适应各种情况，包括通过移动网关访问（会附加X-Forwarded-For）。通过这个简单例子可以看出封装和抽象的重要性。