问题标签 [websphere]

遇到 JSF 正在填满我们的会话的问题。前几天我们发生了系统崩溃。将 Heap 发送给 IBM 进行审核，发现我们有一些会话高达 50M。他们在会话中发现 JSF 组件并且有些非常大。

那么，有没有可以做的调优呢？配置项要看？或者其他方向。

我们的系统是使用 JSF 和 Spring 作为表示层构建的，后端是 EJB、Spring 和 Hibernate，它们都在 WebSphere 6.1 上运行。

如何强制 Websphere 编译我的 .tag 文件？

清理项目、发布、重新启动服务器、添加和删除项目都没有帮助 - 标记文件的 .class 文件没有被重新编译。

如果我删除 .class 文件，我会收到一个错误，指出该类丢失，但它不会重新编译

我正在使用 Websphere 门户 6.0，我想知道是否有一种方法可以告诉服务器从 doView 方法呈现哪个页面。我知道我可以通过 processAction 方法做到这一点，但不幸的是问题的语义不允许这样做。

感谢您的帮助

如何仅使用 Websphere (5.1) 在外部 JavaScript 文件上设置字符编码？我前面没有 Apache，所以我不能使用“AddCharset UTF-8 .js”来设置它。

或者也许还有其他方法可以通过 web.xml 或类似的魔法将其强制到 Web 容器上？

我正在使用 IBM Websphere Application Server v6 和 Java 1.4，并尝试将大型 CSV 文件写入 CSV 文件以ServletOutputStream供用户下载。目前文件大小在 50-750MB 之间。

较小的文件不会造成太大的问题，但是对于较大的文件，它似乎被写入堆中，然后导致 OutOfMemory 错误并关闭整个服务器。

这些文件只能通过 HTTPS 提供给经过身份验证的用户，这就是为什么我通过 Servlet 为它们提供服务，而不是仅仅将它们粘贴在 Apache 中。

我正在使用的代码是（在此周围删除了一些绒毛）：

这FileInputStream似乎不会导致问题，就像我写入另一个文件或只是完全删除写入内存使用似乎不是问题一样。

我在想的是，resp.getOutputStream().write它被存储在内存中，直到数据可以发送到客户端。所以整个文件可能会被读取并存储在resp.getOutputStream()导致我的内存问题和崩溃中！

我尝试过缓冲这些流，也尝试过使用 Channels from java.nio，但似乎都没有对我的内存问题产生任何影响。我还刷新了OutputStream循环的每次迭代和循环之后，这没有帮助。

我有一个 war 文件（实际上不是我自己的，它是 Apache ODE 1.2），由于类加载器问题以及与 wsdl4j 的特定不兼容而无法部署到 WAS 6.1。如果我手动编辑 ODE 的类加载器并为 wsdl4j1.6.1 创建一个共享库，一切都很好。

但是，客户回来说这是不可接受的，我应该提供一个独立安装的耳朵，不涉及手动步骤。

我已经能够构建捆绑战争的耳朵文件，但我找不到任何有关如何在耳朵中包含共享库的相关信息 - 并且在类加载器的开头使用它（需要优先考虑wsdl4j 与 WAS 捆绑在一起）。我需要修改ear 文件结构吗？还是application.xml？

任何人都可以提供任何帮助吗？正如您可能猜到的，我来自“tomcat 只需要一个战争文件”背景，努力掌握耳朵文件。

我的 application.xml 只包含： http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"> XXX ODE ode.war ode 等

我从事一项涉及从一个应用程序移动/遍历到另一个应用程序的任务。这些应用程序位于不同的 JVM 中。

在遍历另一个应用程序时，我会跟踪会话 ID。但是，当我来回遍历时，会创建一个新会话。当我从子应用程序导航回父应用程序时，有什么方法可以让我使用我保留的 sessionId 返回相同的会话？

环境：带有 WebSphere 的 J2EE。

