Skip to content

Add detach replica in shutdown function when error occurs during apply segment of journal #8688

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+6 −1
Open

Add detach replica in shutdown function when error occurs during apply segment of journal #8688

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion src/remote/server/ReplServer.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -416,7 +416,12 @@ namespace

void shutdown()
{
FbLocalStatus localStatus;
if (m_replicator.hasData())
m_replicator->close(&localStatus);
m_replicator = nullptr;
if (m_attachment.hasData())
m_attachment->detach(&localStatus);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm. YAttachment::destroy() calls destroy2() which nullifies next which in turn calls release() for the underlying provider. So AFAIU the connection should be closed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

m_attachment = nullptr;
m_sequence = 0;
m_connected = false;
Expand All @@ -437,7 +442,7 @@ namespace

bool isShutdown() const
{
return (m_attachment == NULL);
return (m_attachment == nullptr);
}

const PathName& getDirectory() const
Expand Down
Loading