[jira] [Closed] (LOG4J2-653) Add plugin builder classes as alternative to factory methods.

[Matt Sicker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Sicker closed LOG4J2-653.
--
   Resolution: Fixed
Fix Version/s: 2.1

Good catch. The infrastructure for this has been in since at least 2.1, so I'll 
go ahead and close this.

> Add plugin builder classes as alternative to factory methods.
> -
>
> Key: LOG4J2-653
> URL: https://issues.apache.org/jira/browse/LOG4J2-653
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>  Labels: config
> Fix For: 2.1
>
>
> It would be useful to have builder-style classes as an alternative to plugin 
> factory methods. This would be useful in two settings:
> # Easier to construct plugins in tests and in the code.
> # Can add annotations to fields for value injection in the PluginBuilder 
> class.
> This could replace the existing factory methods, or it could complement it. 
> This would also make it easier to support programmatic configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Jenkins build is unstable: Log4j 2.x #2019

[Ralph Goers]

Looked at the test again. It had some bugs in it.

Ralph

> On Jun 11, 2016, at 10:22 PM, Ralph Goers  wrote:
> 
> Yes. It creates the file and writes to it. The test should then end and run 
> again. On the second run the file should roll over. The files should both 
> have the header, footer, and same number of lines so they should be the same 
> size.
> 
> Ralph
> 
> On Jun 11, 2016, at 10:08 PM, Remko Popma  > wrote:
> 
>> Hm... this is the second time I see this test fail:
>> Stacktrace
>> 
>> java.lang.AssertionError
>>  at 
>> org.apache.logging.log4j.core.appender.rolling.RollingAppenderOnStartupTest.afterClass(RollingAppenderOnStartupTest.java:85)
>> 
>> What does this test do? It looks like it remembers the size of the first 
>> non-empty file in the directory, and then asserts that all other files are 
>> the same size, is that correct? 
>> 
>> @AfterClass
>> public static void afterClass() throws Exception {
>> long size = 0;
>> try (DirectoryStream directoryStream = 
>> Files.newDirectoryStream(Paths.get("target/onStartup"))) {
>> for (Path path : directoryStream) {
>> if (size == 0) {
>> size = Files.size(path);
>> } else {
>> assertTrue(size == Files.size(path)); // <- line 85 
>> }
>> Files.delete(path);
>> }
>> Files.delete(Paths.get("target/onStartup"));
>> }
>> }
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Sun, Jun 12, 2016 at 1:17 PM, Apache Jenkins Server 
>> > wrote:
>> See > >
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org 
>> 
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org 
>> 
>> 
>> 

Re: Jenkins build is unstable: Log4j 2.x #2019

[Ralph Goers]

Yes. It creates the file and writes to it. The test should then end and run 
again. On the second run the file should roll over. The files should both have 
the header, footer, and same number of lines so they should be the same size.

Ralph

> On Jun 11, 2016, at 10:08 PM, Remko Popma  wrote:
> 
> Hm... this is the second time I see this test fail:
> Stacktrace
> 
> java.lang.AssertionError
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingAppenderOnStartupTest.afterClass(RollingAppenderOnStartupTest.java:85)
> 
> What does this test do? It looks like it remembers the size of the first 
> non-empty file in the directory, and then asserts that all other files are 
> the same size, is that correct? 
> 
> @AfterClass
> public static void afterClass() throws Exception {
> long size = 0;
> try (DirectoryStream directoryStream = 
> Files.newDirectoryStream(Paths.get("target/onStartup"))) {
> for (Path path : directoryStream) {
> if (size == 0) {
> size = Files.size(path);
> } else {
> assertTrue(size == Files.size(path)); // <- line 85 
> }
> Files.delete(path);
> }
> Files.delete(Paths.get("target/onStartup"));
> }
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Sun, Jun 12, 2016 at 1:17 PM, Apache Jenkins Server 
>>  wrote:
>> See 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

Re: Jenkins build is unstable: Log4j 2.x #2019

[Remko Popma]

Hm... this is the second time I see this test fail:
Stacktrace

java.lang.AssertionError
at 
org.apache.logging.log4j.core.appender.rolling.RollingAppenderOnStartupTest.afterClass(RollingAppenderOnStartupTest.java:85)


What does this test do? It looks like it remembers the size of the first
non-empty file in the directory, and then asserts that all other files are
the same size, is that correct?

@AfterClass
public static void afterClass() throws Exception {
long size = 0;
try (DirectoryStream directoryStream =
Files.newDirectoryStream(Paths.get("target/onStartup"))) {
for (Path path : directoryStream) {
if (size == 0) {
size = Files.size(path);
} else {
assertTrue(size == Files.size(path)); // <- line 85
}
Files.delete(path);
}
Files.delete(Paths.get("target/onStartup"));
}
}










On Sun, Jun 12, 2016 at 1:17 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>
>

Jenkins build is unstable: Log4j 2.x #2019

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-548) Log4j 2.0 with JBoss EAP 6.2

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers reassigned LOG4J2-548:
--

Assignee: Ralph Goers

> Log4j 2.0 with  JBoss EAP 6.2
> -
>
> Key: LOG4J2-548
> URL: https://issues.apache.org/jira/browse/LOG4J2-548
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0-rc1, 2.1
> Environment: EJB 3.1 , JBoss EAP 6.2 , Windows 7 , Eclipse Kepler 
>Reporter: Shehata
>Assignee: Ralph Goers
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> When trying to use log4j 2.0-rc1 with EJB3.1 i got Error Message:
> "ERROR StatusLogger Could not search jar file 
> 'jboss-eap-6.2\standalone\deployments\Log4J2Ear.ear\lib\log4j-core-2.0-rc1.jar\org\apache\logging\log4j\core'
>  for classes matching criteria: annotated with @Plugin file not found"
> after debugging the application found that the problem is located in :
> org.apache.logging.log4j.core.config.plugins.ResolverUtil
> method: findInPackage --> line number 247
> the protocol used in the jar is vfs not vfszip



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-823) Changing AsyncLogger level programmatically not working properly

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326166#comment-15326166
 ] 

