Domino 10 Java XPage сбой сервера через некоторое время с PANI C: семафор неверен или не выделен - PullRequest
Новая
       85

Domino 10 Java XPage сбой сервера через некоторое время с PANI C: семафор неверен или не выделен

1 голос
/ 22 февраля 2020

У меня есть приложение java XPages domino, которое работает на моем сервере и служит в качестве API для удаленной обработки базы данных Rooms & Resoruces (основная роль - получение резервирования для набора комнат и его периодическое обновление).

Все было хорошо при тестировании, но как только я поместил приложение на свой рабочий сервер, через некоторое время я получил cra * sh: 

Domino version:     Release 10.0.1FP3 August 09, 2019
OS Version:     Windows/2016 10.0 [64-bit]

Error Message = PANIC: semaphore invalid or not allocated
    SharedDPoolSize = 33554432
    FaultRecovery = 0x00010012
    Cleanup Script Timeout= 600
    Crash Limits = 3 crashes in 5 minutes
    StaticHang = Virtual Thread [   nHTTP:  0674:  0011] (Native thread [   nHTTP:  0674:  145c]) (0x674/0x11/0x170000145C)
    ConfigFileSem =  (  SEM:#0:0x1520000010D) n=0, wcnt=-1, Users=-1,  Owner=[        :  0000]
    FDSem         =  ( RWSEM:#53:0x410f) rdcnt=-1, refcnt=0 Writer=[        :  0000], n=53, wcnt=-1, Users=0,  Owner=[        :  0000]

<@@ ------ Notes Data -> OS Data -> Semaphores -> SEM Info (Time 10:34:34) ------ @@>

     SpinLockIterations   = 1500
     FirstFreeSem         = 819
     SemTableSize         = 827

############################################################
### thread 46/89: [   nHTTP:  0674:  145c] FATAL THREAD (Panic)
### FP=0xF3AC3F61E8, PC=0x7FFFC6DD5AC4, SP=0xF3AC3F61E8
### stkbase=0xF3AC400000, total stksize=1048576, used stksize=40472
### EAX=0x00000004, EBX=0x00000000, ECX=0x00001c6c, EDX=0x00000000
### ESI=0x000927c0, EDI=0x00001c6c, CS=0x00000033, SS=0x0000002b
### DS=0x00000000, ES=0x00000000, FS=0x00000000, GS=0x00000000 Flags=0x1700000246
############################################################
 [ 1] 0x7FFFC6DD5AC4 ntdll.ZwWaitForSingleObject+20 (10,0,0,F3AC3F6300)
 [ 2] 0x7FFFC3464ABF KERNELBASE.WaitForSingleObjectEx+143 (10,F3AC3F69B0,7FFF00000000,1c6c)
@[ 3] 0x7FFFB326DAD0 nnotes.OSRunExternalScript+1808 (5,0,424,0)
@[ 4] 0x7FFFB3269E9C nnotes.FRTerminateWindowsResources+1532 (5,23B45D80D50,0,1)
@[ 5] 0x7FFFB326BA23 nnotes.OSFaultCleanupExt+1395 (0,7f60,0,F3AC3F7C70)
@[ 6] 0x7FFFB326B4A7 nnotes.OSFaultCleanup+23 (7f60,7FFFB3DE7E30,0,200000000)
@[ 7] 0x7FFFB32D6D76 nnotes.OSNTUnhandledExceptionFilter+390 (F3AC3F7B50,7FFFB485A818,F3AC3F7C70,FFFFEB865BDB003)
@[ 8] 0x7FFFB326E70A nnotes.Panic+1066 (5dc,125851500347E41,7FF786A7B4A0,23B1D91F9A8)
@[ 9] 0x7FFFB329FDD6 nnotes.OSLockSemInt+70 (23B1D91F9A4,145c,7FF786A84578,7FF786A84578)
@[10] 0x7FFFB32A04ED nnotes.OSLockWriteSem+77 (23B1D92AA18,7FF786A84578,23B14EA41B0,7FF786A84578)
@[11] 0x7FFFAC74DDC1 nlsxbe.ANDatabase::ANDRemoveCalendar+33 (23B1D92AA18,7FF786A84578,0,23B18FFCBA8)
@[12] 0x7FFFAC881CBB nlsxbe.ANCalendar::`scalar deleting destructor'+91 (7FF786A84578,23B1BB6FC78,0,1)
@[13] 0x7FFFAC7FFAF7 nlsxbe.Java_lotus_domino_local_NotesBase_RecycleObject2+471 (23B159C7A00,23B1BB6FC78,23B1BB6FC70,0)
@[14] 0x7FFFAC7FF91A nlsxbe.Java_lotus_domino_local_NotesBase_RecycleObject+42 (23B159C7A00,23B1BB6FC78,23B1BB6FC70,23B159C7A00)

Большинство Операции основаны на поиске комнаты по ее адресу * integer * в представлении $Rooms в names.nsf, затем в соответствующей базе данных RnR и получении всех документов бронирования для этой указанной c комнаты. Иногда (хотя и очень редко) я также открываю календарь пользователей и создаю / обновляю резервирование.

Сначала я подумал, что это вызвано какой-то утечкой памяти или чем-то, я прошел весь код и recycled() все, что мог найти (и я обнаружил некоторые места с явными утечками ручек), но это совсем не помогло.

Меня беспокоит то, что аварии произошли в почти идентичные часы (4 дня спустя, через несколько минут после 10:00) .

Что может быть причиной этого крэ sh? Я плохо умею читать данные дампа, но вижу, что первым вызовом из списка вызовов фатального стека является RecycleObject, за которым следуют некоторые вещи, связанные с календарем.

Понятия не имею, куда мне обратиться мой код, зачем вообще перерабатывать сервер sh? ANCalendar предлагает мне не смотреть на код, который напрямую обращается к базе данных, а открывать календарь пользователей?

Обновление Изучая логи cra sh, мне удалось узнайте место, где произошла крэ sh. Это мой код создания встречи, который использует NotesCalendar.createEntry() в календаре пользователей. Код выглядит так: 

        Session session = reDatabase.getParent();

        Name nnOrganizer = session.createName(session.getEffectiveUserName());

        String organizerEmail = "";
        DirectoryNavigator nav = session.getDirectory().lookupNames("$Users", nnOrganizer.getCommon(), "InternetAddress");
        if(nav.findFirstMatch() && !nav.getFirstItemValue().isEmpty()) {
            organizerEmail = (String)nav.getFirstItemValue().get(0);
        }

        Recycler.recycle(nav);

        Name nnResource = session.createName(roomName);

        DbDirectory dir = session.getDbDirectory(session.getServerName());
        Database mdb = dir.openMailDatabase();
        NotesCalendar cal = session.getCalendar(mdb);

        String dStart = DateUtil.formatICalendar(dtStart);
        String dEnd = DateUtil.formatICalendar(dtEnd);

        String iCalEntry = "BEGIN:VCALENDAR\n" +
        // Rest of iCalendar string goes here
        iCalEntry += "END:VEVENT\n" +
            "END:VCALENDAR\n";

        cal.setAutoSendNotices(true);

        String apptUNID ="";

        try {
            NotesCalendarEntry entry = cal.createEntry(iCalEntry);
            Document doc = entry.getAsDocument();
            apptUNID = doc.getItemValueString("ApptUNID");
            Recycler.recycle(doc, entry);
        } catch (NotesException ex) {
            System.out.println("Couldn't create appointment!: " + ex.toString());
            throw ex;
        } finally {
            Recycler.recycle(mdb, cal, nnOrganizer, nnResource, dir, reDatabase, session);
        }
        return apptUNID; // return the UNID of the created entry (if any)

Учитывая, что стек фатальных вызовов начинается с вызова RecycleObject, есть ли что-то не так в моей утилизации здесь? Могу ли я переработать запись календаря сразу после ее создания? Это все еще немного сбивает меня с толку, но этот код хорошо работает на моем тестовом сервере. Что-то не так с этим? Это последний код, который выполняется при создании встречи, HTTP-ответ с apptUNID выполняется сразу после вызова вышеуказанной функции.

...