果集群的Weblogic应用出现下列问题：

• 通过Apache访问集群的Weblogic上应用时总是重定向到登录页，并且看到error.log日志里有如下错误日志：

[Mon Jun 25 14:28:35 2007] [error] CONNECTION_REFUSED [os error=0, line 1730 of ../nsapi/URL.cpp]: Error connecting to host 10.150.131.41:8001

• 通过request.getRemoteAddr()获取不了客户端的IP地址
• ####<2007-7-6 下午04时30分14秒 CST> <Error> <Cluster> <psmis_p1> <psmisServer41_8001> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1183710614608> <BEA-000126> <All session objects should be serializable to replicate. Check the objects in your session. Failed to replicate non-serializable object.>
• ####<2007-7-6 下午04时33分25秒 CST> <Error> <HTTP Session> <psmis_p1> <psmisServer41_8001> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1183710805782> <BEA-100049> <Error looking up session with id:Lv3MGN6X3wpnz6TgKZNZlX2Zny4fTX6vXfskQzs75XY5nGTZzx7G!-1815477621!255456967
  java.rmi.MarshalException: error marshalling return; nested exception is: 
  java.io.NotSerializableException:
• ####<2007-7-6 下午04时34分04秒 CST> <Warning> <HTTP Session> <psmis_p1> <psmisServer41_8001> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1183710844798> <BEA-100089> <The session id: LL4HGN6JhQpyjhT1htGyL7nVhV26cRFY1vHm1mXTFtLgQQhly2hg has been accessed from 5781179048806136779S:10.150.131.41:psmis_domain:psmisServer41_8001, a server that is neither the primary (-3434973462381298029S:10.150.131.41:[8002,8002,-1,-1,-1,-1,-1]:psmis_domain:psmisServer41_8002) nor the secondary (299667472757506764S:10.150.131.41:[8003,8003,-1,-1,-1,-1,-1]:psmis_domain:psmisServer41_8003). The request URL was: http://10.150.131.20:80/psmis/curr.html> 
  ####<2007-7-6 下午04时34分04秒 CST> <Warning> <HTTP Session> <psmis_p1> <psmisServer41_8001> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1183710844921> <BEA-100089> <The session id: LL4HGN6JhQpyjhT1htGyL7nVhV26cRFY1vHm1mXTFtLgQQhly2hg has been accessed from 5781179048806136779S:10.150.131.41:psmis_domain:psmisServer41_8001, a server that is neither the primary (-3434973462381298029S:10.150.131.41:[8002,8002,-1,-1,-1,-1,-1]:psmis_domain:psmisServer41_8002) nor the secondary (299667472757506764S:10.150.131.41:[8003,8003,-1,-1,-1,-1,-1]:psmis_domain:psmisServer41_8003). The request URL was: http://10.150.131.20:80/psmis/adEcFeeAndQuantity.html>

下面的内容也许能解决问题：

一、配置Weblogic的Apache http 插件

将静态的内容放在Apache服务器里，配置DocumentRoot参数和Directory参数指向静态内容。httpd.conf：

LoadModule weblogic_module modules/mod_wl_20.so
<IfModule mod_weblogic.c>
   WebLogicCluster 10.150.131.41:8001,10.150.131.41:8002,10.150.131.41:8003,10.150.131.41:8004
   MatchExpression * 
   DynamicServerList OFF
   KeepAliveEnabled ON
   KeepAliveSecs 30
</IfModule>

二、Weblogic内应用程序获取用户的ip

在apache+Weblogic整合系统中，apache会对request对象进行再包装，附加一些WLS要用的头信息。这种情况下，直接用request.getRemoteAddr()是无法取到真正的客户IP的。apache会增加下列头信息：X-Forwarded-For=211.161.1.239WL-Proxy-Client-IP=211.161.1.239
所取得客户的IP需要这样：     String ip=request.getHeader("X-Forwarded-For");
 if(ip == null || ip.length() == 0) {
   ip=request.getHeader("WL-Proxy-Client-IP");
 }
 if(ip == null || ip.length() == 0) {
   ip=request.getRemoteAddr();
 }
或者也可通过weblogic的设置直接能过request.getRemoteAddr();取得客户的IP。在weblogic console domain->servers->servername->General ->Advanced Options ->   WebLogic Plug-In Enabled Specifies whether this server uses the proprietary WL-Proxy-Client-IP header. (This is needed only when WebLogic plugins are configured.) 但是如果apache设置的是反向代理这样就不行了，因为apache不会向heaer写入WL-Proxy-Client-IP的信息。只能通过第一种方法解决。

三、配置WebLogic HTTP Session集群：