Ralph Goers commented on LOG4J2-823:


Is this still a problem or has it been resolved in later releases?

> Changing AsyncLogger level programmatically not working properly
> 
>
> Key: LOG4J2-823
> URL: https://issues.apache.org/jira/browse/LOG4J2-823
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.0-rc2
>Reporter: Pranav Pratap
>  Labels: AsyncLogger
>
> I am trying to programmatically change the log level of AsyncLogger. But 
> unable to do so. 
> Programmatically we can change AsyncRoot or Root Log level using below code:
> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>   Configuration config = ctx.getConfiguration();
>   LoggerConfig loggerConfig = 
> config.getLoggerConfig(LogManager.ROOT_LOGGER_NAME);
>   loggerConfig.setLevel(level);
>   ctx.updateLoggers();
> How to achieve the same for AsyncLogger? Please suggest. I searched many 
> forums but all provide the way for Root Level or AsyncRoot Log Level Change. 
> But no once suggest the AsyncLogger logger level change mechanism.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-800) All life cycle implementations should be serializable

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers closed LOG4J2-800.
--
Resolution: Not A Problem

Doesn't seem to be an issue any more.

> All life cycle implementations should be serializable
> -
>
> Key: LOG4J2-800
> URL: https://issues.apache.org/jira/browse/LOG4J2-800
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.2
> Environment: Apache Maven 3.2.3 
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T16:58:10-04:00)
> Maven home: C:\Java\apache-maven-3.2.3
> Java version: 1.7.0_65, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_65\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> All internal life cycle implementations should be serializable:
> {code:java}
> public class AbstractLifeCycle implements LifeCycle, Serializable
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-696) RegexFilter does not match multiline log messages

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326164#comment-15326164
 ] 

Ralph Goers commented on LOG4J2-696:


Assigning to me since it doesn't appear Gary plans on fixing this.

> RegexFilter does not match multiline log messages
> -
>
> Key: LOG4J2-696
> URL: https://issues.apache.org/jira/browse/LOG4J2-696
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.0-rc2
>Reporter: phil wray
>Assignee: Ralph Goers
> Attachments: RegexFilterTest.java
>
>
> RegexFilter is constructed with a pattern, but pattern does not support 
> multiline matches, so impossible for the filter to ever match a multiline msg.
> Should maybe provide a multline="x attribute whichi should default to true 
> and result in the patter being compiled as such:
> Pattern pattern = Pattern.compile(".*line.*", Pattern.DOTALL);
> See attached UnitTest illustrating failure



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-696) RegexFilter does not match multiline log messages

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers reassigned LOG4J2-696:
--

Assignee: Ralph Goers

> RegexFilter does not match multiline log messages
> -
>
> Key: LOG4J2-696
> URL: https://issues.apache.org/jira/browse/LOG4J2-696
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.0-rc2
>Reporter: phil wray
>Assignee: Ralph Goers
> Attachments: RegexFilterTest.java
>
>
> RegexFilter is constructed with a pattern, but pattern does not support 
> multiline matches, so impossible for the filter to ever match a multiline msg.
> Should maybe provide a multline="x attribute whichi should default to true 
> and result in the patter being compiled as such:
> Pattern pattern = Pattern.compile(".*line.*", Pattern.DOTALL);
> See attached UnitTest illustrating failure



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-159) log4j.xml loading from classpath not working correct in osgi environment

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers closed LOG4J2-159.
--
Resolution: Incomplete

Closing this issue due to lack of feedback.

> log4j.xml loading from classpath not working correct in osgi environment
> 
>
> Key: LOG4J2-159
> URL: https://issues.apache.org/jira/browse/LOG4J2-159
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core
>Affects Versions: 2.0-beta3, 2.0-rc1
> Environment: win7, eclipse 3.7 64bit
>Reporter: Jan Winter
>Assignee: Ralph Goers
>Priority: Trivial
> Fix For: 2.3
>
>
> I have problems while loading log4j.xml configuration file in osgi 
> environment. 
> I have the following started equinox container: 
> +
> | osgi> ss log4j 
> | 
> | Framework is launched. 
> | 
> | id  State Bundle 
> | 58  RESOLVED my.log4j.xml.fragment 
> | Master=136 
> | 136 RESOLVED org.apache.commons.log4j-api_2.0.0.beta3 
> | Fragments=58 
> | 137 RESOLVED org.apache.commons.log4j-core_2.0.0.beta3 
> +
> The log4j2 config file is packaged under my.log4j.xml.fragment.jar/log4j.xml. 
> If I have the upper bundle-configuration 
> - than the following output happens: 
> +
> | ERROR StatusLogger Unable to locate a logging implementation, using 
> SimpleLogger 
> | FATAL Log4j_2 log4j-2.0.x logging 
> | ERROR Log4j_2 log4j-2.0.x logging 
> +
> *QUICKFIX* If I update the 
> org.apache.commons.log4j-core_2.0.0.beta3.jar!/META-INF/MANIFEST.MF 
> - append: Fragment-Host: org.apache.commons.log4j-api 
> - than log4j2 configuration is loaded and work. 
> +
> | osgi> ss log4j 
> |
> | Framework is launched. 
> | 
> | id  State Bundle 
> | 58  RESOLVED my.log4j.xml.fragment 
> | Master=136 
> | 136 RESOLVED org.apache.commons.log4j-api_2.0.0.beta3 
> | Fragments=58, 137 
> | 137 RESOLVED org.apache.commons.log4j-core_2.0.0.beta3 
> | Master=136 
> +



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-653) Add plugin builder classes as alternative to factory methods.

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326160#comment-15326160
 ] 

Ralph Goers commented on LOG4J2-653:


This is marked as "In progress" but hasn't been updated in 2 years.

