在 Linux 系统中,启用 IPv6 时 Monitoring Framework 将不会工作。因此,该系统中受监视组件的测试设备将不会加载到 cacao 容器中,并且不会在 Monitoring Console 中显示。
解决方案:有两种可行的解决方案:
将 Monitoring Framework 配置为不使用回送接口:
在 Monitoring Framework 配置目录(默认为 /etc/opt/sun/mfwk/config)中,复制一份样例属性文件:
cp mfwk.properties.sample mfwk.properties |
在新复制的 mfwk.properties 文件中设置以下参数:
mfwk.multicast.disableloopback=true |
按照《Sun Java Enterprise System 5 监视指南》中的“重新启动节点代理”过程,重新启动节点代理、主代理和 Monitoring Console。
或者使用以下步骤在 Red Hat 3.0 上禁用 IPv6:
在 /etc/modprobe.conf 文件中查找下面的行是否存在:
alias net-pf-10 ipv6 |
对其进行更改或添加以下行:
alias net-pf-10 off |
重新引导系统。此时 IPv6 应被禁用。
在 Red Hat 4.0 中,使用 /etc/modules.conf 文件执行相同的步骤。
在禁用受监视组件的过程中,应从受监视组件的节点代理取消其部署,但这一过程有时会冻结。特别是,cacaoadm undeploy 命令不再返回,并且监视在整个节点代理中被阻塞。
解决方案:中止该进程,然后按照《Sun Java Enterprise System 5 监视指南》中的“重新启动节点代理”过程,重新启动节点代理、主代理和 Monitoring Console。
依靠 C 库与 Monitoring Framework 连接的组件在 Linux 操作环境中运行时,可能在 Monitoring Console 中显示得更慢。
解决方案:无。
在同一节点代理中的其他组件重新部署或停止后,依赖于 C 库的组件可能在 Monitoring Console 中表现出更低的监视性能。
解决方案:按照《Sun Java Enterprise System 5 监视指南》中的“重新启动节点代理”过程,重新启动节点的 Common Agent Container(包括节点代理),然后重新启动主代理和 Monitoring Console。
在同一主机上依赖于 C 库的组件和节点代理之间的进程间通信不安全。默认情况下,通信使用回送接口,因而降低了安全风险。
解决方案:无。
通过 SNMP 访问时,依靠 Java 库与 Monitoring Framework 连接的组件可能会遇到性能问题。
解决方案:无。
由于 Solaris 9 中存在的一个错误,发往 IPv4 地址的包未传送到 IPv6 套接字上的侦听器。这会中断该主机上节点代理与受监视组件之间的搜索机制。
解决方案:使用以下命令强制节点代理的 JVM 侦听 IPv4 套接字:
cacaoadm stop oldvalue=`cacaoadm get-param java-flags --value` cacaoadm set-param java-flags="${oldvalue} -Djava.net.preferIPv4Stack=true" |
然后按照《Sun Java Enterprise System 5 监视指南》中的“重新启动节点代理”过程,重新启动节点代理、主代理和 Monitoring Console。
如果节点代理和主代理主机上的时间相差甚远,则无法将该节点添加到 Monitoring Console。主代理的 Monitoring Framework 的错误日志将在“建立 JRMP 连接期间”报告一个严重错误。
解决方案:设置任一主机上的时间以使两者同步。
专用 C API 的文档被意外包含在运行时软件包中。它描述的接口是专用接口,并且随时会有变化,因此不主张使用这些接口。
解决方案:无。
当在 HP-UX 操作系统上的某个节点代理中并行创建大量监视规则时,Java 虚拟机 (Java Virtual Machine, JVM) 中的线程数可能会超出内核参数限制,进而导致 OutOfMemory 异常。
解决方案:如《Sun Java Enterprise System 5 监视指南》中的“在 HP-UX 上优化 Monitoring Framework 的内核参数”过程所述,下载并运行 HPjconfig 工具。