所以我正在解决一个问题，有些建议会很好。首先请介绍一下背景，请原谅。
我正在使用一个通过TL1 protocol查询网络设备的管理系统。对于那些不熟悉该协议的人来说，简短的答案是它是一种“人类可读”的语言，可以通过基于文本的IO流进行通信。
我正在使用Spring和Jsch打开到远程NE（网络元素）的端口，登录，运行命令，然后关闭连接。有两种进入远程网元的方法，一种是直接（通过ssh网关）进入（如果该元素具有tcp / ip地址（许多仅用于osi），另一种是通过某种类型的ems（管理系统）进入）被称为“北向接口”。
无论哪种方法，过程都是相同的。
使用Jsch打开到网元或em的端口。
发送网元ex的登录命令。 "act-user<tid>:<username>:UniqueId::<password>;"
发送命令ex。 "rtrv-alm-all:<tid>:ALL:uniqueid::,,,,;"
检索和处理结果。例如，上面的结果可能看起来像这样...RTRV-ALM-ALL:foo:ALL:uniqueid;CMPSW205 02-01-11 18:33:05M uniqueid COMPLD"01-01-06:MJ,BOARDOUT-ALM,SA,01-10,12-53-58,,:\"OPA_C__LRX:BOARD EXTRACTED\",";;很重要，因为它表示响应结束。
最后注销，然后关闭端口。
对于Spring，我一直非常有效地使用ThreadPoolTaskExecutor来做到这一点。
直到这个问题出现...
在一个特定的ems平台（日立）上，我遇到了一个障碍。该ems通过它处理多达80个节点。您连接到端口，然后发出命令以登录到ems，然后运行指向各个NE的命令。与以前相同的过程，但这是问题所在...
登录到ems后，无论它是什么，下一条命令最多需要10分钟才能完成。在此之前，所有其他命令均被阻止。在此初始等待之后，所有其他命令将快速运行。似乎没有办法消除这种行为（我怀疑在此期间发生了一些NE自动发现）。
现在我的问题的重点...
因此，对于该平台，我的下一个方法是连接到ems，登录到该ems，并保持连接打开，然后将命令传递给各个NE。这将意味着在首次加载基于Web的应用程序后会有10分钟的延迟，但是在此之后就可以了。
我的问题是如何最好地做到这一点。拥有一个基于文本的iostream来传递这些内容似乎是一个很大的瓶颈，加上多个用户将使用该应用程序，我如何处理针对此单个iostream的多个命令和响应？我可以在此ems上打开几个iostream（最多6个），但这也使弄清楚去哪儿变得复杂。
关于方向的任何建议将不胜感激。
最佳答案
看每个em使用一个进程，以便与每个em的通信分开。这至少将确保与其他ems的通信不受此问题的影响。
您将必须构建某种命令排队系统，以使发送到Hitachi em的命令在完成之前不会阻塞用户界面。要么，要么您必须在客户端软件开始使用之前将10分钟的延迟添加到客户端软件中，或者将10分钟的延迟添加到可以处理Hitachi的界面部分中。
断开连接并立即发送某种ping或站保持空闲命令可能是一个好策略-某些有益的内容，您无需关心响应，也不会给出响应，但会触发10分钟的延迟结束它。您的用户可以熟悉这10分钟的延迟，至少可以在开始喝咖啡或其他东西之前启动应用程序。
如果您能够以某种方式将日立与应用程序设计中的其他ems隔离开，那么这将确保只有在与日立接口时才存在10分钟的延迟。您可以连接并发出虚拟命令，然后将Hitachi置于某种“连接”状态，直到出现结果后才能使用命令，然后将状态更改为ready，以便用户可以与之交互。
另一种方法是开发某种中间件组件-我不知道您是否已经做过。如果客户端都是基于Web的，则可以在Web服务器上运行一个通信段，该通信段从客户端获取连接，然后将它们通过Web服务器上的一个段通过管道传输，该Web服务器与所有Ems进行通信。当此片段在网络服务器上启动时，它可以连接到每个em，并发送一些初始ping命令，以启动10分钟计时器。一旦完成，网络服务器上的程序就可以每隔一段时间发送一次keepalive消息，再一次使用某种虚拟命令，使套接字保持活动状态，这样就不必重置并再次经历10分钟的等待时间。当用户打开网站时，他们可以与此中间件服务器通信，该中间件服务器将请求转发到适当的ems，并将响应转发回客户端-全部通过已经打开的连接进行。