我职业生涯中遇到的一个问题是在分层服务架构中，如果一个下游系统进入一个状态，其所有线程都在死锁或某种类型上被消耗，那么单个下游系统可以关闭整个客户端应用程序该系统中的无限循环错误。在这些情况下，Java EE服务器上的服务器套接字仍在接受来自客户端应用程序的请求并对其进行排队。这会导致客户端应用程序耗尽所有线程，等待正确建立的套接字连接的响应。然后，所有用户都被锁定在系统之外，因为他们的请求也在排队。
我想到了一些解决方案，但我想知道社区是否有更好的解决方案。
下游请求的隔离线程池。这成为一个问题，因为您组合了系统中的空闲线程数，从而创建了许多需要具有足够线程以确保完全吞吐量的小池。产生线程意味着您需要自己处理事务和安全上下文。不是真正受支持的Java EE解决方案。
MDB解决方案，这是Java EE的首选异步解决方案，然而这看起来相当重，但具有让app服务器处理管理MDB线程池的额外好处。 （目前在我的名单上排名第一）
ESB。这甚至更重，并增加了更多的网络和处理时间。但它允许您设置单个服务超时。还有一个问题，就是要在大公司实施这个问题，所以我的时间框架可能不实用。
你们有更好的想法吗？
答案 0 :(得分：1)
你是正确的，因为MDB案例是正常的解决方案，它通常也支持超时，这将有助于避免挂起请求。话虽这么说，但它可能无法解决问题，只是将备份转移到JMS队列，而不会将响应发送回客户端。当然，如果几个服务中只有一个会导致这个问题，那么其他服务现在仍然可以访问。
您的提议（1）也可以通过commonj WorkManager在WebSphere或Weblogic上实现。它允许您在这些环境中创建托管线程，并且非常轻量级。
答案 1 :(得分：0)
我们使用MDB，其中队列持久存储在数据库中，如果系统出现故障，该数据库的好处是不会丢失消息。
您可能还希望在参与方之间建立异步合同。我的意思是客户端会向您发送消息，而不是您进行大量重量级处理并返回响应，您只需发送确认响应，然后向其发送异步消息并获得完整结果。
您还应该建立一个协议，允许客户端在已建立的时间内未收到完整响应时重新发送消息。
答案 2 :(得分：0)
您可以使用Atomikos MessageDrivenContainers（消息驱动的POJO）尝试轻量级MDB方法。您的应用程序将更轻量级，更易于测试，并且可能更具可扩展性。
请参阅 http://www.atomikos.com/Publications/J2eeWithoutApplicationServer。
HTH
盖