[
https://issues.apache.org/jira/browse/LOGCXX-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458533#comment-17458533
]
Truman Lackey edited comment on LOGCXX-537 at 12/13/21, 5:09 PM:
-----------------------------------------------------------------
[~rmiddleton] Couple of other things I noticed.
In SocketAppenderSkeleton::monitor() there is a thread::sleep_for and an
interrupt.wait_for both have the recconnectDelay argument passed in. This is
causing the reconnect time to double.
in SocketAppenderSkeleton::close()
{code:c++}
std::unique_lock<std::mutex> lock2(interrupt_mutex);
interrupt.notify_all();
{code}
Is the lock needed?
When I test against the [LOGCXX-537
|https://github.com/apache/logging-log4cxx/tree/LOGCXX-537] branch if I kill my
test receiver and start it up again messages are not be received.
Changing void SocketAppenderSkeleton::fireConnectorInternal() to the following
fixes this:
{code:c++}
void SocketAppenderSkeleton::fireConnectorInternal(){
if ( !thread.joinable() )
{
LogLog::debug(LOG4CXX_STR("Connector thread not alive: starting
monitor."));
thread = ThreadUtility::instance()->createThread(
LOG4CXX_STR("SocketAppend"), &SocketAppenderSkeleton::monitor, this );
}
else {
interrupt.notify_all();
thread.join();
thread = ThreadUtility::instance()->createThread(
LOG4CXX_STR("SocketAppend"), &SocketAppenderSkeleton::monitor, this );
}
}
{code}
There might be a cleaner way to handle this. Hopefully this gives some insight
into the thread state to have it restart monitoring.
was (Author: JIRAUSER281485):
[~rmiddleton] Couple of other things I noticed.
In SocketAppenderSkeleton::monitor() there is a thread::sleep_for and an
interrupt.wait_for both have the recconnectDelay argument passed in. This is
causing the reconnect time to double.
in SocketAppenderSkeleton::close()
{code:c++}
std::unique_lock<std::mutex> lock2(interrupt_mutex);
interrupt.notify_all();
{code}
Is the lock needed?
When I test against the [LOGCXX-537
|https://github.com/apache/logging-log4cxx/tree/LOGCXX-537] branch if I kill my
test receiver and start it up again messages are not be received.
Changing void SocketAppenderSkeleton::fireConnectorInternal() to the following
fixes this:
{code:c++}
void SocketAppenderSkeleton::fireConnectorInternal(){
if ( !thread.joinable() )
{
LogLog::debug(LOG4CXX_STR("Connector thread not alive: starting
monitor."));
thread = ThreadUtility::instance()->createThread(
LOG4CXX_STR("SocketAppend"), &SocketAppenderSkeleton::monitor, this );
}
else {
interrupt.notify_all();
thread.join();
thread = ThreadUtility::instance()->createThread(
LOG4CXX_STR("SocketAppend"), &SocketAppenderSkeleton::monitor, this );
}
}
{code}
> double mutex lock
> -----------------
>
> Key: LOGCXX-537
> URL: https://issues.apache.org/jira/browse/LOGCXX-537
> Project: Log4cxx
> Issue Type: Bug
> Components: Appender
> Affects Versions: 0.12.1
> Environment: Ubuntu 18.04
> Reporter: Truman Lackey
> Priority: Major
> Fix For: 0.13.0
>
>
> There is a possibility of the SocketAppender calling
> std::unique_lock<log4cxx::shared_mutex> lock(mutex) twice causing a deadlock
> exception. In socketappenderskeleton.cpp connect call if the exception is
> caught on line 118 then fireConnector() will be called. On line 160 the
> mutex is attempted to be locked again but it has already been locked in the
> appendersleketo.cpp doAppend call. This causes log4cxx to throw a
> std::err::resource_deadlock_would_occur
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
