websphere ejb压力测试下,锁socket的问题

应用部署在websphere7.0上。
开一个实例,一个ejb ,实例的内存为8g,ejb为5g左右,并发100以上就出现锁socket的现象。
以上是利用kill -3 生成的javacore文件。
打印的堆栈如下:(比较长哈~_~)
at com.ibm.rmi.util.buffer.SimpleByteBuffer.flushTo(SimpleByteBuffer.java:192) - locked [9ffffffe87d7eeb8] (a java.net.SocketOutputStream) - locked [9fffffff29698e60] (a com.ibm.rmi.util.buffer.SimpleByteBuffer) at com.ibm.rmi.iiop.IIOPOutputStream.writeTo(IIOPOutputStream.java:532) at com.ibm.rmi.iiop.Connection.write(Connection.java:2127) at com.ibm.rmi.iiop.Connection.sendFragment(Connection.java:2355) at com.ibm.rmi.iiop.IIOPOutputStream.sendFragment(IIOPOutputStream.java:189) at com.ibm.rmi.iiop.CDRWriter.completeFragment(CDRWriter.java:654) at com.ibm.rmi.iiop.CDROutputStream.alignAndReserve(CDROutputStream.java:272) at
...
com.ibm.rmi.io.IIOPOutputStream.simpleWriteObjectInternal(IIOPOutputStream.java:441) at com.ibm.rmi.io.IIOPOutputStream.simpleWriteObjectLoop(IIOPOutputStream.java:469) at com.ibm.rmi.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:526) at com.ibm.rmi.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:168) at com.ibm.rmi.iiop.CDRWriter.write_value(CDRWriter.java:1194) at com.ibm.rmi.iiop.CDRWriter.write_value(CDRWriter.java:1212) at com.ibm.rmi.iiop.CDRWriter.writeAnyOpt(CDRWriter.java:899) at com.ibm.CORBA.iiop.UtilDelegateImpl.writeAny(UtilDelegateImpl.java:365) at javax.rmi.CORBA.Util.writeAny(Util.java:97) at com.adtec.pool.ejb._EJSRemote0SLECAPResPoolBean_c87de11f_Tie.getResData(_EJSRemote0SLECAPResPoolBean_c87de11f_Tie.java) at com.adtec.pool.ejb._EJSRemote0SLECAPResPoolBean_c87de11f_Tie._invoke(_EJSRemote0SLECAPResPoolBean_c87de11f_Tie.java) at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:622) at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:475) at com.ibm.rmi.iiop.ORB.process(ORB.java:504) at com.ibm.CORBA.iiop.ORB.process(ORB.java:1573) at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2793) at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2662) at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63) at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1527)

监控ejb的线程共61,发现wait on condition 12,wait on monitor 49.
其中ejb的对象读取代码如下
public Object getResData(int type, String name) throws BaseException
{
ErrLog eLog;
try
{
isStratResPool();

Object retObj = null;

ConcurrentHashMap resPool = (ConcurrentHashMap)getResPool(type);

if (resPool != null) {
return resPool.get(name);
}

return retObj;
}
catch (BaseException e) {
...
} catch (Exception ex) {
...
}
}

public Object getResPool(int type) throws BaseException
{
ErrLog eLog;
try
{
isStratResPool();

switch (type)
{
case 1:
return PoolManager.getActionHashtable();
...
case 20:
return PoolManager.getTranPathHashtable();
}
try
{
...
} catch (Exception e) {
...
}
}

[该贴被admin于2009-05-13 17:56修改过]

服务器要加Jprofiler来监测死锁,可以定位到具体类。

恩,谢谢bang的回复
最近一直都在解决的这个问题,但还是没有找到答案,其中有怀疑是由于应用对ejb只有一个连接,修改了应用连接ejb的ctx方式,修改成每次都new 一个ctx,但发现问题依然存在。
因为我们这边有大量的数据放在ejb,每次从ejb返回的对象都很大,并发50的时候不出现锁socket。

自己来把这个结一下吧

进过努力,确认是ejb的orb的只有一个连接导致,于是经历了ibm level2的支持,至今仍然没有答案

现修改架构方式,直接抛弃ejb,问题解决。