李哲

一、总结前一天的学习 从“第三天”的性能测试一节中，我们得知了决定性能测试的几个重要指标，它们是： ü 吞吐量 ü Responsetime ü Cpuload ü MemoryUsage 我 们也在第三天的学习中对Apache做过了一定的优化，使其最优化上述4大核心指标的读数，那么我们的Apache调优了，我们的Tomcat也作些相应 的调整，当完成今的课程后，到时你的“小猫”到时真的会“飞”起来的，所以请用心看完，这篇文章一方面用来向那位曾写过“Tomcat如何承受1000个 用户”的作都的敬，一方面又是这篇原文的一个扩展，因为在把原文的知识用到相关的两个大工程中去后解决了： 1) 承受更大并发用户数 2) 取得了良好的性能与改善（系统平均性能提升达20倍，极端一个交易达80倍）。 另外值的一提的是，我们当时工程里用的“小猫”是跑在32位机下的， 也就是我们的JVM最大受到2GB内存的限制，都已经跑成“飞”了。。。。。。如果在64位机下跑这头“小猫”。。。。。。大家可想而知，会得到什么样的效果呢？下面就请请详细的设置吧！ 二、一切基于JVM（内存）的优化 2.1 32位操作系统与64位操作系统中JVM的对比 我们一般的开发人员，基本用的是都是32位的Windows系统，这就导致了一个严重的问题即：32位windows系统对内存限制，下面先来看一个比较的表格： 操作系统

一、总结前一天的学习 在前两天的学习中我们知道、了解并掌握了Web Server结合App Server实现单向Https的这样的一个架构。这个架构是一个非常基础的J2ee工程上线布署时的一种架构。在前两天的教程中，还讲述了Http服务 器、App Server的最基本安全配置（包括单向https的实现）， 它只是避免了用户可以通过浏览器侵入我们的Web访问器或者能够通过Web浏览器来查询我们的Web目录结构及其目录内的文件与相关内容，这种入侵我们把 它称为： Directory traversal，当然我们只是实现了最基本的防范Directory traversal的手段，在日后的Security课程中将会详细地去擅述完整的Web Security的相关理论。 从今天起我们将继续在原有的这种Apache+Tomat的架构上，去论述如何在性能及Performance上优化这个架构，因此这两天的课程在有些人看来，可能会有些“枯燥”，所以我在此给大家打个招呼： 这 两天的课程论述的是如何在不改动代码与SQL语句的前提下，如何去改善和提高web server与app server的性能，千万不要小觑这一内容，它可以让你在不改动代码的情况下得到10-20倍以上的性能提高，网上有其它的大牛们写过一篇文章叫 “Tomcat如何支持到1000个用户”，经本人经过几个重大工程的实践

