4

我在职业生涯中遇到过几次的问题是在分层服务架构中，如果单个下游系统进入其所有线程都被死锁或某种无限循环消耗的状态，它可能会导致整个客户端应用程序瘫痪该系统中的错误。在这些情况下，Java EE 服务器上的服务器套接字仍在接受来自客户端应用程序的请求并对其进行排队。这会导致客户端应用程序用尽所有等待来自正确建立的套接字连接的响应的线程。然后所有用户都被锁定在系统之外，因为他们的请求也在排队。

我已经想到了一些解决方案，但我想知道社区是否有更好的解决方案。

  1. 下游请求的隔离线程池。这成为一个问题，因为您在系统中增加了空闲线程的数量，创建了许多需要足够线程来确保完全吞吐量的小池。产生线程意味着您需要自己处理事务和安全上下文。不是真正受支持的 Java EE 解决方案。

  2. MDB 解决方案，Java EE 的首选异步解决方案，然而，这似乎相当重量级，但具有让应用程序服务器处理管理 MDB 线程池的额外好处。（目前在我的名单上排名第一）

  3. ESB。这甚至更重，并增加了更多的网络和处理时间。但它允许您设置单独的服务超时。还有一个问题是在大公司中实施需要很长时间，所以在我的时间范围内可能不切实际。

大家有什么更好的想法吗？

4

3 回答 3

1

您是正确的，因为 MDB 案例是正常的解决方案，它通常也支持超时，这将有助于避免挂起请求。话虽如此，它可能并不能真正解决问题，而只是将备份转移到您的 JMS 队列，而不会将响应发送回客户端。当然，如果几个服务中只有一个导致了这个问题，其他的现在仍然可以访问。

您的建议 (1) 也可以通过 commonj WorkManager 在 WebSphere 或 Weblogic 上实现。它将允许您在这些环境中创建托管线程并且非常轻量级。

WorkManager 和 TimerManager API

于 2008-11-17T20:46:07.200 回答
0

我们使用 MDB，其中队列持久保存在数据库中，这样的好处是，如果系统出现故障，消息不会丢失。

您可能还希望在参与方之间建立异步合同。我的意思是，客户端将向您发送一条消息，而不是您进行大量繁重的处理并返回响应，您只需发送一个确认响应，然后向他们发送一条带有完整结果的异步消息。

您还应该建立一个协议，如果客户端在规定的时间内没有收到完整的响应，则允许客户端重新发送消息。

于 2008-11-17T20:31:39.727 回答
0

您可以尝试使用Atomikos MessageDrivenContainers（消息驱动 POJO）的轻量级 MDB 方法。您的应用程序将更轻量级、更好的可测试性并且可能也更具可扩展性。

看http://www.atomikos.com/Publications/J2eeWithoutApplicationServer。

高温高压

盖伊

于 2009-06-02T20:11:56.160 回答