问题描述</p>

WebLogic Server 实例在监听或接收消息时有问题,或者在 BEA WebLogic Server 之间通常都无法成功使用组播功能。 </td> </tr> </tbody> </table>

</tbody> </table>

转载请注明:WebLogic Android 博客 » WebLogic组播错误[转]

故障排除</p>

请注意,并非下面所有任务都需要完成。有些问题仅通过执行几项任务就可以解决。

快速链接

为什么发生此问题?

一般而言,此问题是由于 BEA WebLogic Server 中组播的配置问题引起的。另外,网络问题(比如在该计算机上没有安装组播)也会造成此问题。使用下列检查清单检查组播的配置、其它可能存在的问题和一般问题。

返回页首

组播地址/端口问题

组播地址出现问题是群集无法启动或者服务器连接群集失败的最常见原因之一。每个群集需要一个组播地址。组播地址可以是介于 224.0.0.0 和 239.255.255.255 之间的 IP 号,或者是具有在该范围内的 IP 地址的主机名。

如果组播地址不正确,您很有可能看到以下错误:

  • 无法为群集创建组播套接字
  • 组播套接字发送错误
  • 组播套接字接收错误

若要检查地址/端口问题:

  1. 使用 WebLogic Server 控制台检查群集的组播地址和端口。
  1. 检查 config.xml 中的组播信息,或通过控制台检查是否有错别字、拼写错误等。

特别检查组播的地址和端口。有关组播和故障排除的详细信息,参见:http://e-docs.bea.com/wls/docs70/ConsoleHelp/domain_cluster_config_multicast.html#1104722

</p>

返回页首

不同 WLS 版本的组播配置差异</p>

</span>在 WLS 6.1 和 WLS 7.0 之间存在影响组播地址和端口的网络配置差异。

  1. 在以下网址查看 WebLogic Server 7.0 中为组播提供的网络配置新功能列表:http://e-docs.bea.com/wls/docs70/admin_domain/network.html#1089150,然后与 WLS 6.x 做一些比较:
    • 6.x 版:在群集中,从每个服务器的监听端口设置复制组播端口号。因为群集的所有成员必须使用相同的组播地址和端口号,所以要求群集中的所有服务器使用相同的监听端口。
    • 7.x 版:群集的组播配置不再与单台服务器的网络配置绑定。相反,配置独立于群集成员所用端口号的群集组播端口号。您还可以确定每个群集服务器应当将哪一个 NIC 用于组播通信。

返回页首

物理问题/共享地址问题

  1. 验证网络连接没有任何物理问题。
  1. 检查没有任何其它应用程序正在使用群集组播地址。

备注:一种检查方法是使用特定操作命令查看该地址/端口是否正在使用,比如 netstat

</p>

返回页首

重复 IP 地址

通过检查确保没有把重复 IP 地址分配给多台计算机。

返回页首

测试组播/错误通信

如果您收到 Unable to send service announcement(无法发送服务公告)消息,这指示一个常规网络问题或 DNS 配置错误。群集服务器通过组播互相通信,并且必须共享相同(专用的)组播地址。在 WLS 8.1 中,群集能够智能地删除不与其特定域和群集关联的组播消息。因此在群集正常工作时,如果其它资源正在组播地址上广播,它必须执行额外工作才能接收消息然后将其抛弃。

  1. 运行 utils.MulticastTest实用程序以验证组播正在工作,或者是否观察到不同群集正在互相进行会话而这种情况不是所需要的。 有关详细信息,请参阅 http://e-docs.bea.com/wls/docs70/adminguide/utils.html#1117048

示例:

在 MachA 上运行:java utils.MulticastTest  -N ginger -A 237.0.0.1 -P 7126

在 MachB 上运行:java utils.MulticastTest  -N fred -A 237.0.0.1 -P 7126

在 MachC 上运行:java utils.MulticastTest  -N smith -A 237.1.1.60 -P 7126

在 MachD 上运行:java utils.MulticastTest  -N jones -A 237.1.1.60 -P 7126