> Add plugin builder classes as alternative to factory methods.
> -
>
> Key: LOG4J2-653
> URL: https://issues.apache.org/jira/browse/LOG4J2-653
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>  Labels: config
>
> It would be useful to have builder-style classes as an alternative to plugin 
> factory methods. This would be useful in two settings:
> # Easier to construct plugins in tests and in the code.
> # Can add annotations to fields for value injection in the PluginBuilder 
> class.
> This could replace the existing factory methods, or it could complement it. 
> This would also make it easier to support programmatic configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-1420) 2.6.1 - NPE due to OnStartupTriggeringPolicy changes

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-1420.
-
   Resolution: Fixed
Fix Version/s: 2.6.2

This has been fixed in master. Please verify and close.

> 2.6.1 - NPE due to OnStartupTriggeringPolicy changes
> 
>
> Key: LOG4J2-1420
> URL: https://issues.apache.org/jira/browse/LOG4J2-1420
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Leon Finker
>Assignee: Ralph Goers
> Fix For: 2.6.2
>
>
> Hi,
> Noticed an NPE with one of our configurations with 2.6.1 (doesn't happen on 
> previous versions). Looks like it's due to changes for LOG4J2-1405. Looks 
> like the file size in RollingFileManager constructor is set before the 
> randomAccessFile in RollingRandomAccessFileManager ctor. And the actual 
> policy triggering happens in RollingFileManager  before the randomAccessFile 
> is assigned:triggeringPolicy.initialize(this); I guess that's why there was 
> somewhat an elaborate logic in previous version of OnStartupTriggeringPolicy 
> and the actual rollover was decided in isTriggeringEvent.
> The NPE always happens with OnStartupTriggeringPolicy and if previous file is 
> not empty.
> {noformat}
> 2016-06-09 13:38:57,060 main ERROR Unable to invoke factory method in class 
> class org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender 
> for element RollingRandomAccessFile. 
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:132)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:918)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:858)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:850)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:479)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:219)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:231)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:491)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
>   at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
>   at 
> org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:103)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:42)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>   at 
> com.tradingscreen.gemfire.server.CacheServer.(CacheServer.java:46)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.close(RollingRandomAccessFileManager.java:128)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:211)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:142)
>   at 
> org.apache.logging.log4j.core.appender.rolling.OnStartupTriggeringPolicy.initialize(OnStartupTriggeringPolicy.java:43)
>   at 
> org.apache.logging.log4j.core.appender.rolling.CompositeTriggeringPolicy.initialize(CompositeTriggeringPolicy.java:49)
>   at 
> 

Build failed in Jenkins: Log4j 2.x #2018

[Apache Jenkins Server]

See 

Changes:

[rgoers] LOG4J-1420 - RollingRandomAccessFileManager was not properly rolling