验证 Weblogic.xml 条目：
确保 weblogic.xml 含有需要为每个“会话复制”类型设置的所有参数。 例如，当使用内存中复制时，样本 weblogic.xml 将类似于如下形式：

      <session-descriptor> 
    <session-param> 
     <param-name>
       PersistentStoreType
     </param-name>
     <param-value> 
       replicated 
     </param-value> 
    </session-param> 
   </session-descriptor>

会话数据必须可序列化
为了支持 HTTP 会话状态的内存中复制，所有 servlet 和 JSP 会话数据都必须是可序列化的，否则会话复制将会失败。当启用了调试标志时，Weblogic Server 将在下面输出警告消息，指示会话仍未被复制。您必须使该对象变为可序列化的对象，这样才能复制它。其它对象的会话复制将会正常进行。

调试消息：

<Oct 8, 2003 2:10:45 PM PDT> <Error> <Cluster> <000126> <All session objects should be serializable to replicate. Please check the objects in your session. Failed to replicate non-serializable object>

解决办法：

找到从中抛出错误的页面，并确保输入会话中的所有数据是可序列化的。

检查网络/组播问题：
确保网络是完好的，且没有组播问题。您可以执行组播测试来确保组播 IP 工作正常。

运行 utils.MulticastTest 实用程序

1.语法形式类似于：

java utils.MulticastTest -n name -a address [-p portnumber] [-t timeout] [-s send]

1.您也可以参阅 http://e-docs.bea.com/wls/docs81/admin_ref/utils.html#1199798

验证群集配置：
从群集列表中选择 Primary 服务器和 Secondary 服务器。在一个由两个服务器组成的群集中，如果该群集没有包含所有服务器，则不能选择 Secondary 服务器，从而导致会话数据不能被复制。

若要验证，可执行下列命令：

1.确保 weblogic.jar 在类路径中。

1.若要获得群集中的所有服务器：

java weblogic.Admin -username weblogic -password weblogic -url http://oneofthemanagedserverurlinthecluster:6151/ GET -type ClusterRuntime .pretty

这样将列出群集中的所有服务器。可以将 URL 改变为群集中的每个服务器，以确保他们拥有相同的条目。

应用程序代码诊断：
确保仅在应用程序代码中使用 HttpSession 中的 setAttribute/removeAttribute 方法来更新 Http 会话。如果您使用其它设置方法来更改会话内的对象，WebLogic Server 将不复制这些更改。

请不要使用 http 会话的 putValue 和removeValue 方法，因为它们不受支持，并且当您在应用程序中使用这些方法时，可能会出现会话数据复制问题。相反，请仅使用 HttpSession 的setAttribute/removeAttribute 方法。

Cookie 与 URL Rewriting ：
在某些情况下，浏览器或无线设备可能不接受 cookie，这样会使利用 cookie 的会话跟踪不能进行。当 WebLogic Server 检测到浏览器不接受 cookie 时，URL Rewriting 是对这种情况的一个可自动替换的解决方法。

通过设置 WebLogic-specific 部署描述符 weblogic.xml 中、<session-param> 元素下的 URLRewritingEnabled 属性，在 WebLogic Server 中启用 URL Rewriting。此属性的缺省值为 true。

性能问题：

考虑序列化系统开销
序列化会话数据会给复制会话状态带来一些系统开销。系统开销随序列化对象大小的增大而增加。如果您想在会话中创建很大的对象，请测试您的 servlet 的性能，以确保性能是可接受的。

控制对会话数据的帧访问
如果您正在设计使用多帧的 Web 应用程序，请记住给定帧集中的帧无法执行任何请求同步。

例如，尽管在逻辑上客户端应当仅创建单个会话，但帧集中的多个帧可以代表客户端应用程序创建多个会话。

为了避免意外的应用程序行为，您应认真规划如何利用帧访问会话数据。可以应用下列其中一个一般规则来避免常见问题：

• 在一个给定帧集中，确保只有一个帧创建和修改会话数据。
• 始终在应用程序使用的第一个帧集内的某个帧中创建会话（例如，在所访问的第一个 HTML 页面中创建会话）。
• 在创建会话后，仅在除第一个帧集外的其它帧集中访问会话数据。

在会话中存储更大量的数据
JDBC 持久性和文件持久性的速度将不会更快，因为会话数据必须存储在外部资源中并从中检索，并且也会因为 JDBC 访问每个会话的更新信息而存在性能开销。如果您想在会话中存储大型对象，则应考虑 JDBC 或文件持久性。

在会话中存储小量的数据

当您不需要在会话中存储大量数据时，基于 cookie 的会话持久性是最有用的。基于 cookie 的会话持久性可以使 WebLogic Server 安装的管理更加容易，因为不需要群集 Failover 逻辑