您应当只能看到在第一个组合中交换的“fred”和“ginger”的消息。相反,您应当只能看到在第二个组合中交换的“smith”和“jones”的消息。如果您看到在这些组合之间交换的消息或者从其它进程根本看不到消息,则出现了网络问题。

  1. 如果组播测试失败,则检查是否使用了 Primary 地址(WLS 需要使用 Primary 地址)。检查是否正确安装和使用 DNS。
    1. 获取 /usr/sbin/ifconfig -a信息(必须作为 root 用户运行才能获取 MAC 地址)并检查多宿主环境中每个计算机的 MAC 地址。 如果地址相同,那么可能有问题。 您应当确保地址是唯一的(尤其在 Solaris 上)。  否则,您会遇到许多问题。  一个解决方法是将通过一个接口卡组成多宿主环境的所有 Solaris 计算机集中在一起。  另一个方法是再添加一个接口卡。这是 Solaris 中存在的已知问题。
    1. 以下示例仅针对 Solaris,在其它平台上不需要。在 Solaris 和 SunOS 系统上,以太网设备一般称为 le0 或 ie0。为了查找以太网设备的 MAC 地址,通过利用 su 首先成为 root 用户。然后键入 ifconfig -a并查找相关信息。 例如:

      :# ifconfig -a

      le0: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING>

      inet 131.225.220.144 netmask ffffff00 broadcast 131.225.255.255

      ether 8:0:20:f:c2:f

      备注:Solaris 和 SunOS 删除通常包含在 MAC 地址中最前面的 0。 在此计算机中,MAC 地址是 08:00:20:0f:c2:f8   请参阅 http://www.dimensional.com/findmac.htm

返回页首

文件描述符问题

  1. 检查文件描述符 (FD) 的数量。

    根据不同的操作系统,这可能是一个已知问题。例如,此问题会在 Solaris 上发生,而原因是系统打开过多的文件。Sun 指出这是因为有 fopen限制。

  2. 您可以执行象 lsof这样的命令,并了解在出现问题时进程已经打开了磁盘中多少个文件(不必担心套接字文件描述符)。
  1. 如果这成为一个问题,则增加系统中文件描述符的数量。

系统管理员需要为计算机解决这一问题。

</p>

返回页首

Nsswitch 配置

  1. 检查计算机上的 /etc/nsswitch.conf文件。您可能需要在服务器上将 nsswitch.conf文件中的顺序更改为“文件,DNS,NIS”以避免 UnknownHostExceptions随机发生(即使在服务器没有大量负载时它也会发生)。下面是 nsswitch.conf 的 man 页的一部分:

    备注:

    在每个使用 nsswitch.conf的进程内,整个文件仅读取一次;如果以后更改文件,则进程将继续使用原来的配置。在 Solaris 中,不可以静态使用 NSS 服务来链接程序。在 Linux 中,这不是一个问题。

返回页首

组播超时

当网络接口卡 (NIC) 出现 Failover(就象是断开网络)时就会观察到组播超时。它会生成类似以下消息: </span>。 如果您遇到这种错误: </p>

  1. 尝试禁用 NIC 的 Failover。
  1. 检查 Internet 组管理协议 (IGMP)。在交换机上有一个设置 igmp snooping,在缺省情况下为启用。该设置用于防止在交换机上出现组播泛流问题。通过禁用交换机上的 igmp snooping,WebLogic Server 组播测试就会取得成功。
  1. 检查待确认 Windows 2000 设置,以及:

    IGMP 级别:

    密钥:Tcpip\参数

    值类型:REG_DWORD – 数字

    有效范围:0,1,2

    缺省值:2

    说明:该参数决定系统在多大程度上支持 IP 组播并参与 Internet 组管理协议。在级别 0 上,系统不提供任何组播支持。在级别 1 上,系统仅可发送 IP 组播信息包。在级别 2 上,系统可以发送 IP 组播信息包并完全参与 IGMP 以接收组播信息包。

    尝试将系统设置为级别 2。

  2. 您还可以尝试设置 MulticastTTL=32。 

返回页首

群集心跳信号检测问题 

