Пожалуйста посоветуйте как можно решить проблемму.
Принимаются любые идеи (не только с domino с api) так как бьюсь уже неделю
Есть мой addin на c api. если мой addin не работает то куршений нет.
При одновременном обращении к одной и той же базе моего addin и nIMAP происходит крушение сервера
############################################################
### FATAL THREAD 7/10 [ nIMAP: 0c70: 0154]
### FP=0x13a3f444, PC=0x602774b7, SP=0x13a3f444
### stkbase=13a40000, total stksize=262144, used stksize=3004
### EAX=0x00000000, EBX=0x60c9ddf8, ECX=0x13a3f800, EDX=0x00ebeed0
### ESI=0x00000000, EDI=0x13a3f800, CS=0x0000001b, SS=0x00000023
### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000 Flags=0x00010202
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
@[ 1] 0x602774b7 nnotes.CIMsgMimeDirectoryStreamStore::GetHeaderStream+71 (ebed34,ebeed0,13a3f800,13a3f7f0)
@[ 2] 0x602447c9 nnotes.CIMsgImport::RewriteHeaders+233 (13a3f83c,ebed34,0,13a3f834)
@[ 3] 0x6027a2d7 nnotes.CIMsgMimeDirectoryStore::GetSomeHeaders+87 (ebed34,0,13a3f9f9,0)
@[ 4] 0x60278cb8 nnotes.MDGetSomeHeaders@28+40 (ebed34,0,13a3f9f9,0,0,0,0)
@[ 5] 0x004075be nIMAP.FormatBodyPart+990 (13a3fed8,1,0,56b0850,0,0,0)
@[ 6] 0x00408f83 nIMAP.FormatData+675 (2a465ac,56b0850,56b0a2c,13400001,0,0,0)
@[ 7] 0x00409891 nIMAP.ResponseProcess+1457 (11b,13400001,e72ee8,3,0,0,0)
@[ 8] 0x00418e04 nIMAP.IMAPThreadProc@4+836 (0)
@[ 9] 0x600fe6ef nnotes.ThreadWrapper@4+175 (0)
[10] 0x7c80b713 kernel32.GetModuleFileNameA+436
Крушение на вызове моим addin функции NSFNoteUpdate
@[19] 0x6012228b nnotes.NSFNoteUpdate@8+27 (2,0)
те hendle note 2, update_flags - флаг обновления 0 (в других задачах флаг 0 работает нормально)
Сам считаю что пути решения
1) как то проверять что note занята другим процессом (как проверить не знаю)
2) использовать какой то из этих флагов обновления
UPDATE_FORCE - Do an update or delete even if some other user has updated the note between the time the note was read into memory and the time we try to write it. This flag is appropriate for both updating and deleting a note.
UPDATE_NAME_KEY_WARNING - Give an error if the updated note contains a new field name that wasn't already defined in one of the forms in the database. This flag is appropriate for updating a note only.
UPDATE_NOCOMMIT - Do not flush all data to disk after the update. The note will be updated by the system, but non-summary data may not be immediately written to disk. This may improve the speed of NSFNoteUpdate if many operations are to be done sequentially, but risks loss of data if the machine crashes before data can be flushed to the disk. Summary data is always written to disk regardless of whether this flag is set or clear. This flag is appropriate for both updating and deleting a note.
UPDATE_NOREVISION - Do not maintain revision history. This flag is appropriate for updating a note only.
UPDATE_NOSTUB - Leave no trace of the note in the database if the note is deleted. This flag is only appropriate for deleting a note. You can use this flag on a deletion stub by removing the RRV_DELETED flag from the note id of the deletion stub before calling NSFNoteDelete or NSFNoteDeleteExtended. Once the deletion stub is removed, the deletion of the note will not be replicated. Otherwise, UPDATE_NOSTUB is only useful for applications that do NOT use views, and do not replicate. For example, a gateway may periodically examine a mail.box file, using NSFSearch and simply delete a document (using UPDATE_NOSTUB) when it's done with it. The database does not replicate, nor does it need views. UPDATE_NOSTUB ensures that there is minimum waste space allocated to stubs that are never needed in a highly volatile request-style database. Documents that are deleted with UPDATE_NOSTUB will still appear in the Domino views of the database and may cause problems when replicated. The documents themselves will not exist in the database and therefore cannot be opened.
UPDATE_INCREMENTAL - Compute incremental note info.
UPDATE_DELETED - The current update is a step in the process of deleting a note. API programs only use this flag in the context of a database hook driver. See Data Type DBHOOKVEC. Normally, API programs do not set this flag in calls to NSFNoteUpdate or NSFNoteDelete. NSFNoteDelete specifies this flag when it calls NSFNoteUpdate in the process of writing the deletion stub to the disk.
UPDATE_DUPLICATES - Obsolete. Allow duplicate items of the same name. This flag is appropriate for updating a note only.
UPDATE_SHARE_SECOND - Extended (32-bit DWORD) option: Split the second update of this note with the Note Object Store.
UPDATE_SHARE_OBJECTS - Extended (32-bit DWORD) option: Share only objects with the Note Object Store, not the summary information.
посоветйет пожалуйста что можно сделать
Принимаются любые идеи (не только с domino с api) так как бьюсь уже неделю
Есть мой addin на c api. если мой addin не работает то куршений нет.
При одновременном обращении к одной и той же базе моего addin и nIMAP происходит крушение сервера
############################################################
### FATAL THREAD 7/10 [ nIMAP: 0c70: 0154]
### FP=0x13a3f444, PC=0x602774b7, SP=0x13a3f444
### stkbase=13a40000, total stksize=262144, used stksize=3004
### EAX=0x00000000, EBX=0x60c9ddf8, ECX=0x13a3f800, EDX=0x00ebeed0
### ESI=0x00000000, EDI=0x13a3f800, CS=0x0000001b, SS=0x00000023
### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000 Flags=0x00010202
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
@[ 1] 0x602774b7 nnotes.CIMsgMimeDirectoryStreamStore::GetHeaderStream+71 (ebed34,ebeed0,13a3f800,13a3f7f0)
@[ 2] 0x602447c9 nnotes.CIMsgImport::RewriteHeaders+233 (13a3f83c,ebed34,0,13a3f834)
@[ 3] 0x6027a2d7 nnotes.CIMsgMimeDirectoryStore::GetSomeHeaders+87 (ebed34,0,13a3f9f9,0)
@[ 4] 0x60278cb8 nnotes.MDGetSomeHeaders@28+40 (ebed34,0,13a3f9f9,0,0,0,0)
@[ 5] 0x004075be nIMAP.FormatBodyPart+990 (13a3fed8,1,0,56b0850,0,0,0)
@[ 6] 0x00408f83 nIMAP.FormatData+675 (2a465ac,56b0850,56b0a2c,13400001,0,0,0)
@[ 7] 0x00409891 nIMAP.ResponseProcess+1457 (11b,13400001,e72ee8,3,0,0,0)
@[ 8] 0x00418e04 nIMAP.IMAPThreadProc@4+836 (0)
@[ 9] 0x600fe6ef nnotes.ThreadWrapper@4+175 (0)
[10] 0x7c80b713 kernel32.GetModuleFileNameA+436
Крушение на вызове моим addin функции NSFNoteUpdate
@[19] 0x6012228b nnotes.NSFNoteUpdate@8+27 (2,0)
те hendle note 2, update_flags - флаг обновления 0 (в других задачах флаг 0 работает нормально)
Сам считаю что пути решения
1) как то проверять что note занята другим процессом (как проверить не знаю)
2) использовать какой то из этих флагов обновления
UPDATE_FORCE - Do an update or delete even if some other user has updated the note between the time the note was read into memory and the time we try to write it. This flag is appropriate for both updating and deleting a note.
UPDATE_NAME_KEY_WARNING - Give an error if the updated note contains a new field name that wasn't already defined in one of the forms in the database. This flag is appropriate for updating a note only.
UPDATE_NOCOMMIT - Do not flush all data to disk after the update. The note will be updated by the system, but non-summary data may not be immediately written to disk. This may improve the speed of NSFNoteUpdate if many operations are to be done sequentially, but risks loss of data if the machine crashes before data can be flushed to the disk. Summary data is always written to disk regardless of whether this flag is set or clear. This flag is appropriate for both updating and deleting a note.
UPDATE_NOREVISION - Do not maintain revision history. This flag is appropriate for updating a note only.
UPDATE_NOSTUB - Leave no trace of the note in the database if the note is deleted. This flag is only appropriate for deleting a note. You can use this flag on a deletion stub by removing the RRV_DELETED flag from the note id of the deletion stub before calling NSFNoteDelete or NSFNoteDeleteExtended. Once the deletion stub is removed, the deletion of the note will not be replicated. Otherwise, UPDATE_NOSTUB is only useful for applications that do NOT use views, and do not replicate. For example, a gateway may periodically examine a mail.box file, using NSFSearch and simply delete a document (using UPDATE_NOSTUB) when it's done with it. The database does not replicate, nor does it need views. UPDATE_NOSTUB ensures that there is minimum waste space allocated to stubs that are never needed in a highly volatile request-style database. Documents that are deleted with UPDATE_NOSTUB will still appear in the Domino views of the database and may cause problems when replicated. The documents themselves will not exist in the database and therefore cannot be opened.
UPDATE_INCREMENTAL - Compute incremental note info.
UPDATE_DELETED - The current update is a step in the process of deleting a note. API programs only use this flag in the context of a database hook driver. See Data Type DBHOOKVEC. Normally, API programs do not set this flag in calls to NSFNoteUpdate or NSFNoteDelete. NSFNoteDelete specifies this flag when it calls NSFNoteUpdate in the process of writing the deletion stub to the disk.
UPDATE_DUPLICATES - Obsolete. Allow duplicate items of the same name. This flag is appropriate for updating a note only.
UPDATE_SHARE_SECOND - Extended (32-bit DWORD) option: Split the second update of this note with the Note Object Store.
UPDATE_SHARE_OBJECTS - Extended (32-bit DWORD) option: Share only objects with the Note Object Store, not the summary information.
посоветйет пожалуйста что можно сделать
