Add detach replica in shutdown function when error occurs during apply segment of journal #8688
Conversation
…y segment of journal
| m_replicator = nullptr; | ||
| if (m_attachment.hasData()) | ||
| m_attachment->detach(&localStatus); |
There was a problem hiding this comment.
Both m_replicator and m_attachment are RefPtr's and nullifying them causes a release() call which does the proper cleanup (similar to close/detach) under the hood. So I don't see what is actually fixed. What do I miss?
There was a problem hiding this comment.
It turns out that for m_replicator close is called during release and it is not necessary to do this (I added it for the company with m_attachment, which is the problem).
There detach is not called during release, only destroy, in which requests, events, transactions, etc. are released and the handle is also removed, but the connection to the DB itself remain.
There was a problem hiding this comment.
Hmmm. YAttachment::destroy() calls destroy2() which nullifies next which in turn calls release() for the underlying provider. So AFAIU the connection should be closed.
There was a problem hiding this comment.
That's right.
The problem occurs when using an external engine, even without a replication error.
It uses the context of the current replication connection and increases the reference counter, and when the main connection is nullified. In the JAttachment::release function the counter is not equal to 0 and freeEngineData is not called, in which the following functions should be called in the chain:
purge_attachment
release_attachment
dbb->dbb_extManager->closeAttachment
delete attInfo
~ExternalContextImpl
externalAttachment->release // In which the counter should be reduced and the external engine connection should be deleted.
This behavior occurs in RedDatabase, but I am sure that it will be the same in Firebird, since the code in this part is not different, but I cannot check, since there are problems with configuring jaybird for Firebird.
Calling the detach function on the main connection directly calls internalDetach and freeEngineData, which closes the connection and releases all resources.
If an error occurs during segment apply that results in a return other than PROCESS_CONTINUE, the connection to the replica will not be detach. With asynchronous replication the error will like be repeated, result to many connections that take up RAM and hold a connection to the database.