--
[...truncated 1732 lines...]
jdk1.7.0_51/jre/lib/zi/Asia/Jerusalem
jdk1.7.0_51/jre/lib/zi/Asia/Riyadh
jdk1.7.0_51/jre/lib/zi/Asia/Kamchatka
jdk1.7.0_51/jre/lib/zi/WET
jdk1.7.0_51/jre/lib/zi/PST8PDT
jdk1.7.0_51/jre/lib/images/
jdk1.7.0_51/jre/lib/images/icons/
jdk1.7.0_51/jre/lib/images/icons/sun-java_HighContrast.png
jdk1.7.0_51/jre/lib/images/icons/sun-java_HighContrastInverse.png
jdk1.7.0_51/jre/lib/images/icons/sun-java_LowContrast.png
jdk1.7.0_51/jre/lib/images/icons/sun-java.png
jdk1.7.0_51/jre/lib/images/cursors/
jdk1.7.0_51/jre/lib/images/cursors/motif_MoveDrop32x32.gif
jdk1.7.0_51/jre/lib/images/cursors/cursors.properties
jdk1.7.0_51/jre/lib/images/cursors/motif_MoveNoDrop32x32.gif
jdk1.7.0_51/jre/lib/images/cursors/motif_CopyNoDrop32x32.gif
jdk1.7.0_51/jre/lib/images/cursors/motif_LinkNoDrop32x32.gif
jdk1.7.0_51/jre/lib/images/cursors/motif_LinkDrop32x32.gif
jdk1.7.0_51/jre/lib/images/cursors/invalid32x32.gif
jdk1.7.0_51/jre/lib/images/cursors/motif_CopyDrop32x32.gif
jdk1.7.0_51/jre/lib/jfr.jar
jdk1.7.0_51/jre/lib/jvm.hprof.txt
jdk1.7.0_51/jre/lib/amd64/
jdk1.7.0_51/jre/lib/amd64/libjsoundalsa.so
jdk1.7.0_51/jre/lib/amd64/libkcms.so
jdk1.7.0_51/jre/lib/amd64/libjfxmedia.so
jdk1.7.0_51/jre/lib/amd64/libjpeg.so
jdk1.7.0_51/jre/lib/amd64/libnio.so
jdk1.7.0_51/jre/lib/amd64/libfontmanager.so
jdk1.7.0_51/jre/lib/amd64/libhprof.so
jdk1.7.0_51/jre/lib/amd64/libjsig.so
jdk1.7.0_51/jre/lib/amd64/libinstrument.so
jdk1.7.0_51/jre/lib/amd64/libnet.so
jdk1.7.0_51/jre/lib/amd64/libattach.so
jdk1.7.0_51/jre/lib/amd64/libsaproc.so
jdk1.7.0_51/jre/lib/amd64/jli/
jdk1.7.0_51/jre/lib/amd64/jli/libjli.so
jdk1.7.0_51/jre/lib/amd64/libjfxwebkit.so
jdk1.7.0_51/jre/lib/amd64/libnpt.so
jdk1.7.0_51/jre/lib/amd64/libjavafx-font.so
jdk1.7.0_51/jre/lib/amd64/libawt.so
jdk1.7.0_51/jre/lib/amd64/libprism-es2.so
jdk1.7.0_51/jre/lib/amd64/libsplashscreen.so
jdk1.7.0_51/jre/lib/amd64/libj2pcsc.so
jdk1.7.0_51/jre/lib/amd64/libmlib_image.so
jdk1.7.0_51/jre/lib/amd64/libj2pkcs11.so
jdk1.7.0_51/jre/lib/amd64/libsctp.so
jdk1.7.0_51/jre/lib/amd64/libdt_socket.so
jdk1.7.0_51/jre/lib/amd64/libjavafx-iio.so
jdk1.7.0_51/jre/lib/amd64/libjavaplugin_jni.so
jdk1.7.0_51/jre/lib/amd64/libgstplugins-lite.so
jdk1.7.0_51/jre/lib/amd64/libsunec.so
jdk1.7.0_51/jre/lib/amd64/libnpjp2.so
jdk1.7.0_51/jre/lib/amd64/libdeploy.so
jdk1.7.0_51/jre/lib/amd64/libjava_crw_demo.so
jdk1.7.0_51/jre/lib/amd64/libunpack.so
jdk1.7.0_51/jre/lib/amd64/libjfr.so
jdk1.7.0_51/jre/lib/amd64/libj2gss.so
jdk1.7.0_51/jre/lib/amd64/libt2k.so
jdk1.7.0_51/jre/lib/amd64/libverify.so
jdk1.7.0_51/jre/lib/amd64/libdcpr.so
jdk1.7.0_51/jre/lib/amd64/libjava.so
jdk1.7.0_51/jre/lib/amd64/libJdbcOdbc.so
jdk1.7.0_51/jre/lib/amd64/fxavcodecplugin-52.so
jdk1.7.0_51/jre/lib/amd64/server/
jdk1.7.0_51/jre/lib/amd64/server/libjsig.so
jdk1.7.0_51/jre/lib/amd64/server/Xusage.txt
jdk1.7.0_51/jre/lib/amd64/server/libjvm.so
jdk1.7.0_51/jre/lib/amd64/fxplugins.so
jdk1.7.0_51/jre/lib/amd64/xawt/
jdk1.7.0_51/jre/lib/amd64/xawt/libmawt.so
jdk1.7.0_51/jre/lib/amd64/fxavcodecplugin-53.so
jdk1.7.0_51/jre/lib/amd64/libjaas_unix.so
jdk1.7.0_51/jre/lib/amd64/libgstreamer-lite.so
jdk1.7.0_51/jre/lib/amd64/libmanagement.so
jdk1.7.0_51/jre/lib/amd64/jvm.cfg
jdk1.7.0_51/jre/lib/amd64/libjsdt.so
jdk1.7.0_51/jre/lib/amd64/libzip.so
jdk1.7.0_51/jre/lib/amd64/libglass.so
jdk1.7.0_51/jre/lib/amd64/headless/
jdk1.7.0_51/jre/lib/amd64/headless/libmawt.so
jdk1.7.0_51/jre/lib/amd64/libjsound.so
jdk1.7.0_51/jre/lib/amd64/libjdwp.so
jdk1.7.0_51/jre/lib/amd64/libjawt.so
jdk1.7.0_51/jre/lib/fontconfig.SuSE.10.bfc
jdk1.7.0_51/jre/lib/classlist
jdk1.7.0_51/jre/lib/management-agent.jar
jdk1.7.0_51/jre/lib/javaws.jar
jdk1.7.0_51/jre/lib/psfontj2d.properties
jdk1.7.0_51/jre/lib/rt.jar
jdk1.7.0_51/jre/lib/calendars.properties
jdk1.7.0_51/jre/lib/security/
jdk1.7.0_51/jre/lib/security/local_policy.jar
jdk1.7.0_51/jre/lib/security/trusted.libraries
jdk1.7.0_51/jre/lib/security/javafx.policy
jdk1.7.0_51/jre/lib/security/cacerts
jdk1.7.0_51/jre/lib/security/java.policy
jdk1.7.0_51/jre/lib/security/US_export_policy.jar
jdk1.7.0_51/jre/lib/security/java.security
jdk1.7.0_51/jre/lib/security/blacklist
jdk1.7.0_51/jre/lib/security/javaws.policy
jdk1.7.0_51/jre/lib/jfxrt.jar
jdk1.7.0_51/jre/lib/fontconfig.Turbo.properties.src
jdk1.7.0_51/jre/lib/jfr/
jdk1.7.0_51/jre/lib/jfr/profile.jfc
jdk1.7.0_51/jre/lib/jfr/default.jfc
jdk1.7.0_51/jre/lib/fontconfig.RedHat.5.properties.src
jdk1.7.0_51/jre/lib/net.properties
jdk1.7.0_51/jre/lib/content-types.properties
jdk1.7.0_51/jre/lib/fontconfig.RedHat.5.bfc
jdk1.7.0_51/jre/lib/alt-rt.jar
jdk1.7.0_51/jre/lib/logging.properties
jdk1.7.0_51/jre/lib/applet/
jdk1.7.0_51/jre/lib/cmm/
jdk1.7.0_51/jre/lib/cmm/LINEAR_RGB.pf
jdk1.7.0_51/jre/lib/cmm/GRAY.pf
jdk1.7.0_51/jre/lib/cmm/sRGB.pf
jdk1.7.0_51/jre/lib/cmm/PYCC.pf

[jira] [Commented] (LOG4J2-1397) Support ByteBufferLayout

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326130#comment-15326130
 ] 

Remko Popma commented on LOG4J2-1397:
-

I created LOG4J2-1424 for a more general garbage-free async message transfer 
mechanism.

