2.5 WebLogic如何设置session超时时间
1 web.xml
设置WEB应用程序描述符web.xml里的<session-timeout>元素。这个值以分钟为
单位，并覆盖weblogic.xml中的TimeoutSecs属性
<session-config>
<session-timeout>54</session-timeout>
</session-config>
此例表示Session将在54分钟后过期
当<session-timeout>设置为－2，表示将使用在weblogic.xml中设置的
TimeoutSecs这个属性值。
当<session-timeout>设置为－1，表示Session将永不过期，而忽略在
weblogic.xml中设置的TimeoutSecs属性值。
该属性值可以通过console控制台来设置2 weblogic.xml
设置WebLogic特有部署描述符weblogic.xml的<session-descriptor>元素的
TimeoutSecs属性。这个值以秒为单位
<session-descriptor>
<session-param>
<param-name>TimeoutSecs</param-name>
<param-value>3600</param-value>
</session-param>
</session-descriptor>
默认值是3600秒
原文地址：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=1972&tstart=25&quint=true
3 监控调优
3.1 理解JVM的垃圾收集机制
3.1.1 简述
GC即垃圾收集机制是指JVM用于释放那些不再使用的对象所占用的内存。java语言并不要求JVM有GC，也没有规定GC如何工作。不过常用的JVM都有GC，而且大多数GC都使用类似的算法管理内存和执行收集操作。在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而 大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和JVM支持的垃圾收集算法，便可以进行优化配置垃圾收集器。垃圾收集的目的在于清除不再使用的对象。GC通过确定对象是否被活动对象引用来确定是否收集该对象。GC首先要判断该对象时候可以收集。两种常用的方法是 引用计数和对象引用遍历。引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，JVM必须适当增减引用数。当某对象的 引用数为0时，便可以进行垃圾收集。早期的JVM使用引用计数，现在大多数JVM采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达 （reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，GC必须记住哪些对象可以到 达，以便删除不可到达的对象，这称为标记（ing）对象。下一步，GC要删除不可到达的对象。删除时，有些GC只是简单的扫描堆栈，删除未标记的对象，并释放它们的内存以生成新的对象，这叫做清除 （sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多GC可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。为此，GC需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有GC运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的 GC不断增加或同时运行以减少或者清除应用程序的中断。有的GC使用单线程完成这项工作，有的则采用多线程以增加效率。3.1.2 下面列举一些JVM使用的GC
标记－清除收集器：这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
标记－压缩收集器：有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。
复制收集器 这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，JVM生成的新对象则放在另一半空间中。GC运行时，它把可到达对象复制到另一半空 间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
增量收集器 增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。有多种方法可以定义实际的GC。
分代收集器 这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。JVM生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。
并发收集器 并发收集器与应用程序同时运行。这些收集器在某点上一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。
并行收集器 并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。3.1.3 Sun Hotspot 1.4.1 JVM堆大小的调整
Sun Hotspot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。JVM生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环 后，便获得使用期并进入旧域。在永久域中JVM则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。下面介绍如 何控制这些域的大小。
可使用-Xms和-Xmx控制整个堆的原始大小或最大值。比如，下面的命令是把初始大小设置为128M：
java –Xms128m –Xmx256m
为控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。比如下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：
java –Xms128m –Xmx128m –XX:NewRatio =3
可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。比如，下面的命令把新域的初始值和最大值设置成64m:
java –Xms256m –Xmx256m –Xmn64m
一般不把永久域当作堆的一部分。永久域默认大小为4m。运行程序时，JVM会调整永久域的大小以满足需要。每次调整时，JVM会对堆进行一次完全的垃圾收 集。使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当JVM加载类时，永久域中的对象急剧增加，从而使JVM不断调整永久域大小。为了避免 调整，可使用-XX:PerSize标志设置初始值。比如，下面把永久域初始值设置成32m，最大值设置成64m。
java –Xms512m –Xmx512m –Xmn128m –XX:PermSize=32m –XX:MaxPermSize=64m
默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满 时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空 间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。
使用-XX:SurvivorRatio可控制新域子空间的大小。同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：
java –Xms256m –Xmx256m –Xmn64m –XX:SurvivorRation=2
如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大 部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以 立即把它们移进旧域，避免在救助空间反复复制。
但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。
为控制新域中对象的复制，可用-XX:TargetSurvivorRatio控制救助空间的比例。该值是一个百分比，默认值是50。当较大的堆栈使用较低的sruvivorratio时，应增加该值到80至90，以更好利用救助空间。
用-XX:maxtenuring threshold可控制上限。为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0。设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：
java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝5000
1 web.xml
设置WEB应用程序描述符web.xml里的<session-timeout>元素。这个值以分钟为
单位，并覆盖weblogic.xml中的TimeoutSecs属性
<session-config>
<session-timeout>54</session-timeout>
</session-config>
此例表示Session将在54分钟后过期
当<session-timeout>设置为－2，表示将使用在weblogic.xml中设置的
TimeoutSecs这个属性值。
当<session-timeout>设置为－1，表示Session将永不过期，而忽略在
weblogic.xml中设置的TimeoutSecs属性值。
该属性值可以通过console控制台来设置2 weblogic.xml
设置WebLogic特有部署描述符weblogic.xml的<session-descriptor>元素的
TimeoutSecs属性。这个值以秒为单位
<session-descriptor>
<session-param>
<param-name>TimeoutSecs</param-name>
<param-value>3600</param-value>
</session-param>
</session-descriptor>
默认值是3600秒
原文地址：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=1972&tstart=25&quint=true
3 监控调优
3.1 理解JVM的垃圾收集机制
3.1.1 简述
GC即垃圾收集机制是指JVM用于释放那些不再使用的对象所占用的内存。java语言并不要求JVM有GC，也没有规定GC如何工作。不过常用的JVM都有GC，而且大多数GC都使用类似的算法管理内存和执行收集操作。在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而 大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和JVM支持的垃圾收集算法，便可以进行优化配置垃圾收集器。垃圾收集的目的在于清除不再使用的对象。GC通过确定对象是否被活动对象引用来确定是否收集该对象。GC首先要判断该对象时候可以收集。两种常用的方法是 引用计数和对象引用遍历。引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，JVM必须适当增减引用数。当某对象的 引用数为0时，便可以进行垃圾收集。早期的JVM使用引用计数，现在大多数JVM采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达 （reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，GC必须记住哪些对象可以到 达，以便删除不可到达的对象，这称为标记（ing）对象。下一步，GC要删除不可到达的对象。删除时，有些GC只是简单的扫描堆栈，删除未标记的对象，并释放它们的内存以生成新的对象，这叫做清除 （sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多GC可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。为此，GC需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有GC运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的 GC不断增加或同时运行以减少或者清除应用程序的中断。有的GC使用单线程完成这项工作，有的则采用多线程以增加效率。3.1.2 下面列举一些JVM使用的GC
标记－清除收集器：这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
标记－压缩收集器：有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。
复制收集器 这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，JVM生成的新对象则放在另一半空间中。GC运行时，它把可到达对象复制到另一半空 间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
增量收集器 增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。有多种方法可以定义实际的GC。
分代收集器 这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。JVM生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。
并发收集器 并发收集器与应用程序同时运行。这些收集器在某点上一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。
并行收集器 并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。3.1.3 Sun Hotspot 1.4.1 JVM堆大小的调整
Sun Hotspot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。JVM生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环 后，便获得使用期并进入旧域。在永久域中JVM则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。下面介绍如 何控制这些域的大小。
可使用-Xms和-Xmx控制整个堆的原始大小或最大值。比如，下面的命令是把初始大小设置为128M：
java –Xms128m –Xmx256m
为控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。比如下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：
java –Xms128m –Xmx128m –XX:NewRatio =3
可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。比如，下面的命令把新域的初始值和最大值设置成64m:
java –Xms256m –Xmx256m –Xmn64m
一般不把永久域当作堆的一部分。永久域默认大小为4m。运行程序时，JVM会调整永久域的大小以满足需要。每次调整时，JVM会对堆进行一次完全的垃圾收 集。使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当JVM加载类时，永久域中的对象急剧增加，从而使JVM不断调整永久域大小。为了避免 调整，可使用-XX:PerSize标志设置初始值。比如，下面把永久域初始值设置成32m，最大值设置成64m。
java –Xms512m –Xmx512m –Xmn128m –XX:PermSize=32m –XX:MaxPermSize=64m
默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满 时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空 间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。
使用-XX:SurvivorRatio可控制新域子空间的大小。同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：
java –Xms256m –Xmx256m –Xmn64m –XX:SurvivorRation=2
如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大 部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以 立即把它们移进旧域，避免在救助空间反复复制。
但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。
为控制新域中对象的复制，可用-XX:TargetSurvivorRatio控制救助空间的比例。该值是一个百分比，默认值是50。当较大的堆栈使用较低的sruvivorratio时，应增加该值到80至90，以更好利用救助空间。
用-XX:maxtenuring threshold可控制上限。为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0。设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：
java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝5000
-verbose.gc开关可显示GC的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。
打开-xx:+ printgcdetails开关，可以详细了解GC中的变化。
打开-XX: + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。
最后，通过-xx: + PrintHeapAtGC开关了解堆的更详细的信息。
为了了解新域的情况，可以通过-XX:=PrintTenuringDistribution开关了解获得使用期的对象权。
3.1.5 BEA JRockit JVM的使用
Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是Bea新JVM所在目录。
不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台或者WebLogic Server控制台。Bea JRockit JVM支持4种垃圾收集器：
分代复制收集器：它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery。这种收集器最适合单CPU机上小型堆操作。
单空间并发收集器：该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。
分代并发收集器：这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也 较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。
并行收集器：该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。默 认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc:<gc_name>，对应四个收集器分别为gencopy， singlecon，gencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用-Xns:
java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m…
尽管JRockit支持-verbose:gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、load和codegen的输出。
原文地址：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=124&threadID=19031&tstart=03.2 WebLogic Server Hang产生的一般原因
3.2.1 系统内存不足
 系统CPU忙，系统文件描述符数目不足，线程死锁，JVM有GC方面的bug，对于一些特定的情况可以使用truss命令跟踪系统调用来进行分析。可以打开JVM的gc log,在java命令行上加上-verbose:gc,GC的log输出在java进程的标准输出里,在hp的JVM上，可以通过在java命令行上加-Xverbosegc:file=gcfilename来将gc log写到指定的文件其输出类似：[GC 15639K->13700K(65280K), 0.0068439 secs]。解决办法是调整JVM的内存设置和gc算法,升级jvm或是os patch。
 出现OutOfMemoryError或是观察到内存吃紧，操作系统本身的剩余内存，通过top或是vmstat观察，操作系统的swap区，Swap区太小可能导致编译jsp时报“Not enough space”的错，操作系统kernel参数中maxsize的大小，如果观测到数据库连接池里的连接泄漏，极可能是内存泄漏的先兆
 JVM的heap区大小，通过java命令行中的-Xms,-Xmx指定，建议最小值和最大值设成一样，可以通过WebLogic console上server/monitor/performance来观察其使用情况，建议生产系统最256M，一般情况下可以设置为系统剩余物理内存的80％，Heap size太大在一些JVM上会有问题，对于sun和hp的JVM，permanent size太小也会出OutOfMemoryError，在java命令行上加-XX:MaxPermSize=128m
 尽量减少内存消耗，Session中不要放大的数据，并尽量在不再需要的时候remove掉，如果可以调整session timeout到较小的值，避免在J2EE server端应用里边调用AWT/swing作图，调整ejb的cache/pool设置
 内存泄漏，可以通过WebLogic console来观察JVM的heap memory使用情况来获知是否有内存泄漏情况，采用第三方辅助工具来获取更详细信息，如Jprobe/OptimizeIt；有可能是weblogic的bug，但绝大部分情况是由用户的应用引起的，最常见的代码问题是数据库连接没正常关闭。
 如果用户访问量很大，CPU占用很高（user态）并不是异常
 如果是kernel态很多，需要OS厂商调整操作系统
 采用top找到占用CPU很多的进程，如果是非weblogic进程，应该考虑将其移到另外的server上运行，如果是运行weblogic的java进程，通过做thread dump（详细信息后边会介绍到）来确认是那段代码导致了这么高的CPU使用（也有可能是os/jvm本身不正常）
