[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender
by Bela Ban (JIRA)
Optimization: make threads return immediately if NAKACK has another active thread for the same sender
-----------------------------------------------------------------------------------------------------
Key: JGRP-457
URL: http://jira.jboss.com/jira/browse/JGRP-457
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.5
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4 days, 19 hours
[JBoss JIRA] (LOGMGR-113) Create a better way to handle a TCP reconnect policy
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-113?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-113:
---------------------------------
Fix Version/s: 2.1.0.Alpha4
(was: 2.1.0.Alpha3)
> Create a better way to handle a TCP reconnect policy
> ----------------------------------------------------
>
> Key: LOGMGR-113
> URL: https://issues.jboss.org/browse/LOGMGR-113
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: James Perkins
> Fix For: 2.1.0.Alpha4
>
>
> The audit logger in WildFly uses it's own policy to reconnect a TCP connection for the {{SyslogHandler}}. The current {{org.jboss.logmanager.handlers.TcpOutputStream}} handles a reconnection on it's own unless a deprecated constructor is used. A way to set some kind of policy or enable the reconnection to be turned off should be added.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (LOGMGR-52) Add option to WriterHandler to collapse repeated messages
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-52?page=com.atlassian.jira.plugin.... ]
James Perkins updated LOGMGR-52:
--------------------------------
Fix Version/s: 2.1.0.Alpha4
(was: 2.1.0.Alpha3)
> Add option to WriterHandler to collapse repeated messages
> ---------------------------------------------------------
>
> Key: LOGMGR-52
> URL: https://issues.jboss.org/browse/LOGMGR-52
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 2.1.0.Alpha4
>
>
> The WriterHandler could have a time interval configured wherein a repeated message would be collapsed.
> The last message would be stored in a field for comparison along with a nanoTime tag (the timestamp on the message is not adequate because the clock can have skew or be reset completely at any time). If the current message string equals the last message string, and collapsing is enabled, then instead of logging the message, a count is incremented. If the current message is not equal, then the stored message is logged with a tag indicating the number of repeats (i18n?) and then the next submitted message is logged.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month