> Support ByteBufferLayout
> 
>
> Key: LOG4J2-1397
> URL: https://issues.apache.org/jira/browse/LOG4J2-1397
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Layouts
>Affects Versions: 2.6
>Reporter: Remko Popma
>
> As requested by Kirk Pepperdine on the Mechanical Sympathy [mailing 
> list|https://groups.google.com/d/msg/mechanical-sympathy/klefjRqlpQE/-1WF59IGAwAJ]:
> Support a new Layout that takes ObjectMessages containing a ByteBuffer 
> payload and write them to the appender without modification.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1424) Generic Message contents transfer mechanism into Async Logger ringbuffer

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1424:
---

 Summary: Generic Message contents transfer mechanism into Async 
Logger ringbuffer
 Key: LOG4J2-1424
 URL: https://issues.apache.org/jira/browse/LOG4J2-1424
 Project: Log4j 2
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.6
Reporter: Remko Popma


Log4j 2.6 in garbage-free mode uses a reusable message, and transfers the 
message content into the AsyncLogger ringbuffer for consumption by the 
background thread. 

This ticket proposes to make this mechanism more general so it can be used by 
custom messages. 

This will involve 
* Some way for users to populate the ringbuffer with either custom 
RingBufferLogEvents, or by setting the Message field of the RingBufferLogEvents 
to pre-allocated instances.
* Some transfer mechanism to copy the payload of a custom Message that was 
logged by the appliction into the Message field of the RingBufferLogEvent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

compiler warning

[Gary Gregory]

The changes for MessageFactory2 now give the following warnings. I think we
should fix these.

[WARNING]
E:\vcs\git\apache\logging\logging-log4j2\log4j-api\src\main\java\org\apache\logging\log4j\status\StatusLogger.java:[45,13]
[unchecked] getMessageFactory() in AbstractLogger implements
getMessageFactory() in Logger
[WARNING]   return type requires unchecked conversion from MessageFactory2
to MF
  where MF is a type-variable:
MF extends MessageFactory declared in method getMessageFactory()
E:\vcs\git\apache\logging\logging-log4j2\log4j-api\src\main\java\org\apache\logging\log4j\simple\SimpleLogger.java:[37,7]
[unchecked] getMessageFactory() in AbstractLogger implements
getMessageFactory() in Logger
[WARNING]   return type requires unchecked conversion from MessageFactory2
to MF
  where MF is a type-variable:
MF extends MessageFactory declared in method getMessageFactory()

Gary
-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Comment Edited] (LOG4J2-1418) Provide MessageFactory2 to custom Logger implementations

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324932#comment-15324932
 ] 

Remko Popma edited comment on LOG4J2-1418 at 6/11/16 12:03 PM:
---

Gentle reminder: can you also add an entry in changes.xml?



was (Author: rem...@yahoo.com):
Gentle reminder: also add an entry in changes.xml.


> Provide MessageFactory2 to custom Logger implementations
> 
>
> Key: LOG4J2-1418
> URL: https://issues.apache.org/jira/browse/LOG4J2-1418
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.6.2
>
>
> It would be useful for a custom Logger implementation to be able to get hold 
> of a {{MessageFactory2}} (and not just a {{MessageFactory}}), in order to 
> efficiently process {{CharSequence}} etc.
> {{Logger.getMessageFactory()}} return {{MessageFactory}}, even though the 
> sole implementation in {{AbstractLogger}} do have a {{MessageFactory2}} 
> available.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1420) 2.6.1 - NPE due to OnStartupTriggeringPolicy changes

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15325822#comment-15325822
 ] 

Ralph Goers commented on LOG4J2-1420:
-

That is my plan

> 2.6.1 - NPE due to OnStartupTriggeringPolicy changes
> 
>
> Key: LOG4J2-1420
> URL: https://issues.apache.org/jira/browse/LOG4J2-1420
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Leon Finker
>
> Hi,
> Noticed an NPE with one of our configurations with 2.6.1 (doesn't happen on 
> previous versions). Looks like it's due to changes for LOG4J2-1405. Looks 
> like the file size in RollingFileManager constructor is set before the 
> randomAccessFile in RollingRandomAccessFileManager ctor. And the actual 
> policy triggering happens in RollingFileManager  before the randomAccessFile 
> is assigned:triggeringPolicy.initialize(this); I guess that's why there was 
> somewhat an elaborate logic in previous version of OnStartupTriggeringPolicy 
> and the actual rollover was decided in isTriggeringEvent.
> The NPE always happens with OnStartupTriggeringPolicy and if previous file is 
> not empty.
> {noformat}
> 2016-06-09 13:38:57,060 main ERROR Unable to invoke factory method in class 
> class org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender 
> for element RollingRandomAccessFile. 
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:132)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:918)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:858)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:850)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:479)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:219)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:231)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:491)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
>   at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
>   at 
> org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:103)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:42)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>   at 
> com.tradingscreen.gemfire.server.CacheServer.(CacheServer.java:46)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.close(RollingRandomAccessFileManager.java:128)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:211)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:142)
>   at 
> org.apache.logging.log4j.core.appender.rolling.OnStartupTriggeringPolicy.initialize(OnStartupTriggeringPolicy.java:43)
>   at 
> org.apache.logging.log4j.core.appender.rolling.CompositeTriggeringPolicy.initialize(CompositeTriggeringPolicy.java:49)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.(RollingFileManager.java:77)
>   at 
> 

[jira] [Assigned] (LOG4J2-1420) 2.6.1 - NPE due to OnStartupTriggeringPolicy changes