3.2.3 系统文件描述符数目不足
Log中有“too many open files”的错误，表示达到了系统对一个进程能同时打开的文件数的限制：
 ulimit –a –H 可以查看当前限制
 ulimit –n number可以来更改当前环境的设置，建议至少设到4096
 Solaris上可以通过/usr/proc/bin/pfiles pid来查看指定进程的限制和当前使用的file descriptor数目
 Solaris上root用户可以通过/usr/proc/bin/plimit -n soft,hard pid 来动态更改进程的文件描述符的限制
3.2.4 线程死锁
对于原因不明的hang或是响应慢，最根本的方法就是获取thread dump信息，对于windows系统，在运行java的窗口按Ctrl＋Break，对于UNIX系统，首先用ps找到运行weblogic的java进程的pid，然后执行kill –3 pid，JVM将负责将所有java进程的状态、执行堆栈dump到其标准输出，为了方便获取thread dump信息，在weblogic启动的时候，最好将其标准输出重定向到一个文件，为了反映线程状态的动态变化，需要接连多次做thread dump，每次间隔10-20s。对于thread dump信息，主要关注的是线程的状态和其执行堆栈，线程的状态一般为三类
 Runnable（R）：当前可以运行的线程
 Waiting on monitor（CW）：线程主动wait
 Waiting for monitor entry（MW）：线程等锁
