[
https://issues.apache.org/jira/browse/LOG4J2-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068766#comment-15068766
]
Ralph Goers edited comment on LOG4J2-1230 at 12/22/15 9:38 PM:
---------------------------------------------------------------
The read lock accomplishes nothing. There used to be a write lock as well that
was used to allow the manager to be replaced. You removed that method and the
write lock in May of 2014. The read lock should have been removed at the same
time as it was only there to insure the manager wasn't changed in the middle of
an append.
Currently, there is nothing that makes the manager.write() and manager.flush()
act as an atomic operation, so it is possible to have multiple threads calling
manager.write() simultaneously, which means more data than was anticipated
could be queued for writing.
One solution to this would be to introduce a new manager.write method that
takes the byte array and a boolean value indicating whether an immediate write
is required. Then the locking could be pushed to the appropriate manager if it
is required.
was (Author: [email protected]):
The read lock accomplishes nothing. There used to be a write lock as well that
was used to allow the manager to be replaced. You removed that method and the
write lock in May of 2014. The read lock should have been removed at the same
time as it was only there to insure the manager wasn't changed in the middle of
an append.
Currently, there is nothing that makes the manager.write() and manager.flush()
act as an atomic operation, so it is possible to have multiple threads calling
manager.write() simultaneously, which means more data than was anticipated
could be queued for writing.
> Concatenated SYSLOG Messages
> ----------------------------
>
> Key: LOG4J2-1230
> URL: https://issues.apache.org/jira/browse/LOG4J2-1230
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.5
> Environment: Linux, Java7, WebLogic 12
> Reporter: Vladimir Hudec
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> Under heavy traffic load several SYSLOG messages can be concatenated, which
> is not correct.
> The problem is, several threads in {{AbstractOutputStreamAppender}} can reach
> in the next code {{write()}} before one thread reaches {{flush()}} (the
> {{readLock.lock()}} is not lock at all)
> {code:java}
> @Override
> public void append(final LogEvent event) {
> readLock.lock();
> try {
> final byte[] bytes = getLayout().toByteArray(event);
> if (bytes.length > 0) {
> manager.write(bytes);
> if (this.immediateFlush || event.isEndOfBatch()) {
> manager.flush();
> }
> }
> } catch (final AppenderLoggingException ex) {
> error("Unable to write to stream " + manager.getName() + " for
> appender " + getName());
> throw ex;
> } finally {
> readLock.unlock();
> }
> }
> {code}
> In DatagramOutputStream all messages are cumulated in instance variable
> {{private byte[] data;}}
> Synchronized methods don't help and in this case the synchronization in
> {{DatagramOutputStream}} is useless, as the correct synchronization should be
> provided in {{AbstractOutputStreamAppender}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