[Ralph Goers (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers reassigned LOG4J2-1420:
---

Assignee: Ralph Goers

> 2.6.1 - NPE due to OnStartupTriggeringPolicy changes
> 
>
> Key: LOG4J2-1420
> URL: https://issues.apache.org/jira/browse/LOG4J2-1420
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Leon Finker
>Assignee: Ralph Goers
>
> Hi,
> Noticed an NPE with one of our configurations with 2.6.1 (doesn't happen on 
> previous versions). Looks like it's due to changes for LOG4J2-1405. Looks 
> like the file size in RollingFileManager constructor is set before the 
> randomAccessFile in RollingRandomAccessFileManager ctor. And the actual 
> policy triggering happens in RollingFileManager  before the randomAccessFile 
> is assigned:triggeringPolicy.initialize(this); I guess that's why there was 
> somewhat an elaborate logic in previous version of OnStartupTriggeringPolicy 
> and the actual rollover was decided in isTriggeringEvent.
> The NPE always happens with OnStartupTriggeringPolicy and if previous file is 
> not empty.
> {noformat}
> 2016-06-09 13:38:57,060 main ERROR Unable to invoke factory method in class 
> class org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender 
> for element RollingRandomAccessFile. 
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:132)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:918)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:858)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:850)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:479)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:219)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:231)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:491)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
>   at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
>   at 
> org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:103)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:42)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>   at 
> com.tradingscreen.gemfire.server.CacheServer.(CacheServer.java:46)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.close(RollingRandomAccessFileManager.java:128)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:211)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:142)
>   at 
> org.apache.logging.log4j.core.appender.rolling.OnStartupTriggeringPolicy.initialize(OnStartupTriggeringPolicy.java:43)
>   at 
> org.apache.logging.log4j.core.appender.rolling.CompositeTriggeringPolicy.initialize(CompositeTriggeringPolicy.java:49)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.(RollingFileManager.java:77)
>   at 
> 

[jira] [Commented] (LOG4J2-1420) 2.6.1 - NPE due to OnStartupTriggeringPolicy changes

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15325787#comment-15325787
 ] 

Remko Popma commented on LOG4J2-1420:
-

Ralph, are you going to take care of this one?

> 2.6.1 - NPE due to OnStartupTriggeringPolicy changes
> 
>
> Key: LOG4J2-1420
> URL: https://issues.apache.org/jira/browse/LOG4J2-1420
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Leon Finker
>
> Hi,
> Noticed an NPE with one of our configurations with 2.6.1 (doesn't happen on 
> previous versions). Looks like it's due to changes for LOG4J2-1405. Looks 
> like the file size in RollingFileManager constructor is set before the 
> randomAccessFile in RollingRandomAccessFileManager ctor. And the actual 
> policy triggering happens in RollingFileManager  before the randomAccessFile 
> is assigned:triggeringPolicy.initialize(this); I guess that's why there was 
> somewhat an elaborate logic in previous version of OnStartupTriggeringPolicy 
> and the actual rollover was decided in isTriggeringEvent.
> The NPE always happens with OnStartupTriggeringPolicy and if previous file is 
> not empty.
> {noformat}
> 2016-06-09 13:38:57,060 main ERROR Unable to invoke factory method in class 
> class org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender 
> for element RollingRandomAccessFile. 
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:132)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:918)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:858)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:850)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:479)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:219)
>   at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:231)
>   at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:491)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
>   at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
>   at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
>   at 
> org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
>   at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>   at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:103)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>   at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:42)
>   at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>   at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>   at 
> com.tradingscreen.gemfire.server.CacheServer.(CacheServer.java:46)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager.close(RollingRandomAccessFileManager.java:128)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:211)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:142)
>   at 
> org.apache.logging.log4j.core.appender.rolling.OnStartupTriggeringPolicy.initialize(OnStartupTriggeringPolicy.java:43)
>   at 
> org.apache.logging.log4j.core.appender.rolling.CompositeTriggeringPolicy.initialize(CompositeTriggeringPolicy.java:49)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.(RollingFileManager.java:77)
>   at 
> 

Re: Jenkins build is still unstable: Log4j 2.x #2017

[Remko Popma]

It's our old friend XZ. 

Sent from my iPhone

> On 2016/06/11, at 18:08, Apache Jenkins Server  
> wrote:
> 
> See 
> 
> 
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
> 

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Jenkins build is still unstable: Log4j 2.x #2017

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1417) Unbox should respect Constants.ENABLE_THREADLOCALS

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1417.
---

> Unbox should respect Constants.ENABLE_THREADLOCALS
> --
>
> Key: LOG4J2-1417
> URL: https://issues.apache.org/jira/browse/LOG4J2-1417
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> The org.apache.logging.log4j.util.Unbox class stores a non-JDK class 
> (Unbox$State) in a static ThreadLocal field.
> This may cause memory leaks in containers which share thread pools between 
> applications.
> One way to accomplish this is to have two ThreadLocal fields: one that stores 
> an array of StringBuilders, and one that stores an AtomicLong to track the 
> current slot.
> (If there is a performance impact we can switch between alternative 
> implementations depending on the value of Constants.ENABLE_THREADLOCALS.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-1417) Unbox should respect Constants.ENABLE_THREADLOCALS

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma resolved LOG4J2-1417.
-
Resolution: Fixed

Added a web-app safe representation for storing StringBuilders in ThreadLocals.

Performance testing showed the original representation is faster with multiple 
threads, so the web-safe representation is only used if 
Constants.ENABLE_THREADLOCALS is false.

*Original representation with 4 threads*
{code}
// java -Dlog4j2.enable.threadlocals=true -jar log4j-perf\target\benchmarks.jar 
".*Unbox.*" -f 1 -wi 10 -i 15 -t 4

Benchmark  Mode  SamplesScore   Error  Units
o.a.l.l.p.j.UnboxBenchmark.boxBooleansample   797504   62.489 ± 1.197  ns/op
o.a.l.l.p.j.UnboxBenchmark.boxDouble sample  1073882  475.165 ± 6.840  ns/op
o.a.l.l.p.j.UnboxBenchmark.boxFloat  sample   998490  279.987 ± 3.992  ns/op
o.a.l.l.p.j.UnboxBenchmark.boxIntsample  1149793   78.770 ± 2.661  ns/op
o.a.l.l.p.j.UnboxBenchmark.boxLong   sample   629717   75.244 ± 0.865  ns/op
o.a.l.l.p.j.UnboxBenchmark.boxShort  sample   685683   69.648 ± 1.057  ns/op
{code}