一般关注的都是第一和第三种状态的线程
CPU很忙则关注runnable的线程
CPU闲则关注waiting for monitor entry的线程
一种典型的死锁是由于在server端应用（比如servlet）中请求由同一weblogic实例serve的资源，解决办法就是将该servlet放到另外的执行队列里去执行。
原文地址：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=4525&tstart=0&quint=true3.3 "指定的网络名不再可用"错误
wl6.1和wl7.0部署应用后都在后台抛出“java.net.SocketException: ReadFile failed: 指定的网络名不再可用”,这不是一个致命的错误，只会在中文Window上。如Hilaser和linstone提出了办法： 如果你是自己随便玩玩，将你的JDK升级到jdk1.3.1_06
 用wls6.1 sp4，到如下位置下载
http://commerce.bea.com/SoftwareProductDetailWLS?SWName=WebLogic+Server+Evaluation+Software&SWVersion=Version+6.1+SP4&SWPlatform=Microsoft+Windows+NT%2F2000
 运行cmd，打开窗口菜单（点击左上角窗口图标），选择 默认值，将默认代码页改为437。原文地址：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=9393&tstart=0
4 集群配置
4.1 集群简明配置过程
在wls7中，集群的受管服务器无需使用相同的端口，这使在一个主机上实现集群成为可能。下面的例子是在一个主机（172.30.94.60）上的 wls7里创建一个集群（mycluster）DEMO，包括管理服务器（myserver:7001）、集群（两个受管服务器serverA: 8001、serverB:8003）、代理服务器（ProxyServer:80）。应用WebApp是部署在集群上的web应用，而 DefaultWebApp是部署在代理服务器上用来代理集群应用WebApp的。具体步骤如下：1．创建集群域clusterdomainnew，管理服务器myserver（7001:7003）；
2．创建Machine：admin（myserver,ProxyServer），cluster(serverA,serverB)；
3．创建受管服务器serverA(8001)，serverB(8003)；
4．创建集群mycluster；
Choose Servers for this Cluster: serverA，serverB
config.xml:
<Cluster ClusterAddress="172.30.94.60:8001,172.30.94.60:8003"
MulticastAddress="237.0.0.1" MulticastPort="7777" Name="mycluster"/>5．部署WebApp应用，targets mucluster；
6．创建代理服务器ProxyServer（80），将DefaultWebApp targets ProxyServer；
7．编辑DefaultWebApp应用，注册HttpClusterServlet：
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>
<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>172.30.94.60:8001:8002|172.30.94.60:8003:8004</param-value>
</init-param>
<init-param>
<param-name>DebugConfigInfo</param-name>
<param-value>ON</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>/</url-pattern></servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.jsp</url-pattern> </servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.htm</url-pattern> </servlet-mapping>
<servlet-mapping>
<servlet-name>HttpClusterServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
8．重启myserver；
9．启动serverA：startManagedWeblogic serverA http://172.30.94.60:7001;
启动成功后，访问http://172.30.94.60:8001/WebApp/ 验证一下！
10.启动serverB：startManagedWeblogic serverB http://172.30.94.60:7001;
启动成功后，访问http://172.30.94.60:8003/WebApp/ 验证一下！
11. 启动ProxyServer：startManagedWeblogic ProxyServer http://172.30.94.60:7001。
访问http://172.30.94.60/WebApp，是不是大功告成了：）原文地址：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=3257&tstart=25&quint=true
4.2.1 基本概念
1．硬件的cluster和WebLogic的cluster不是一回事，硬件做的是冷备份，对用户的session，用户请求的负载均衡等的处理是做不到 的，而且一般硬件的双机热备也不是时时的备份，而是间隔一段时间再将主机上的数据copy过来，而WebLogic Server的cluster就不是这样，其session的数据是时时的复制的，对不经常更改的jndi等的复制虽然也是定期完成的，但update的 时间间隔很短
2．WebLogic Server的cluster配置非常方便，请参考dev2dev学堂
http://dev2dev.bea.com.cn/bbs/school/guide/webser/20030627.html
如果你要对集群做扩展，操作也非常方便，你只需要启动一个指向这个集群的Admin Server的managed server就可以了，由这个集群中的唯一的Admin Server往这个managed server上部署应用
3．http状态会话复制就是session的复制，例如你登陆了系统，如果一个服务器坏了，cluster会将你的请求转发集群中的另外一个server，由其继续处理你的这个请求，而不要重新登陆。
4．EJB集群中有状态，无状态EJB的意义和区别请看J2EE中EJB的相关知识
5．对EJB的集群，也是非常简单的，直接把EJB应用target到cluster的server上！
6．对WebLogic Server来说，它的cluster做session的in memory的时时复制，这适用于web application及stateful session BEA的session内容的复制
7．对非stateful的EJB，WebLogic Server的cluster做其负载均衡及failover的工作（failover只针对EJB的stateless BEAN
4.2.2 集群规划
在规划集群配置时，应该牢记以下关于网络环境与集群配置的限制。1． 首先，集群中的WebLogic主机必须使用永久的静态IP地址。动态IP地址分配不能用于集群环境。如果服务器位于防火墙后面，而客户机位于防火墙外面，那么服务器必须有公共的静态IP地址，只有这样，客户端才能访问服务器。2．集群中的所有WebLogic服务器必须位于同一个局域网，并且必须是IP广播可到达的。3．集群中的所有WebLogic服务器必须使用相同的版本。配置集群中的服务器，使它们支持所提供的服务。对于使用了JDBC连接的EJB，所有部署了某EJB的服务器必须具有相同的部署与持久化配置。也就是说所有服务器都应该有相同的JDBC配置。所有部署了servlet的主机必须维护一组具有相同ACL的servlet。
如果客户端应用直接使用JDBC连接池，那么你必须为每个WebLogic服务器创建相同的连接池（并具有相同的ACL）。这意味着集群所使用的连接池应该 可以在所有的机器上创建。例如，一台运行WebLogic的NT服务器配置了连接Microsoft SQL Server数据库的连接池，那么一个包含非Windows机器（即不支持Microsoft SQL Server连接的机器）的集群不能使用这个连接池。
其它配置细节可能会因不同的集群成员而不同。例如，一台Solaris服务器可以比一台小的 NT工作站处理更多的登录请求。这种差异是可以接受的。因此，正如这里所给出的例子，对于那些与性能相关的属性，你可以根据每个集群成员的特点来配置不同 的值，只要所有成员的服务配置相同即可。因此，集群中的WebLogic服务器在所有与WebLogic服务、类文件以及外部资源（例如数据库）相关的方 面具有相同的配置。4.2.3 服务器配置任务列表
可以通过管理控制台进行以下服务器配置：
 Server节点配置单独的服务器可以配置的属性包括名字：监听端口与IP地址。
 Server节点克隆一个服务器：克隆的服务器保存了原来服务器的属性值，你可以使用Server节点中的Configuration配置新服务器的名字。
 使用管理控制台的Server节点来删除一个服务器：点击要删除的服务器的图标，将弹出一个删除服务器的确认对话框，点击对话框中的Yes按钮将删除服务器。
 使用管理控制台的Server节点查看一个服务器的日志：点击要查看的服务器，点击Monitoring标签页，点击View Server Log连结，便可以在管理控制台的右窗格查看服务器日志。
 使用管理控制台的Server节点查看一个服务器的JNDI树：点击所要查看的服务器，然后点击Monitoring标签页，点击该页面上View JNDI Tree连接，该服务器JNDI树的信息便显示在管理控制台的右窗格中。
 使用管理控制台的Server节点查看服务器的执行队列：点击所要查看的服务器，然后点击Execute Queue 链接，然后查看管理控制台右边窗格里的表格中的内容。
 使用管理控制台的Server节点查看服务器的执行线程：点击所要查看的服务器，然后点击Execute Queue 链接，然后查看管理控制台右边窗格里的表格中的内容：
 使用管理控制台的Server节点查看server sockets：点击所要查看的服务器,点击View Sockets连接，然后查看管理控制台右边窗格里的表格中的内容。
 使用管理控制台的Server节点查看服务器连接：点击所要查看的服务器，点击View Connections连接，然后查看管理控制台右边窗格里的表格中的内容。
 使用管理控制台的Server节点进行强制垃圾收集，点击要监控的服务器，点击JVM标签页，点击页面上的Force Garbage Collection连接，将弹出是否要进行垃圾收集的确认对话框。
 Server节点监视服务器的安全：点击要监控的服务器，点击Monitoring标签页，点击Security标签页，将显示安全信息。
 Server节点查看服务器的版本：点击要查看的服务器，点击Version标签页，将显示服务器的版本信息。
 Server节点监控服务器集群：点击要监控的服务器，点击Cluster标签页，将显示该服务器的集群数据。
 Server节点来部署EJB：点击需要部署EJB的服务器，点击需要分发的EJB并使用移动控件将它移到被选列中，点击Apply来保存你的选择。
 Server节点来监视部署在某一服务器上的所有EJB：点击需要监视的服务器，点击Monitor All EJB Deployments连接来显示EJB的部署列表。
 Server节点将web应用组件部署在某一服务器上：选择要部署web应用的服务器：选择需要部署的web应用，然后通过移动控件将它移到被选列中，点击Apply来保存你的选择。
 Server节点来监控某一服务器上的所有web应用组件：点击web应用所在的服务器，然后点击Monitor All Web Applications连接来显示Web Application 的部署列表。
 Server节点在服务器上部署启动与终止类：点击需要部署启动类的服务器，然后点击需要部署的启动类并将它移到被选列中，点击Apply来保存你的选择，使用终止类控件来部署终止类的过程与此相同。
 Server节点为服务器分配JDBC连接池：点击web server分配表中的一个服务器，在Available列中点击一到多个JDBC连接池，并通过移动控件将所选择的JDBC连接池移到Chosen列，点击Apply来保存你所做的分配。
 Server节点为一个服务器分配WLEC连接池：点击需要分配WLEC连接池的服务器：在Available列中选择一个或多个要分配的WLEC连接池，使用移动控件将所选择的WLEC连接池移动到Chosen列。
 通 过管理控制台的Server节点监视某一服务器上的所有WLEC连接池：选择一个需要监视连接池的服务器，点Monitor All WLEC Connection Pools on This Server链接，所有分配给这台服务器的连接池会显示在右窗格中的WLEC Connection Pools列表中。
 Server节点为一台服务器分配XML 注册表，选择要分配XML 注册表的服务器，从XML 注册表的下拉列表中选择一个注册表，点Apply保存设置。
 Server节点分配邮件会话：选择一个要分配邮件会话的服务器，从Available列中选择要分配给服务器的邮件会话，使用移动控件把所选择的移动会话移动到Chosen列中，点Apply按钮保存设置。
 通过管理控制台为服务器分配文件T3s：选择一个要分配文件T3的服务器，从Available列中选择要分配给服务器的文件T3s，使用移动控件把所选择的文件T3s移动到Chosen列，点Apply按钮保存设置。
 Connection连接，然后查看管理控制台右边窗格里的表格中的内容。
 使用管理控制台的Server节点进行强制垃圾收集：点击要监控的服务器，点击JVM标签页，点击页面上的Force Garbage Collection连接，将弹出是否要进行垃圾收集的确认对话框。
原文地址：
http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=4800&tstart=0&quint=true