群集心跳信号检测问题也关系到组播问题。

  1. 设置 Multicast Send Delay

    </li> </ol>

    1. 如果已经设置了组播延迟但没有解决此问题,则检查下面两个作为接收和传输组播信息包的 udp 缓冲区大小的操作系统参数。 
      • 如果 udp_xmit_hiwat  udp_recv_hiwat的 udp 设置被设定为 8K,而组播信息包大小设置为 WebLogic 允许的最大值 (32K),这就可能会出现问题。
      • 如果下面两个属性(udp_xmit_hiwat  udp_recv_hiwat)都被设置为 64K,(显然保持 WebLogic 的组播信息包大小为其最大值 32K),则问题就得到了解决。

    返回页首

    群集组播风暴问题 </p>

    </u>如果您遇到组播风暴,则需要配置组播缓冲区大小。

    示例情况:

    故障症状:当组播网络通信量占满网络时,群集中的一个实例将终止群集 servlet 服务。

    发生此问题的原因:启动 WLS 时,就发现 6 mg 数据正在发送给其它实例,这些实例反过来继续发送该数据,结果数据量不断增大!

    关于组播风暴的背景信息:

    请参阅 http://e-docs.bea.com/wls/docs70/cluster/features.html#1031231

    配置组播缓冲区大小:

    可以利用 UNIX ndd实用程序来配置 TCP/IP 内核参数。udp_max_buf参数针对 UDP 套接字控制发送和接收缓冲区的大小(以字节计)。udp_max_buf的适当值因不同的部署而异。如果您遇到组播风暴,可以执行以下操作:

    1. 在更改 udp_max_buf之前,请阅读“Solaris Tunable Parameters Reference Manual”(Solaris 可调参数参考手册)的“TCP/IP Tunable Parameters”(TCP/IP 可调参数)一章之“UDP Parameters with Additional Cautions”(UDP 参数的额外注意事项)小节中的 Sun 警告说明,该参考手册可从以下网址得到:http://docs.sun.com/?p=/doc/806-6779/6jfmsfr7o&
    1. 除非有必要,否则不要更改 udp_max_buf
    1.  udp_max_buf的值增加到 32K,并评估该更改的影响。  
    1. 如果您再次发现组播风暴,可以尝试将缓冲区大小增加到 32K,同时还使用 WebLogic 指数延迟参数。

    返回页首

    多宿主配置

    如果主计算机采取多宿主配置,则确保您已经通过 WebLogic Server 控制台配置了 UnixMachine实例,并为每个服务器实例指定一个 InterfaceAddress以便处理组播通信量。

    返回页首

    背景信息

    返回页首

    调试组播 

    如果所有其它用过的选项都已经失败,那么您可以收集调试信息以便调试组播。

    调试标志

    专用于组播的调试参数是:

    • DebugCluster
    • DebugClusterHeartbeats
    • DebugClusterFragments

    调试组播

    启用这些调试参数时,将在日志文件中产生大量消息。 

    1. 在服务器启动时利用命令行通过添加以下命令来设置这些调试参数:

      -Dweblogic.debug.DebugCluster=true

      -Dweblogic.debug.DebugClusterHeartbeats=true

      -Dweblogic.debug.DebugClusterFragments=true

      或者

    2. 利用 weblogic.Admin实用程序动态启用调试标志。

    例如:

    java weblogic.Admin -url t3://localhost:6151 -username weblogic .password weblogic SET -type ServerDebug -property DebugCluster true

    您可以为上述其它参数重复此操作。您也可以通过运行相同的命令并将其设置为“false”来停用这些调试标志。

    1. 如果此调试还没有解决您的问题,那么支持部门也可以通过支持案例进行额外调试。

    返回页首

    </td> </tr> </tbody> </table>

    是否需要更多帮助?

    如果您已经理解这个模式,但仍需要其它帮助,您可以:

    1.  http://support.bea.com 上查询 AskBEA(例如使用“multicast error”),以查找其它已发布的解决方案。
    2.  http://support.bea.com 上,向 BEA 的某个新闻组中提出更详细具体的问题。

    如果这还不能解决您的问题,并且您拥有有效的技术支持合同,您可以通过登录以下网站来打开支持案例:http://support.bea.com

    反馈

    请给我们提供您的意见,说明此支持诊断模式“组播错误”一文对您有如何帮助,您需要的任何解释,以及对支持诊断模式的新主题的任何要求。

    免责声明:

    依据 BEA 与您签署的维护和支持协议条款,BEA Systems, Inc. 在本网站上提供技术技巧和修补程序供您使用。虽然您可以将这些信息和代码与您获得 BEA 授权的软件一起使用,但 BEA 并不对所提供的技术技巧和修补程序做任何形式的担保,无论是明确的还是隐含的。

    本文档中引用的任何商标是其各自所有者的财产。有关完整的商标信息,请参考您的产品手册。

    返回页首

    </td> </tr>