*Web-safe representation with 4 threads*
{code}
// java -Dlog4j2.enable.threadlocals=false -jar 
log4j-perf\target\benchmarks.jar ".*Unbox.*" -f 1 -wi 10 -i 15 -t 4

Benchmark  Mode  SamplesScoreError  
Units
o.a.l.l.p.j.UnboxBenchmark.boxBooleansample   680750   69.998 ±  4.319  
ns/op
o.a.l.l.p.j.UnboxBenchmark.boxDouble sample  1096977  495.519 ± 11.621  
ns/op
o.a.l.l.p.j.UnboxBenchmark.boxFloat  sample   952154  301.714 ± 12.061  
ns/op
o.a.l.l.p.j.UnboxBenchmark.boxIntsample   912080  102.098 ±  4.950  
ns/op
o.a.l.l.p.j.UnboxBenchmark.boxLong   sample  1016424   95.503 ± 10.432  
ns/op
o.a.l.l.p.j.UnboxBenchmark.boxShort  sample   611588   77.056 ±  2.721  
ns/op
{code}

Fixed in master.

> Unbox should respect Constants.ENABLE_THREADLOCALS
> --
>
> Key: LOG4J2-1417
> URL: https://issues.apache.org/jira/browse/LOG4J2-1417
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> The org.apache.logging.log4j.util.Unbox class stores a non-JDK class 
> (Unbox$State) in a static ThreadLocal field.
> This may cause memory leaks in containers which share thread pools between 
> applications.
> One way to accomplish this is to have two ThreadLocal fields: one that stores 
> an array of StringBuilders, and one that stores an AtomicLong to track the 
> current slot.
> (If there is a performance impact we can switch between alternative 
> implementations depending on the value of Constants.ENABLE_THREADLOCALS.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-1417) Unbox should respect Constants.ENABLE_THREADLOCALS

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reassigned LOG4J2-1417:
---

Assignee: Remko Popma

> Unbox should respect Constants.ENABLE_THREADLOCALS
> --
>
> Key: LOG4J2-1417
> URL: https://issues.apache.org/jira/browse/LOG4J2-1417
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> The org.apache.logging.log4j.util.Unbox class stores a non-JDK class 
> (Unbox$State) in a static ThreadLocal field.
> This may cause memory leaks in containers which share thread pools between 
> applications.
> One way to accomplish this is to have two ThreadLocal fields: one that stores 
> an array of StringBuilders, and one that stores an AtomicLong to track the 
> current slot.
> (If there is a performance impact we can switch between alternative 
> implementations depending on the value of Constants.ENABLE_THREADLOCALS.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1415) Avoid calling toString() on auto-boxed primitive message parameters

[Anthony Maire (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anthony Maire closed LOG4J2-1415.
-

tested on master, it works as expected

> Avoid calling toString() on auto-boxed primitive message parameters
> ---
>
> Key: LOG4J2-1415
> URL: https://issues.apache.org/jira/browse/LOG4J2-1415
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Anthony Maire
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.6.2
>
>
> When using Log4j 2 through the SLF4J binding, the Unboxer mecanism is not 
> available and a parameterized message with a primitive type parameter will be 
> auto-boxed.
> Then this boxed value will be formatted by 
> ParameterFormatter.recursiveDeepToString() and further allocations will happen
> To lower allocation rate for SLF4J users, 
> ParameterFormatter.appendSpecialTypes() should handle boxed primitive types 
> too.
> {code}
> private static boolean appendSpecialTypes(final Object o, final StringBuilder 
> str) {
> ...
> } else if (o instanceof Long) {
> str.append(((Long) o).longValue());
> return true;
> } else if (o instanceof Integer) {
> str.append(((Integer) o).intValue());
> return true;
> } else if (o instanceof Double) {
> str.append(((Double) o).doubleValue());
> return true;
> } // similarly for float, short, boolean and char.
> ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1423) org.apache.logging.log4j.flume.appender.FlumeAppenderTest.testIncompleteBatch hangs

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1423:

Description: 
This test reliably hangs on my Windows 10 laptop. The build never gets past it.

{noformat}
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode):

"Thread-1011" #2057 daemon prio=5 os_prio=0 tid=0x16cd1000 nid=0x4714 
runnable [0x73b0f000]
   java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0xf5952d40> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0xf5952d40> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)

"Thread-1010" #2056 daemon prio=5 os_prio=0 tid=0x16ccc000 nid=0x904 
runnable [0x73a0f000]
   java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.available(Native Method)
at java.io.BufferedInputStream.available(BufferedInputStream.java:410)
- locked <0xf594dad8> (a java.io.BufferedInputStream)
at sun.nio.cs.StreamDecoder.inReady(StreamDecoder.java:363)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:324)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0xf59500e8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0xf59500e8> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)

"Thread-1009" #2055 daemon prio=5 os_prio=0 tid=0x16ccf800 nid=0x50c8 
waiting on condition [0x7390e000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf532cbe8> (a 
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
at 
org.apache.maven.plugin.surefire.booterclient.lazytestprovider.TestProvidingInputStream.awaitNextTest(TestProvidingInputStream.java:173)
at 
org.apache.maven.plugin.surefire.booterclient.lazytestprovider.TestProvidingInputStream.beforeNextCommand(TestProvidingInputStream.java:131)
at 
org.apache.maven.plugin.surefire.booterclient.lazytestprovider.AbstractCommandStream.read(AbstractCommandStream.java:101)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamFeeder.feed(StreamFeeder.java:123)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamFeeder.run(StreamFeeder.java:60)

"ThreadedStreamConsumer" #2052 daemon prio=5 os_prio=0 tid=0x18f85000 
nid=0x40a4 runnable [0x7370e000]
   java.lang.Thread.State: RUNNABLE
at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:142)
at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:115)
at 
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:70)
at java.lang.Thread.run(Thread.java:745)

