Caching ejb2.x缓存远程接口@客户端

在稍旧的应用程序中，BizDelegate和ServiceLocator用作客户端模式。出于某种原因，BizDelegate被缓存。 也就是说，主接口和远程接口正在缓存，并在大约100个线程之间共享。BizDelegate中的方法也不同步

我们有几个问题

写入套接字时客户端的线程问题？因为单个对象试图在线程之间共享 在进行部署时，始终需要重新启动客户端？因为存储了远程接口，并且部署使用了不同的引用。 我们在服务器端有服务器EJB池大小为500的EJB对象实例。 这是否意味着我们只使用home.create时创建的一个EJB实例？这是一种单身吗？ 我们使用IBMWebSphereAppServer7v

与旧版本的代码相同

我们可以在日志中看到的异常

000000 3A ThreadMonitor W WSVR0605W:Thread WebContainer:76 0000010f已处于活动状态618203毫秒，可能已挂起。服务器中总共有/有1个线程可能挂起

at com.ibm.rmi.util.buffer.SimpleByteBuffer.flushTo(SimpleByteBuffer.java:174)
   at com.ibm.rmi.iiop.IIOPOutputStream.writeTo(IIOPOutputStream.java:541)
   at com.ibm.rmi.iiop.Connection.write(Connection.java:2213)
at com.ibm.rmi.iiop.Connection.sendFragment(Connection.java:2438)
at com.ibm.rmi.iiop.IIOPOutputStream.sendFragment(IIOPOutputStream.java:202)
at com.ibm.rmi.iiop.CDRWriter.completeFragment(CDRWriter.java:659)
at com.ibm.rmi.iiop.CDROutputStream.alignAndReserve(CDROutputStream.java:276)
at com.ibm.rmi.iiop.CDROutputStream.writeOctetArrayPiece(CDROutputStream.java:694)
at com.ibm.rmi.iiop.CDROutputStream.write_octet_array(CDROutputStream.java:670)
at com.ibm.rmi.iiop.CDROutputStream.write_octet_array(CDROutputStream.java:664)
at com.ibm.rmi.iiop.ClientRequestImpl.write_octet_array(ClientRequestImpl.java:734)
at com.ibm.rmi.ServiceContext.write(ServiceContext.java:121)
at com.ibm.rmi.iiop.RequestMessage.write(RequestMessage.java:449)
at com.ibm.rmi.iiop.ClientRequestImpl.<init>(ClientRequestImpl.java:188)
at com.ibm.rmi.iiop.GIOPImpl.createRequest(GIOPImpl.java:185)
at com.ibm.rmi.corba.ClientDelegate._createRequest_WLM(ClientDelegate.java:1874)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1061)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1143)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1259)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1042)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1225)
at com.ibm.rmi.corba.ClientDelegate.request(ClientDelegate.java:1685)
at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1181)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:458)

另一个

WebContainer : 37" daemon prio=3 tid=0x00000001050d9000 nid=0xe6 runnable [0xfffffffe3aff7000]
   java.lang.Thread.State: RUNNABLE
  at java.net.SocketOutputStream.socketWrite0(Native Method)
  at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
  at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
  at com.ibm.jsse2.d.a(d.java:66)
  at com.ibm.jsse2.d.a(d.java:108)
  at com.ibm.jsse2.SSLSocketImpl.b(SSLSocketImpl.java:337)
  at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:594)
  at com.ibm.jsse2.k.write(k.java:18)
  - locked <0xfffffffe9ca84e08> (a com.ibm.jsse2.k)
  at com.ibm.rmi.util.buffer.SimpleByteBuffer.flushTo(SimpleByteBuffer.java:152)
  - locked <0xfffffffe9ca84e08> (a com.ibm.jsse2.k)

---

没有这样的EJB2.4。你是说EJB2.1吗

多个客户端线程写入同一套接字时不存在线程问题。除去bug，ORB将在同一套接字连接上多路调用，并为您管理同步。您没有提到您正在使用哪个版本的WebSphere Application Server

---

在WebSphereApplicationServer中，只要您使用相同的应用程序名称、模块URI和EJB名称，对Bean的客户端引用在整个部署过程中将保持有效。如果您更改了其中任何一个，例如，因为您在应用程序名称或模块URI中包含并更改了版本号，那么在重新部署后，客户端将需要刷新/重新启动。您可以在远程调用周围添加try/catchNoSuchObjectException，并添加自动刷新的逻辑。

IBM WAS V7。同样的代码在WAS5、5.1、6和6.1中运行良好。有人知道修复补丁吗？谢谢你的回答。是的，它是EJB2.x。现在它在IBM WASV7的重载下失败了。同样的代码在WAS6和6.1中工作得很好，具有相似的负载。它最初是为IBMWAS5.x编写的，可能会少一些。我想是EJB1.x。有人知道IBM提供的修补程序吗？同样，供应商是否应该按照EJB规范同步HomeInterface和Remoteinterface对象？代码不会显式执行。2个或更多线程正在等待套接字写入。这是从堆分析中得到的？我重复一下：您看到了什么具体错误？我无法提供任何帮助，包括IBMAPAR，除非您显示具体的故障。是的，应用服务器必须为EJB提供同步。如果多个线程正在向一个套接字写入，则它们必须向不同的套接字写入，假设没有缺陷，但我不知道有任何异常。添加了带疑问的异常详细信息。查看服务器的线程转储可能会很有意思，以确定它不读取请求的原因。也许它用完了线程，我看到这会导致问题吗？嗯，如果您能够轻松地复制这一点，那么最好与IBM建立一个PMR；它看起来不像是由坏的应用程序或简单的错误配置引起的。