解决方法
这不是JavaRebel所做的. JavaRebel(根据描述)热替换内存中的类.在与系统的现有连接的情况下,这是不可接受的,因为更新的类可能会破坏客户端的逻辑.
一旦我工作的公司有类似的问题,它就这样解决了：
>智能路由器被用作负载均衡器
>新版本已部署到(新)群集的50％节点
>新连接严格地传递给这些更新的节点,旧节点在旧节点之间平衡
>旧节点脱机(一个接一个,以保持每个节点的客户端数量在限制范围内)
>与此同时,新版本被部署到离线的“旧”节点,并将它们作为新节点启动
>由于EJB集群,会话和bean被其他旧节点选中
>最终(在几个小时内),只剩下一个旧节点,只有一个旧版本的实例,所有使用旧版本的客户端都连接到它
>当最后一个旧客户端断开连接时,该节点太低了
现在,我不是一个网络人,也不能给你很多细节(比如什么是路由器硬件等).我的理解可以很简单,但是,如果我没记错的话,我们必须设置一个额外的Weblogic域来部署应用程序的新版本(否则它将与JNDI名称上的旧版本冲突).
希望有所帮助.
附： Ichorus提供了一条评论说该应用程序部署在客户端的服务器上.所以路由器技巧可能不可行.现在,我现在只看到一个可行的解决方案(现在是21:52,我可能忽视了一些事情:)) –
>使用“版本化”JNDI名称开发新版本;例如如果Customer bean在版本1中的ejb / Customer下,则在版本2中,它将在ejb / Customer2下
>在应用程序中有一个具有稳定基本界面(工厂风格)的业务外观,当被要求使用Customer bean时,它会尝试查找版本最高的JNDI名称(当然,不是每次调用都可以缓存一小时或者所以).该外观可以(并且应该)作为单独的应用程序部署 – 并且从不或很少更新
>现在每个新客户端都可以访问部署的最新应用程序,并且应用程序不会发生冲突.
这种方法需要仔细规划和测试,但应该工作恕我直言.