"surefire-fork-starter" #2050 daemon prio=5 os_prio=0 tid=0x18f81800 
nid=0x285c runnable [0x7360f000]
   java.lang.Thread.State: RUNNABLE
at java.lang.ProcessImpl.waitForInterruptibly(Native Method)
at java.lang.ProcessImpl.waitFor(ProcessImpl.java:449)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:260)
at 

[jira] [Updated] (LOG4J2-1423) org.apache.logging.log4j.flume.appender.FlumeAppenderTest.testIncompleteBatch hangs

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1423:

Environment: 
Apache Maven 3.0.4 (r1232337; 2012-01-17 17:44:56+0900)
Maven home: C:\apps\apache-maven-3.0.4\bin\..
Java version: 1.8.0_51, vendor: Oracle Corporation
Java home: C:\apps\jdk1.8.0_51\jre
Default locale: en_US, platform encoding: MS932
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"

> org.apache.logging.log4j.flume.appender.FlumeAppenderTest.testIncompleteBatch 
> hangs
> ---
>
> Key: LOG4J2-1423
> URL: https://issues.apache.org/jira/browse/LOG4J2-1423
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Flume Appender
>Affects Versions: 2.6, 2.6.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 17:44:56+0900)
> Maven home: C:\apps\apache-maven-3.0.4\bin\..
> Java version: 1.8.0_51, vendor: Oracle Corporation
> Java home: C:\apps\jdk1.8.0_51\jre
> Default locale: en_US, platform encoding: MS932
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
>Reporter: Remko Popma
>
> {noformat}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode):
> "Thread-1011" #2057 daemon prio=5 os_prio=0 tid=0x16cd1000 nid=0x4714 
> runnable [0x73b0f000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:255)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> - locked <0xf5952d40> (a java.io.InputStreamReader)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> - locked <0xf5952d40> (a java.io.InputStreamReader)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
> "Thread-1010" #2056 daemon prio=5 os_prio=0 tid=0x16ccc000 nid=0x904 
> runnable [0x73a0f000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.available(Native Method)
> at java.io.BufferedInputStream.available(BufferedInputStream.java:410)
> - locked <0xf594dad8> (a java.io.BufferedInputStream)
> at sun.nio.cs.StreamDecoder.inReady(StreamDecoder.java:363)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:324)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> - locked <0xf59500e8> (a java.io.InputStreamReader)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> - locked <0xf59500e8> (a java.io.InputStreamReader)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
> "Thread-1009" #2055 daemon prio=5 os_prio=0 tid=0x16ccf800 nid=0x50c8 
> waiting on condition [0x7390e000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0xf532cbe8> (a 
> java.util.concurrent.Semaphore$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
> at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.TestProvidingInputStream.awaitNextTest(TestProvidingInputStream.java:173)
> at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.TestProvidingInputStream.beforeNextCommand(TestProvidingInputStream.java:131)
> at 
> org.apache.maven.plugin.surefire.booterclient.lazytestprovider.AbstractCommandStream.read(AbstractCommandStream.java:101)
> at 
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamFeeder.feed(StreamFeeder.java:123)
> 

[jira] [Created] (LOG4J2-1423) org.apache.logging.log4j.flume.appender.FlumeAppenderTest.testIncompleteBatch hangs

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1423:
---

 Summary: 
org.apache.logging.log4j.flume.appender.FlumeAppenderTest.testIncompleteBatch 
hangs
 Key: LOG4J2-1423
 URL: https://issues.apache.org/jira/browse/LOG4J2-1423
 Project: Log4j 2
  Issue Type: Bug
  Components: Flume Appender
Affects Versions: 2.6.1, 2.6
Reporter: Remko Popma


{noformat}
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode):

"Thread-1011" #2057 daemon prio=5 os_prio=0 tid=0x16cd1000 nid=0x4714 
runnable [0x73b0f000]
   java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0xf5952d40> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0xf5952d40> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)

"Thread-1010" #2056 daemon prio=5 os_prio=0 tid=0x16ccc000 nid=0x904 
runnable [0x73a0f000]
   java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.available(Native Method)
at java.io.BufferedInputStream.available(BufferedInputStream.java:410)
- locked <0xf594dad8> (a java.io.BufferedInputStream)
at sun.nio.cs.StreamDecoder.inReady(StreamDecoder.java:363)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:324)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0xf59500e8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0xf59500e8> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)

"Thread-1009" #2055 daemon prio=5 os_prio=0 tid=0x16ccf800 nid=0x50c8 
waiting on condition [0x7390e000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf532cbe8> (a 
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:312)
at 
org.apache.maven.plugin.surefire.booterclient.lazytestprovider.TestProvidingInputStream.awaitNextTest(TestProvidingInputStream.java:173)
at 
org.apache.maven.plugin.surefire.booterclient.lazytestprovider.TestProvidingInputStream.beforeNextCommand(TestProvidingInputStream.java:131)
at 
org.apache.maven.plugin.surefire.booterclient.lazytestprovider.AbstractCommandStream.read(AbstractCommandStream.java:101)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamFeeder.feed(StreamFeeder.java:123)
at 
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamFeeder.run(StreamFeeder.java:60)

"ThreadedStreamConsumer" #2052 daemon prio=5 os_prio=0 tid=0x18f85000 
nid=0x40a4 runnable [0x7370e000]
   java.lang.Thread.State: RUNNABLE
at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.processLine(ForkClient.java:142)
at 
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:115)
at 
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:70)
at java.lang.Thread.run(Thread.java:745)

"surefire-fork-starter" #2050 daemon prio=5 os_prio=0 tid=0x18f81800 
nid=0x285c runnable [0x7360f000]
   java.lang.Thread.State: RUNNABLE
at java.lang.ProcessImpl.waitForInterruptibly(Native Method)
at java.lang.ProcessImpl.waitFor(ProcessImpl.java:449)
at 

Jenkins build is unstable: Log4j 2.x #2016

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org