我们正在使用 IBM JDK 1.4.2 在 AIX 上的 Websphere Portal Server 5.1 上将一个相当复杂的应用程序作为 portlet 运行。在我们的生产系统上，我可以在详细的 GC 日志中看到一个奇怪的行为。在一段时间的正常行为之后，系统可以开始快速分配越来越大的块。系统开始花费超过 1000 毫秒来完成每个 GC，但是分配块的速度非常快，以至于分配失败之间只有 30 毫秒的间隔。

• 每个分配失败比最后一个稍大一些整数 x 1024 字节。例如，您可能有 5 MB，然后不久之后 5 MB + 17 * 1024。
• 这可以持续长达 10 分钟。
• 在停止之前，这些块的大小往往会增长到 8 到 14 MB。
• 这是一个四核系统，我假设它现在花费超过 95% 的时间进行 GC，其中三个核心等待另一个核心完成 GC。10 分钟。哎哟。
• 显然，此时系统性能会下降。
• 我们有 JSF、hibernate 和 JDBC、Web 服务调用、log4j 输出等等。

我认为这可能是基础设施而不是我们的应用程序代码。如果是循环内的错误字符串连接，我们预计会比 1024 个块有更多的不规则增长。如果是 StringBuffer 或 ArrayList 增长，我们会看到块大小翻倍。这种增长让我想到了日志缓冲或其他东西。在我们的应用程序中我想不出任何分配甚至 1 MB 的东西，更不用说 14。今天我在内存中寻找日志记录备份，然后再刷新到磁盘，但是在这段 GC 颠簸期间的日志记录语句量远不及MB 范围。

很明显，问题在于过多的内存分配，而不是垃圾收集，垃圾收集只是尽力跟上。有些东西正在分配一个大块并试图以太小的增量低效地增长它。

当系统处于负载状态时，有什么想法可能导致所有这些吗？有人看到与 Portal Server 类似的东西吗？

注意：对于任何感兴趣的人来说，原因似乎是偶尔但巨大的数据库查询。罪魁祸首似乎是 Hibernate 或 JDBC 驱动程序。

我们有一个需要并行化的 Websphere Java EE 应用程序，我们希望为此使用CommonJ 工作组件。

每个“线程”都需要对来自数据库的数据有自己的看法。其中大部分是预取的，但仍需要到数据库中获取一些。我们预计所有这些线程的整体工作的持续时间将是“长的”（即有足够的时间来更改基础数据）。

因此，我们需要确保隔离应用程序使用的数据并在线程工作过程中查询。

似乎确保这一点的唯一方法是进行“全局”事务并使用 XA 事务。但我们希望尽可能避免这种复杂性（和开销），并且正在寻找想法或替代方案：有什么想法吗？

此外，Common-J 工作组件在多大程度上（如果有的话）支持容器管理的事务？

@Karl：也许我只是指开销。我们的想法是 XA 事务和消息传递会产生共享事务的 Common-J 工作组件可以避免的开销？正在操作的数据集将是超过 300k 的不同数据行，每行需要对其进行约 100 次计算。尽管这些可以划分到不同的线程上操作共享、缓存、只读数据，但复制到/读取队列的相对内存开销似乎令人望而却步。你会同意吗？

@Karl：每个实体几十到几百毫秒。我们还专注于改进逻辑处理作为一项单独的任务。
当要求所有线程在单个数据库中具有一致的数据视图时，我是否需要使用 XA 事务？我对此的回答是，每个线程都需要自己的 JPA EntityManager（例如连接），并且需要 XA 来协调它们的访问。
但是，如果我可以在没有 XA 的情况下做到这一点，那就更好了，不是吗？

我有一个在 Windows 操作系统上的 IBM Websphere Application Server 上运行的 J2EE 应用程序。

有时我会在 javacore 文件中看到带有以下信息的 OutOfMemoryError 异常。

Java 使用以下配置运行：-Xms512m -Xmx1350m -Xscmx50M

分析javacore文件，线程数只有124个。分析heap dump，heap占用的内存约500Mb。

鉴于相对正常的线程数和堆大小远低于最大值，我试图弄清楚为什么我会看到这个错误？

我不确定这是否有帮助，但这里是 javacore 文件的顶部...