3 月，跳不动了？>>> 前言： 从今天开始，我们将学习如何使用Webservice进行二进制附件的传输，这一课题将分成两个部分： l 第一部分实现Client上传一个附件到服务端，服务端接收Client传过来的二进制附件后保存至本地。 第二部分实现Client上传一个Java复杂类型，该复杂类型中有一个字段叫myPhoto，为一个jpg/gif附件，服务端接受该上传的复杂类型，并把其中的二进制字段中的图片保存至本地。 以下是我们要存取的图片（搞笑一下啊） 目标: 1． 客户端用Webservice上传一个二进制文件，服务端收到客户端request后把二进制附件读出，保存至本地 一、编写Server端 1.1 制作Service端 package ctsjavacoe.ws.fromjava; import javax.jws.WebMethod; import javax.jws.WebService; import javax.xml.ws.Holder; import java.io.*; @WebService public class MTOMSimple { @WebMethod public void echoData(Holder<byte[]> data) { OutputStream os = null; ByteArrayInputStream bin =

介绍： 给列表（ListView）提供多选框功能（Multiple Choice）的Adapter，从而可以很方便让ListView支持多选功能。除了ListView，这个Adapter也可以用在GridView中。 测试环境： 编译测试，测试环境：Eclipse 4.2, Android 3.0 以上。 效果图： 来源： oschina 链接： https://my.oschina.net/u/187822/blog/289861

前言： 第一天里说了如何用jax-ws去结合ssh框架。 在今天的教程中将会向大家详细讲述一个ws-security中的一个传统的”基于handler”来认证客户端传来的用户名密码的webservice. 客户端传过来一对用户名和密码,服务端进行认证。 当然，我们此处说这个用户名和密码的传送，那可不是用下面的这种形式来传送的哦: http://xxx.do?username=xxx&password=xxx 。 我们这个用户名和密码是带在soap报文中的， jax-ws用一个handler专门用于处理soap报文的。 一、书写Handler 1. 1 handler类 package ctsjavacoe.ws.fromjava; import java.util.*; import javax.servlet.http.HttpServletRequest; import javax.xml.namespace.QName; import javax.xml.soap.*; import javax.xml.ws.handler.MessageContext; import javax.xml.ws.handler.soap.*; import javax.xml.ws.soap.SOAPFaultException; import org.apache.cxf

前言： 在今天的学习中，我们讲开始过渡到一个真正的websecurity例子。 第二天中我们知道了如何使用handler来处理客户端提交上来的用户名与密码，而在今天的学习中，我们将会使用服务端预先配置的用户名与密码来authenticate客户端提交上来的值。 相对于第二天的学习，如果客户端提交的用户名与密码输错，但还是能够与服务端建立http连接来说，第三天中的例子的安 全性则更高，当客户端提交上来的用户名与密码错误则更本不可能和服务端建立起有效的http连接。该例子同时适用于一切J2EE AppServer，比如说:IBMWAS, ORACLE WEBLOGIC。 同时，通过该例子将讲述ws-security与相关的ws-policy进而一步步过渡到QoS。 一、配置服务端的相关角色 1.1 配置J2EE AppServer中的相关用户名与密码 打开tomcat下的cnof/tomcat-user.xml文件： <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="operator"/> <user username="tomcatws" password="123456" roles="operator"/> </tomcat-users> 通过上述配置

前言： 在前面的“5天学会jaxws-webservice教程”，我们讲了基本的jax-ws的使用。 Jax-ws是业界公认的标准的webservice，它已经成为了一个行业界标准，包括cxf，其实cxf也是调用的jax-ws为标准的基于spring的webservice框架。 同时，大家都知道世界上除了j2ee体系外，还存在.net体系，同时有过相关经验的同事们也知道用ws-security无非就是涉及到“加密”，“解密”，而JAVA的x509所涉及到的证书，公钥，私钥与.net体系之间是无法通用的。 但是webservice是因该属于无所谓语言的一个标准，因此为了让j2ee的webservice与.net的webservice能够互相调用（当然包括ws-security里的加密解密），SUN与微软联合推出了一个：WCF。 WCF是Windows Communication Foundation的缩写，原来代号为Indigo,它是MS为SOA（Service Oriented Architecture 面向服务架构）而设计的一套完整的技术框架。利用它能够开发出分布式(Distributed)应用程序，而且开发难度相比以前 的.NETRemoting和ASP.NETXML Web Service等都有了大幅度的降低。 那么搞J2EE的人如何去支持这个WCF呢？我们不可能去用

Android 多线AsyncTask详解 您可以通过点击 右下角 的按钮 来对文章内容作出评价, 也可以通过左下方的 关注按钮 来关注我的博客的最新动态。 如果文章内容对您有帮助, 不要忘记点击右下角的 推荐按钮 来支持一下哦 如果您对文章内容有任何疑问, 可以通过评论或发邮件的方式联系我: 609025984@qq.com 如果需要转载，请注明出处，谢谢！！ 本篇随笔将讲解一下Android的多线程的知识，以及如何通过AsyncTask机制来实现线程之间的通信。 一、Android当中的多线程 在Android当中，当一个应用程序的组件启动的时候，并且没有其他的应用程序组件在运行时，Android系统就会为该应用程序组件开辟一个新 的线程来执行。默认的情况下，在一个相同Android应用程序当中，其里面的组件都是运行在同一个线程里面的，这个线程我们称之为Main线程。当我们 通过某个组件来启动另一个组件的时候，这个时候默认都是在同一个线程当中完成的。当然，我们可以自己来管理我们的Android应用的线程，我们可以根据 我们自己的需要来给应用程序创建额外的线程。 二、Main Thread 和 Worker Thread 在Android当中，通常将线程分为两种，一种叫做Main Thread，除了Main Thread之外的线程都可称为Worker Thread。

在集群环境下，大家会碰到一直困扰的问题，即多个 APP 下如何用 quartz 协调处理自动化 JOB 。 大家想象一下，现在有 A ， B ， C3 台机器同时作为集群服务器对外统一提供 SERVICE ： A ， B ， C 3 台机器上各有一个 QUARTZ ，他们会按照即定的 SCHEDULE 自动执行各自的任务。 我们先不说实现什么功能，就说这样的架构其实有点像多线程。 那多线程里就会存在“资源竞争”的问题，即可能产生脏读，脏写，由于三台 APP SERVER 里都有 QUARTZ ，因此会存在重复处理 TASK 的现象。 一般外面的解决方案是只在一台 APP 上装 QUARTZ ，其它两台不装，这样集群就形同虚设了； 另一种解决方案是动代码，这样就要影响到原来已经写好的 QUARTZ JOB 的代码了，这对程序开发人员来说比较痛苦； 本人仔细看了一下 Spring 的结构和 QUARTZ 的文档，结合 Quartz 自身可以实例化进数据的特性找到了相关的解决方案。 本方案优点： 1. 每台作为集群点的 APP SERVER 上都可以布署 QUARTZ ； 2. QUARTZ 的 TASK （ 12 张表）实例化如数据库，基于数据库引擎及 High-Available 的策略（集群的一种策略）自动协调每个节点的 QUARTZ ，当任一一节点的 QUARTZ

前言： 随着近几年来，SOA，EAI等架构体系的日渐成熟，Webservice越来越炽手可热，尤其是在企业做异质平台整合时成为了首选的技术。 Java的Webservice技术更是层出不穷，比较流行的有： Axis2，Spring WS以及Jaxws。 本人在日常工作和以往工程中，在使用了上述这些Webservice后进行了总结，比较，最终觉得jaxws是目前最标准，需要额外第三方插件最少，配置最少最灵活的webservice。 JAXWS适合几乎所有Webservice客户端的调用，因此不少巨头型的厂商如：IBM，Weblogic等，在他们的产品上都使用了以JAXWS为标准的Webservice接口。 本教程分成五天，为初级教程。 通过本教程，可以使一个没有Webservice概念或者没有写过Webservice的JAVA Resource快速上手入门，并能满足一般中小型项目中Webservice的应用。 对于Webservice Security，在（初级）教程中并不提供，会在高级教程中详细描述。 不过真正利用Webservice Security特性即XML加密技术的工程并不多，少之又少，大多还是以 http: //xxx/xxxService?userId=&password= 这样的形式来进行“假安全”通讯的。 必经我们的大部分项目是运行在Intranet里的