Search code examples
cachingwebsphere

ejb2.x caching remote interface @ client side

In a bit old application, BizDelegate and ServiceLocator are used as Client side patterns. For some reason, BizDelegate got cached. Means, Home and Remote interfaces are being cached and shared between around 100 threads. Methods in BizDelegate are not synchronized either.

We are having a couple of issues.

  1. Thread issues on client side while writing into socket?(since single object is trying to shared between threads)
  2. When you do a deployment, always need to client restart?(since remote interface is stored and deployment making a different reference). We do have server EJB pool size 500 ejb object instance on server side.

Does it mean we use only one EJB instance created while home.create()? is it a kind of singleton? We use IBM Websphere AppServer 7V.

Same code used to work fine older versions.

Exception what we can see in logs.

0000003a ThreadMonitor W WSVR0605W: Thread "WebContainer : 76" (0000010f) has been active for 618203 milliseconds and may be hung. There is/are 1 thread(s) in total in the server that may be hung.

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)

Another one

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)
Solution

  • There is no such "ejb 2.4". Do you mean EJB 2.1?

    There are no threading issues with multiple client threads writing to the same socket. Excluding bugs, the ORB will multiplex calls on the same socket connection and manage the synchronization for you. (You did not mention which version of WebSphere Application Server you're using.)

    In WebSphere Application Server, client references to beans will remain valid through deployments so long as you use the same application name, module URI, and EJB names. If you change any of those (e.g., because you've included and changed a version number in your application name or module URI), then the client will need to be refreshed/restarted after redeployment. You could add a try/catch(NoSuchObjectException) around your remote calls and add logic to automatically refresh.