Назад | Перейти на главную страницу

Встроенный LDAP WebLogic дает сбой

Наш рабочий административный сервер (WebLogic 10.3.5, работающий на Solaris 10) время от времени дает сбой. Журналы показывают массу этих ошибок (по несколько каждую минуту):

<1-Jun-2012 2:28:34 o'clock AM EDT> <Critical> <EmbeddedLDAP> <BEA-000000> <java.lang.NullPointerException
at weblogic.socket.DevPollSocketMuxer.cleanupSocket(DevPollSocketMuxer.java:150)
at weblogic.socket.DevPollSocketMuxer.cancelIo(DevPollSocketMuxer.java:166)
at weblogic.socket.SocketMuxer.deliverExceptionAndCleanup(SocketMuxer.java:836)
at weblogic.socket.SocketMuxer.deliverEndOfStream(SocketMuxer.java:760)
at weblogic.ldap.MuxableSocketLDAP$LDAPSocket.close(MuxableSocketLDAP.java:128)
at com.octetstring.vde.Connection.close(Connection.java:166)
at com.octetstring.vde.WorkThread.executeWorkQueueItem(WorkThread.java:89)
at weblogic.ldap.LDAPExecuteRequest.run(LDAPExecuteRequest.java:50)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)

В конце концов, серверу администратора не хватает памяти:

<1-Jun-2012 12:29:59 o'clock PM EDT> <Error> <Kernel> <BEA-000802> <ExecuteRequest failed
java.lang.OutOfMemoryError: GC overhead limit exceeded.

Одно не обязательно вызывает другое, но похоже, что оно очень хорошо подходит.

Изучая код WebLogic, мы видим следующее:

void cleanupSocket(MuxableSocket paramMuxableSocket, SocketInfo paramSocketInfo) {
this.sockRecords[paramSocketInfo.getFD()] = null; // DevPollSocketMuxer.java:150
super.cleanupSocket(paramMuxableSocket, paramSocketInfo);
}

protected void cancelIo(MuxableSocket paramMuxableSocket)
{
super.cancelIo(paramMuxableSocket);

cleanupSocket(paramMuxableSocket, paramMuxableSocket.getSocketInfo()); // DevPollSocketMuxer.java:166
}

Таким образом, paramMuxableSocket.getSocketInfo () будет иметь значение null. Я не могу объяснить это ... У кого-нибудь есть идея?

Спасибо!

В итоге мы увеличили максимальный размер кучи до 512 МБ и уменьшили количество обращений к AdminServer LDAP за счет кэширования результатов на стороне клиента. Задача решена.