Re: Issues with log4j2 socket appender

[Ralph Goers]

Please do not send emails to individuals but please keep your mail on the Log4j 
mailing lists.

In case you are not aware most open source software projects are developed by 
people who are volunteering their time to do so. Some committers at the ASF are 
lucky in that their employers do pay them to work on their projects. In the 
case of Log4j we all work on this in our spare time - we don’t get any monetary 
compensation for what we do. Due to the nature of our paying jobs the amount of 
time we have varies quite a bit. I suspect that at the moment we are all busy. 

Log4j currently has about 450 unresolved issues. Many of these are enhancement 
requests but others are bugs that need to be addressed. It isn’t that we don’t 
want to fix them but we tend to work on what we either think are the biggest 
problems or what we find most interesting. 

So that said, any assistance you can offer will go a long way to moving towards 
a solution on this problem. For example, if you can provide a unit test that 
demonstrates this error it will make it easier to determine what the problem is 
and how to fix it. Even better, provide a patch. I do plan to look at this 
issue but I can provide no assurance on when that will be.

Ralph

> On May 21, 2017, at 8:51 PM, Kulkarni, Girish  wrote:
> 
> Hi Ralph,
>  
> I have got notification that you have closed the post which I have raised it 
> for log4j2 socket appender issue 
> https://issues.apache.org/jira/browse/LOG4J2-1918 
>  saying it is duplicate as 
> already it has raised earlier 
> (https://issues.apache.org/jira/browse/LOG4J2-1311 
> ).
>  
> Could you please let us know update on LOG4J2-1311. 
> 
> We have raised to log4j2-user group also on this issue and did not get any 
> help.  We really appreciate your response for this as we are facing this from 
> last 2 weeks. 
> 
> Regards,
> Girish Kulkarni
>  
> From: Gokhe, Pravin 
> Sent: 19 May 2017 09:37
> To: Kulkarni, Girish; log4j-u...@logging.apache.org 
> ; log4j-...@logging.apache.org 
> 
> Cc: Pyndah, Venkata Rama Krishna
> Subject: RE: Issues with log4j2 socket appender
> Importance: High
>  
> Hi Log4j team,
>  
> We really appreciate your response for below query. Please let us know if you 
> need more details from our side.
> We are facing this issue for almost 2 weeks now and there is limited/no help 
> available on internet
>  
> Thanks in advance.
>  
> Regards,
> Pravin
>  
> From: Kulkarni, Girish 
> Sent: 17 May 2017 20:59
> To: log4j-u...@logging.apache.org ; 
> log4j-...@logging.apache.org 
> Cc: Gokhe, Pravin; Pyndah, Venkata Rama Krishna
> Subject: Issues with log4j2 socket appender
>  
> Hi Team,
>  
> We are facing intermittent lost of logs while sending logs to log target 
> using log4j2 socket appender in our application. The detailed information is 
> as below;
>  
> Our environment:
> 1) In our application, we are using log4j2 (2.7 version jar) framework and 
> SocketAppender (async appender under socket appender) to send logs to Splunk 
> ( Enterprise Logging tool) via radware(load balancer). 
> 2) So our application connects to Radware over TCPIP socket using 
> SocketAppender; Radware is used to load balance load among 4 target Splunk 
> servers.
> 3) Radware Server is configured to timeout if connection is idle for one 
> minute (configurable at radware and set to 1 minute)
> 4) The configuration of log4j2 config file is as below 
>  
>  
> 
> 
> 
>  reconnectDelayMillis="3" immediateFail="false" bufferedIo="true" 
> bufferSize="204800" protocol="TCP" immediateFlush="false">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
> The process/steps of meeting problem:
> 
> 1) Splunk servers, radware server and our application servers are up, and the 
> application servers send logs to radware in turn splunk servers successfully.
> 2) As we didn't do any operation, there is no logs come into radware in one 
> minute ( 1 minute as we set) and radware breaks the connection between it and 
> application server.
> 3) We did an operation so that application server will write one log. However 
> nothing happens, This log didn't come into radware and splunk servers at all.
> 4) We did a second operation so that application server will write the second 
> log. This time also logs did not  come into radware and splunk either.
> 5) After counting for 30 sec (reconnectDelayMillis="3" in log4j2 config 
> file) from first failed log ( i.e the log triggered after radware breaks 
> connection) we did a third operation so that application server will write 
> the third log. This time SocketAppender works well and this log came into 
> radware and splunk servers. This is primarily because application 

Re: Java9

[Ralph Goers]

> On May 21, 2017, at 7:32 PM, Remko Popma  wrote:
> 
> 
>> On May 22, 2017, at 8:57, Ralph Goers  wrote:
>> 
>> When you run the release plugin the artifact is deployed when the module 
>> gets to the deploy phase. Thus any shading would take place too late to do 
>> any good.
> 
> I think there's a misunderstanding: the shade plugin is bound to the package 
> phase, not the deploy phase. So the Java 9 classes would be copied in time 
> (before verify>install>deploy). 
> 
> Would you object to the Java 9 classes going to a separate module if we can 
> get this to work?

No, I did not misunderstand. The Java 9 module has to be built after log4j-api 
as it is dependent on the StackLocator interface. The shading has to be 
completed before the log4j-api is deployed. If you can tell me how you can 
resolve that I’m happy to listen.

Ralph

[jira] [Commented] (LOG4J2-1911) DynamicThresholdFilter defaultThreshold is not used to compare against event's level when there's no matching key found.

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1911:
--

Thank you for the report. 

Can you please provide a patch with a uni test?

> DynamicThresholdFilter defaultThreshold is not used to compare against 
> event's level when there's no matching key found.
> 
>
> Key: LOG4J2-1911
> URL: https://issues.apache.org/jira/browse/LOG4J2-1911
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.8.2
>Reporter: Jerry Chin
>Priority: Minor
>  Labels: documentation, patch
>
> The {{defaultThreshold}} property is not honored as documented :
> {quote}
> defaultThreshold  Level of messages to be filtered. If there is no 
> matching key in the key/value pairs then this level will be compared against 
> the event's level.
> {quote}
> after carefully examining the source code, I found the following code is 
> called:
> {code:title=DynamicThresholdFilter.java|borderStyle=solid}
>  private Result filter(Level level, ReadOnlyStringMap contextMap) {
> String value = (String)contextMap.getValue(this.key);
> if(value != null) {
> Level ctxLevel = (Level)this.levelMap.get(value);
> if(ctxLevel == null) {
> ctxLevel = this.defaultThreshold;
> }
> return 
> level.isMoreSpecificThan(ctxLevel)?this.onMatch:this.onMismatch;
> } else {
> return Result.NEUTRAL;
> }
> }
> {code}
> where level is the event's level, when there's no matching key found 
> {{contextMap}}, {{Result.NEUTRAL}} is mistakenly returned, instead of against 
> {{this.defaultThreshold}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Java9

[Gary Gregory]

On May 21, 2017 7:32 PM, "Remko Popma"  wrote:


> On May 22, 2017, at 8:57, Ralph Goers  wrote:
>
> When you run the release plugin the artifact is deployed when the module
gets to the deploy phase. Thus any shading would take place too late to do
any good.

I think there's a misunderstanding: the shade plugin is bound to the
package phase, not the deploy phase. So the Java 9 classes would be copied
in time (before verify>install>deploy).

Would you object to the Java 9 classes going to a separate module if we can
get this to work?


Feels more hacky to me. There is no clean solution for now. Why not just
let it be for now? Until the next modules vote at least?

Gary



> It could be done if we renamed log4j-api to something else and then
disable the deploy in the module. Then the new log4j-api could create the
jar.  But this all seems messier than what is there now. If you ignore the
Java 9 stuff it should just work in the IDE.
>
> Ralph
>
>> On May 21, 2017, at 4:50 PM, Remko Popma  wrote:
>>
>>
>>> On May 22, 2017, at 5:30, Ralph Goers 
wrote:
>>>
>>> I’m not sure how to make it be any better than this. Although the Java
9 classes could be removed we would just have to put them back in a couple
of months when Java 9 is released. Putting them in a separate module is not
a great option as that will require an additional jar to run in Java 9.
>>
>> Putting the Java 9 classes in a separate module has several advantages.
It would allow IDE's to function in a standard way. It would also make very
clear which JDKs are required to build the project and remove the need for
the toolchain workaround.
>>
>> Together these make the project more approachable for new contributors
which I feel is important for the long term of the project.
>>
>> What remains is a matter of convincing Maven to do what we need:
>> * we _don't_ want this new module to result in a separate artifact in
the distribution. Seems doable: we already do this with log4j-perf.
>> * we _do_ want the Java 9 classes to be included in the log4j-api
artifact. I hope we can do this with maven-shade?
>>
>> Does this make sense?
>>
>> Remko
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>>
>>> Ralph
>>>
 On May 21, 2017, at 1:14 PM, Mikael Ståldal  wrote:

 Same with IntelliJ IDEA. You can set JRE per module (such as
log4j-api, log4j-core), but not per source folder.

 So this is not enough to fix it. But it is better than nothing, so
please keep it. And do the same for tests if/when we add any tests for the
code in src/main/java9.

 I am now able to continue to work with the project in IntelliJ IDEA by
excluding src/main/java9. (But if I work with the Java 9 stuff, I only have
a text editor with syntax highlighting, no other IDE support for that part.)


> On 2017-05-21 14:50, Gary Gregory wrote:
> I set the JRE for that project to Java 9. I do not think you can set
the
> JRE per source folder, only per project.
> Gary
> On May 21, 2017 1:29 AM, "Ralph Goers" 
wrote:
> I’ve modified the build to put the Java 9 classes of the API into a
> separate source directory. Can you see if that helps things in
Eclipse?
> Ralph
>>>
>>>
>>
>
>

Re: Java9

[Remko Popma]

> On May 22, 2017, at 8:57, Ralph Goers  wrote:
> 
> When you run the release plugin the artifact is deployed when the module gets 
> to the deploy phase. Thus any shading would take place too late to do any 
> good.

I think there's a misunderstanding: the shade plugin is bound to the package 
phase, not the deploy phase. So the Java 9 classes would be copied in time 
(before verify>install>deploy). 

Would you object to the Java 9 classes going to a separate module if we can get 
this to work?


> It could be done if we renamed log4j-api to something else and then disable 
> the deploy in the module. Then the new log4j-api could create the jar.  But 
> this all seems messier than what is there now. If you ignore the Java 9 stuff 
> it should just work in the IDE.
> 
> Ralph
> 
>> On May 21, 2017, at 4:50 PM, Remko Popma  wrote:
>> 
>> 
>>> On May 22, 2017, at 5:30, Ralph Goers  wrote:
>>> 
>>> I’m not sure how to make it be any better than this. Although the Java 9 
>>> classes could be removed we would just have to put them back in a couple of 
>>> months when Java 9 is released. Putting them in a separate module is not a 
>>> great option as that will require an additional jar to run in Java 9.
>> 
>> Putting the Java 9 classes in a separate module has several advantages. It 
>> would allow IDE's to function in a standard way. It would also make very 
>> clear which JDKs are required to build the project and remove the need for 
>> the toolchain workaround. 
>> 
>> Together these make the project more approachable for new contributors which 
>> I feel is important for the long term of the project. 
>> 
>> What remains is a matter of convincing Maven to do what we need:
>> * we _don't_ want this new module to result in a separate artifact in the 
>> distribution. Seems doable: we already do this with log4j-perf. 
>> * we _do_ want the Java 9 classes to be included in the log4j-api artifact. 
>> I hope we can do this with maven-shade?
>> 
>> Does this make sense?
>> 
>> Remko 
>> 
>> (Shameless plug) Every java main() method deserves http://picocli.info
>> 
>>> 
>>> Ralph
>>> 
 On May 21, 2017, at 1:14 PM, Mikael Ståldal  wrote:
 
 Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
 log4j-core), but not per source folder.
 
 So this is not enough to fix it. But it is better than nothing, so please 
 keep it. And do the same for tests if/when we add any tests for the code 
 in src/main/java9.
 
 I am now able to continue to work with the project in IntelliJ IDEA by 
 excluding src/main/java9. (But if I work with the Java 9 stuff, I only 
 have a text editor with syntax highlighting, no other IDE support for that 
 part.)
 
 
> On 2017-05-21 14:50, Gary Gregory wrote:
> I set the JRE for that project to Java 9. I do not think you can set the
> JRE per source folder, only per project.
> Gary
> On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:
> I’ve modified the build to put the Java 9 classes of the API into a
> separate source directory. Can you see if that helps things in Eclipse?
> Ralph
>>> 
>>> 
>> 
> 
> 

Re: Java9

[Ralph Goers]

When you run the release plugin the artifact is deployed when the module gets 
to the deploy phase. Thus any shading would take place too late to do any good. 
It could be done if we renamed log4j-api to something else and then disable the 
deploy in the module. Then the new log4j-api could create the jar.  But this 
all seems messier than what is there now. If you ignore the Java 9 stuff it 
should just work in the IDE.

Ralph

> On May 21, 2017, at 4:50 PM, Remko Popma  wrote:
> 
> 
>> On May 22, 2017, at 5:30, Ralph Goers  wrote:
>> 
>> I’m not sure how to make it be any better than this. Although the Java 9 
>> classes could be removed we would just have to put them back in a couple of 
>> months when Java 9 is released. Putting them in a separate module is not a 
>> great option as that will require an additional jar to run in Java 9.
> 
> Putting the Java 9 classes in a separate module has several advantages. It 
> would allow IDE's to function in a standard way. It would also make very 
> clear which JDKs are required to build the project and remove the need for 
> the toolchain workaround. 
> 
> Together these make the project more approachable for new contributors which 
> I feel is important for the long term of the project. 
> 
> What remains is a matter of convincing Maven to do what we need:
> * we _don't_ want this new module to result in a separate artifact in the 
> distribution. Seems doable: we already do this with log4j-perf. 
> * we _do_ want the Java 9 classes to be included in the log4j-api artifact. I 
> hope we can do this with maven-shade?
> 
> Does this make sense?
> 
> Remko 
> 
> (Shameless plug) Every java main() method deserves http://picocli.info
> 
>> 
>> Ralph
>> 
>>> On May 21, 2017, at 1:14 PM, Mikael Ståldal  wrote:
>>> 
>>> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
>>> log4j-core), but not per source folder.
>>> 
>>> So this is not enough to fix it. But it is better than nothing, so please 
>>> keep it. And do the same for tests if/when we add any tests for the code in 
>>> src/main/java9.
>>> 
>>> I am now able to continue to work with the project in IntelliJ IDEA by 
>>> excluding src/main/java9. (But if I work with the Java 9 stuff, I only have 
>>> a text editor with syntax highlighting, no other IDE support for that part.)
>>> 
>>> 
 On 2017-05-21 14:50, Gary Gregory wrote:
 I set the JRE for that project to Java 9. I do not think you can set the
 JRE per source folder, only per project.
 Gary
 On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:
 I’ve modified the build to put the Java 9 classes of the API into a
 separate source directory. Can you see if that helps things in Eclipse?
 Ralph
>> 
>> 
> 

Re: Java9

[Remko Popma]

> On May 22, 2017, at 5:30, Ralph Goers  wrote:
> 
> I’m not sure how to make it be any better than this. Although the Java 9 
> classes could be removed we would just have to put them back in a couple of 
> months when Java 9 is released. Putting them in a separate module is not a 
> great option as that will require an additional jar to run in Java 9.

Putting the Java 9 classes in a separate module has several advantages. It 
would allow IDE's to function in a standard way. It would also make very clear 
which JDKs are required to build the project and remove the need for the 
toolchain workaround. 

Together these make the project more approachable for new contributors which I 
feel is important for the long term of the project. 

What remains is a matter of convincing Maven to do what we need:
* we _don't_ want this new module to result in a separate artifact in the 
distribution. Seems doable: we already do this with log4j-perf. 
* we _do_ want the Java 9 classes to be included in the log4j-api artifact. I 
hope we can do this with maven-shade?

Does this make sense?

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> 
> Ralph
> 
>> On May 21, 2017, at 1:14 PM, Mikael Ståldal  wrote:
>> 
>> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
>> log4j-core), but not per source folder.
>> 
>> So this is not enough to fix it. But it is better than nothing, so please 
>> keep it. And do the same for tests if/when we add any tests for the code in 
>> src/main/java9.
>> 
>> I am now able to continue to work with the project in IntelliJ IDEA by 
>> excluding src/main/java9. (But if I work with the Java 9 stuff, I only have 
>> a text editor with syntax highlighting, no other IDE support for that part.)
>> 
>> 
>>> On 2017-05-21 14:50, Gary Gregory wrote:
>>> I set the JRE for that project to Java 9. I do not think you can set the
>>> JRE per source folder, only per project.
>>> Gary
>>> On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:
>>> I’ve modified the build to put the Java 9 classes of the API into a
>>> separate source directory. Can you see if that helps things in Eclipse?
>>> Ralph
> 
> 

Re: Java 9 modules (again)

[Gary Gregory]

If you see an interesting post on the Jigsaw ML, feel free to post a link
to it here.

Gary

On May 21, 2017 1:45 PM, "Ralph Goers"  wrote:

> I’ve been following the jigsaw mailing list. The consensus on the advice
> I’ve been getting leads me to believe that log4j-api will be able to be a
> “real” module but that log4j core will be an automatic module with just the
> manifest header that declares the name of the module. There is some clean
> up work we might want to do to move things in the API that should be
> private to packages that will not be declared as being exported. However,
> given the state of Jigsaw I think we should be overly cautious and not do
> any work to deliver support for modules until after Java 9 is released. It
> remains to be seen whether the JPMS spec will be approved and what Oracle’s
> reaction to that will be.
>
> Ralph
>
>
>

Re: Java 9 modules (again)

[Gary Gregory]

I like it, let's see what happens with the next module ballot and not sink
too much time into this. I was initially ticked off that my IDE set up go
messed up, but I got over it ;-). I wonder if Oracle would ram it down Java
9's throat anyway...

Gary

On May 21, 2017 1:45 PM, "Ralph Goers"  wrote:

I’ve been following the jigsaw mailing list. The consensus on the advice
I’ve been getting leads me to believe that log4j-api will be able to be a
“real” module but that log4j core will be an automatic module with just the
manifest header that declares the name of the module. There is some clean
up work we might want to do to move things in the API that should be
private to packages that will not be declared as being exported. However,
given the state of Jigsaw I think we should be overly cautious and not do
any work to deliver support for modules until after Java 9 is released. It
remains to be seen whether the JPMS spec will be approved and what Oracle’s
reaction to that will be.

Ralph

Re: Java9

[Gary Gregory]

In Eclipse Oxygen with the Java 9 beta support addon, I setup the log4j-api
project with Java 9 and Java 7 as the target and it works. I have not
checked with the latest Java9 folder though.

We are on the bleeding edge for sure here.

The only part that is not great is that we require Java 9 to be installed
to build. Us that still the case with the new Java 9 folder set up?

This is all good experience anyway. I just want us to keep the release
trains coming knowing our busy schedules. I am slightly worried that we
could be supporting the Jira tickets coming in but that's how life is in an
open source project.

Gary

On May 21, 2017 1:27 PM, "Ralph Goers"  wrote:

> Since src/main/java9 isn’t normally considered a source directory you
> should be able to work with Java 7 as well. It will just ignore the Java 9
> files.
>
> Ralph
>
> > On May 21, 2017, at 5:50 AM, Gary Gregory 
> wrote:
> >
> > I set the JRE for that project to Java 9. I do not think you can set the
> > JRE per source folder, only per project.
> >
> > Gary
> >
> > On May 21, 2017 1:29 AM, "Ralph Goers" 
> wrote:
> >
> > I’ve modified the build to put the Java 9 classes of the API into a
> > separate source directory. Can you see if that helps things in Eclipse?
> >
> > Ralph
>
>
>

Java 9 modules (again)

[Ralph Goers]

I’ve been following the jigsaw mailing list. The consensus on the advice I’ve 
been getting leads me to believe that log4j-api will be able to be a “real” 
module but that log4j core will be an automatic module with just the manifest 
header that declares the name of the module. There is some clean up work we 
might want to do to move things in the API that should be private to packages 
that will not be declared as being exported. However, given the state of Jigsaw 
I think we should be overly cautious and not do any work to deliver support for 
modules until after Java 9 is released. It remains to be seen whether the JPMS 
spec will be approved and what Oracle’s reaction to that will be.

Ralph

Re: Java9

[Ralph Goers]

I’m not sure how to make it be any better than this. Although the Java 9 
classes could be removed we would just have to put them back in a couple of 
months when Java 9 is released. Putting them in a separate module is not a 
great option as that will require an additional jar to run in Java 9.

Ralph

> On May 21, 2017, at 1:14 PM, Mikael Ståldal  wrote:
> 
> Same with IntelliJ IDEA. You can set JRE per module (such as log4j-api, 
> log4j-core), but not per source folder.
> 
> So this is not enough to fix it. But it is better than nothing, so please 
> keep it. And do the same for tests if/when we add any tests for the code in 
> src/main/java9.
> 
> I am now able to continue to work with the project in IntelliJ IDEA by 
> excluding src/main/java9. (But if I work with the Java 9 stuff, I only have a 
> text editor with syntax highlighting, no other IDE support for that part.)
> 
> 
> On 2017-05-21 14:50, Gary Gregory wrote:
>> I set the JRE for that project to Java 9. I do not think you can set the
>> JRE per source folder, only per project.
>> Gary
>> On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:
>> I’ve modified the build to put the Java 9 classes of the API into a
>> separate source directory. Can you see if that helps things in Eclipse?
>> Ralph
> 

Re: Java9

[Ralph Goers]

Since src/main/java9 isn’t normally considered a source directory you should be 
able to work with Java 7 as well. It will just ignore the Java 9 files.

Ralph

> On May 21, 2017, at 5:50 AM, Gary Gregory  wrote:
> 
> I set the JRE for that project to Java 9. I do not think you can set the
> JRE per source folder, only per project.
> 
> Gary
> 
> On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:
> 
> I’ve modified the build to put the Java 9 classes of the API into a
> separate source directory. Can you see if that helps things in Eclipse?
> 
> Ralph

Re: Java9

[Mikael Ståldal]

We need to fix this very soon. It is not acceptable to have the project 
master branch in a state which breaks both of the two most popular Java 
IDEs.


In IntelliJ I now get stuck at com.sun.tools.jconsole.JConsolePlugin not 
found in log4j-jmx-gui.


If we cannot fix this in a timely manner, I suggest we move the 
StackWalker thing into a branch and remove it from master for the time 
being.



On 2017-05-21 14:50, Gary Gregory wrote:

I set the JRE for that project to Java 9. I do not think you can set the
JRE per source folder, only per project.

Gary

On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:

I’ve modified the build to put the Java 9 classes of the API into a
separate source directory. Can you see if that helps things in Eclipse?

Ralph

[jira] [Closed] (LOG4J2-1918) Issues with log4j2 socket appender - Logs are lost when target application closes the tcp connection after idle time

[Ralph Goers (JIRA)]

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

Ralph Goers closed LOG4J2-1918.
---
Resolution: Duplicate

> Issues with log4j2 socket appender - Logs are lost when target application 
> closes the tcp connection after idle time
> 
>
> Key: LOG4J2-1918
> URL: https://issues.apache.org/jira/browse/LOG4J2-1918
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 2.7, 2.8.1, 2.8.2
> Environment: In our application, we are using log4j2 (2.8.1 version 
> jar) framework and SocketAppender (async appender under socket appender) to 
> send logs to Splunk ( Enterprise Logging tool) via radware(load balancer) 
> using tcp protocol. 
>Reporter: Girish
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> We are facing intermittent lost of logs while sending logs to log target 
> using log4j2 socket appender in our application. The detailed information is 
> as below;
>  
> Our environment:
> 1) In our application, we are using log4j2 (2.8.1 version jar) framework and 
> SocketAppender (async appender under socket appender) to send logs to Splunk 
> ( Enterprise Logging tool) via radware(load balancer). 
> 2) So our application connects to Radware over TCPIP socket using 
> SocketAppender; Radware is used to load balance load among 4 target Splunk 
> servers.
> 3) Radware Server is configured to timeout if connection is idle for one 
> minute (configurable at radware and set to 1 minute)
> 4) The configuration of log4j2 config file is as below 
>  
> {code}
> 
>   
> 
>reconnectDelayMillis="3" immediateFail="false" bufferedIo="true" 
> bufferSize="204800" protocol="TCP" immediateFlush="false">
> 
>   
>   
> 
>   
> 
> 
>   
> 
>   
>   
> 
>   
>   
> 
>   
>   
> 
> 
>   
> 
> {code}
>  
> The process/steps of meeting problem:
> 1) Splunk servers, radware server and our application servers are up, and the 
> application servers send logs to radware in turn splunk servers successfully.
> 2) As we didn't do any operation, there is no logs come into radware in one 
> minute ( 1 minute as we set) and radware breaks the connection between it and 
> application server.
> 3) We did an operation so that application server will write one log. However 
> nothing happens, This log didn't come into radware and splunk servers at all.
> 4) We did a second operation so that application server will write the second 
> log. This time also logs did not  come into radware and splunk either.
> 5) After counting for 30 sec (reconnectDelayMillis="3" in log4j2 config 
> file) from first failed log ( i.e the log triggered after radware breaks 
> connection) we did a third operation so that application server will write 
> the third log. This time SocketAppender works well and this log came into 
> radware and splunk servers. This is primarily because application server is 
> able to re-establish connection to Radware after 30 sec as 
> reconnectDelayMillis="3"
>  
> I would like to know why initial logs are lost which are sent after radware 
> connection becomes idle. Ideally, tcp connection created by log4j2 should 
> keep the data in buffer when connection is broken and should send data from 
> buffer when reconnection is established after 30 secs 
> (reconnectDelayMillis="3" )
>  
> We tried setting up parameters like immediateFail="false" bufferedIo="true" 
> bufferSize="204800", so that data can be stored in buffer when radware times 
> out tcp connection and can be sent later when reconnection to radware is 
> established, Unfortunately which is not happening.
>  
> Are we missing any configurations because which we are facing this type of 
> behaviour or is it known defect.
>  
> The similar kind of issue is also observed by others and raised in apache 
> jira(https://issues.apache.org/jira/browse/LOG4J2-1311)
> Context Log:
> {code}
> Listening for transport dt_socket at address: 
> 2017-05-15 17:27:05.706  1 Using jms interface URL: 
> file:/C:/Program%20Files/IBM/IIB/10.0.0.6/server/../common/classes/jms.jar
> 2017-05-15 17:27:05.724  1 Loaded JPLUG
> 2017-05-15 17:27:13.946 49 [15/5/17 17:27:13:397 IST] 0031 
> ObjectGridRAS I   CWOBJ2507I: Trace specification is set to *=off=enabled.
> 2017-05-15 17:27:14,671 Thread-39 DEBUG Initializing configuration 
> XmlConfiguration[location=C:\ProgramData\IBM\MQSI\common\wsrr\log4j2.xml]
> 2017-05-15 17:27:14.686 53 2017-05-15 17:27:14,686 Thread-39 DEBUG 
> Installed script engines
> 2017-05-15 17:27:14.754 53 2017-05-15 17:27:14,754 Thread-39 DEBUG 
> Mozilla Rhino Version: 1.7 release 3 

[jira] [Updated] (LOG4J2-1918) Issues with log4j2 socket appender - Logs are lost when target application closes the tcp connection after idle time

[Ralph Goers (JIRA)]

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

Ralph Goers updated LOG4J2-1918:

Description: 
We are facing intermittent lost of logs while sending logs to log target using 
log4j2 socket appender in our application. The detailed information is as below;
 
Our environment:
1) In our application, we are using log4j2 (2.8.1 version jar) framework and 
SocketAppender (async appender under socket appender) to send logs to Splunk ( 
Enterprise Logging tool) via radware(load balancer). 
2) So our application connects to Radware over TCPIP socket using 
SocketAppender; Radware is used to load balance load among 4 target Splunk 
servers.
3) Radware Server is configured to timeout if connection is idle for one minute 
(configurable at radware and set to 1 minute)
4) The configuration of log4j2 config file is as below 
 
{code}

  

  

  
  

  


  

  
  

  
  

  
  


  

{code}
 
The process/steps of meeting problem:

1) Splunk servers, radware server and our application servers are up, and the 
application servers send logs to radware in turn splunk servers successfully.
2) As we didn't do any operation, there is no logs come into radware in one 
minute ( 1 minute as we set) and radware breaks the connection between it and 
application server.
3) We did an operation so that application server will write one log. However 
nothing happens, This log didn't come into radware and splunk servers at all.
4) We did a second operation so that application server will write the second 
log. This time also logs did not  come into radware and splunk either.
5) After counting for 30 sec (reconnectDelayMillis="3" in log4j2 config 
file) from first failed log ( i.e the log triggered after radware breaks 
connection) we did a third operation so that application server will write the 
third log. This time SocketAppender works well and this log came into radware 
and splunk servers. This is primarily because application server is able to 
re-establish connection to Radware after 30 sec as reconnectDelayMillis="3"
 
I would like to know why initial logs are lost which are sent after radware 
connection becomes idle. Ideally, tcp connection created by log4j2 should keep 
the data in buffer when connection is broken and should send data from buffer 
when reconnection is established after 30 secs (reconnectDelayMillis="3" )
 
We tried setting up parameters like immediateFail="false" bufferedIo="true" 
bufferSize="204800", so that data can be stored in buffer when radware times 
out tcp connection and can be sent later when reconnection to radware is 
established, Unfortunately which is not happening.
 
Are we missing any configurations because which we are facing this type of 
behaviour or is it known defect.
 
The similar kind of issue is also observed by others and raised in apache 
jira(https://issues.apache.org/jira/browse/LOG4J2-1311)

Context Log:
{code}
Listening for transport dt_socket at address: 
2017-05-15 17:27:05.706  1 Using jms interface URL: 
file:/C:/Program%20Files/IBM/IIB/10.0.0.6/server/../common/classes/jms.jar
2017-05-15 17:27:05.724  1 Loaded JPLUG
2017-05-15 17:27:13.946 49 [15/5/17 17:27:13:397 IST] 0031 
ObjectGridRAS I   CWOBJ2507I: Trace specification is set to *=off=enabled.
2017-05-15 17:27:14,671 Thread-39 DEBUG Initializing configuration 
XmlConfiguration[location=C:\ProgramData\IBM\MQSI\common\wsrr\log4j2.xml]
2017-05-15 17:27:14.686 53 2017-05-15 17:27:14,686 Thread-39 DEBUG 
Installed script engines
2017-05-15 17:27:14.754 53 2017-05-15 17:27:14,754 Thread-39 DEBUG Mozilla 
Rhino Version: 1.7 release 3 PRERELEASE, Language: ECMAScript, Threading: 
MULTITHREADED, Compile: true, Names: {js, rhino, JavaScript, javascript, 
ECMAScript, ecmascript}
2017-05-15 17:27:14.756 53 2017-05-15 17:27:14,756 Thread-39 DEBUG 
PluginManager 'Core' found 107 plugins
2017-05-15 17:27:14.757 53 2017-05-15 17:27:14,757 Thread-39 DEBUG 
PluginManager 'Level' found 0 plugins
2017-05-15 17:27:14.765 53 2017-05-15 17:27:14,765 Thread-39 DEBUG 1 
starting Log4j2 ConfigurationScheduler threads
2017-05-15 17:27:14.769 53 2017-05-15 17:27:14,768 Thread-39 DEBUG 
PluginManager 'Lookup' found 13 plugins
2017-05-15 17:27:14.772 53 2017-05-15 17:27:14,772 Thread-39 DEBUG Building 
Plugin[name=layout, class=org.apache.logging.log4j.core.layout.PatternLayout].
2017-05-15 17:27:14.799 53 2017-05-15 17:27:14,798 Thread-39 TRACE 
TypeConverterRegistry initializing.
2017-05-15 17:27:14.800 53 2017-05-15 17:27:14,800 Thread-39 DEBUG 
PluginManager 'TypeConverter' found 23 plugins
2017-05-15 17:27:14.834 53 2017-05-15 17:27:14,834 Thread-39 DEBUG 
PatternLayout$Builder(pattern="null", PatternSelector=null, 

[jira] [Closed] (LOG4J2-1917) Log4j api should use Java's ServiceLoader to locate implememtations

[Ralph Goers (JIRA)]

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

Ralph Goers closed LOG4J2-1917.
---

> Log4j api should use Java's ServiceLoader to locate implememtations
> ---
>
> Key: LOG4J2-1917
> URL: https://issues.apache.org/jira/browse/LOG4J2-1917
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.8.2
>Reporter: Ralph Goers
> Fix For: 2.9
>
>
> Java 9 module support requires that an API locate its implementation using 
> java.util.ServiceLoader. Although we do not plan on implementing module 
> support at this time this change is easy to implement and can be done in a 
> backward compatible manner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Java9

[Gary Gregory]

I set the JRE for that project to Java 9. I do not think you can set the
JRE per source folder, only per project.

Gary

On May 21, 2017 1:29 AM, "Ralph Goers"  wrote:

I’ve modified the build to put the Java 9 classes of the API into a
separate source directory. Can you see if that helps things in Eclipse?

Ralph

[jira] [Resolved] (LOG4J2-1917) Log4j api should use Java's ServiceLoader to locate implememtations

[Ralph Goers (JIRA)]

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

Ralph Goers resolved LOG4J2-1917.
-
Resolution: Fixed

Changes applied.

> Log4j api should use Java's ServiceLoader to locate implememtations
> ---
>
> Key: LOG4J2-1917
> URL: https://issues.apache.org/jira/browse/LOG4J2-1917
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.8.2
>Reporter: Ralph Goers
> Fix For: 2.9
>
>
> Java 9 module support requires that an API locate its implementation using 
> java.util.ServiceLoader. Although we do not plan on implementing module 
> support at this time this change is easy to implement and can be done in a 
> backward compatible manner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Java9

[Ralph Goers]

I’ve modified the build to put the Java 9 classes of the API into a separate 
source directory. Can you see if that helps things in Eclipse?

Ralph

[jira] [Commented] (LOG4J2-1917) Log4j api should use Java's ServiceLoader to locate implememtations

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LOG4J2-1917:
-

Commit 92e4b875463e8dc9e4683687d3572969f39b1593 in logging-log4j2's branch 
refs/heads/master from [~ralph_go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=92e4b87 ]

LOG4J2-1917 - Use ServiceLoader to locate implementations.


> Log4j api should use Java's ServiceLoader to locate implememtations
> ---
>
> Key: LOG4J2-1917
> URL: https://issues.apache.org/jira/browse/LOG4J2-1917
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.8.2
>Reporter: Ralph Goers
> Fix For: 2.9
>
>
> Java 9 module support requires that an API locate its implementation using 
> java.util.ServiceLoader. Although we do not plan on implementing module 
> support at this time this change is easy to implement and can be done in a 
> backward compatible manner.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (LOG4J2-1918) Issues with log4j2 socket appender - Logs are lost when target application closes the tcp connection after idle time

[Girish (JIRA)]

Girish created LOG4J2-1918:
--

 Summary: Issues with log4j2 socket appender - Logs are lost when 
target application closes the tcp connection after idle time
 Key: LOG4J2-1918
 URL: https://issues.apache.org/jira/browse/LOG4J2-1918
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.8.2, 2.8.1, 2.7
 Environment: In our application, we are using log4j2 (2.8.1 version 
jar) framework and SocketAppender (async appender under socket appender) to 
send logs to Splunk ( Enterprise Logging tool) via radware(load balancer) using 
tcp protocol. 


Reporter: Girish


We are facing intermittent lost of logs while sending logs to log target using 
log4j2 socket appender in our application. The detailed information is as below;
 
Our environment:
1) In our application, we are using log4j2 (2.8.1 version jar) framework and 
SocketAppender (async appender under socket appender) to send logs to Splunk ( 
Enterprise Logging tool) via radware(load balancer). 
2) So our application connects to Radware over TCPIP socket using 
SocketAppender; Radware is used to load balance load among 4 target Splunk 
servers.
3) Radware Server is configured to timeout if connection is idle for one minute 
(configurable at radware and set to 1 minute)
4) The configuration of log4j2 config file is as below 
 
 

























 
 
The process/steps of meeting problem:

1) Splunk servers, radware server and our application servers are up, and the 
application servers send logs to radware in turn splunk servers successfully.
2) As we didn't do any operation, there is no logs come into radware in one 
minute ( 1 minute as we set) and radware breaks the connection between it and 
application server.
3) We did an operation so that application server will write one log. However 
nothing happens, This log didn't come into radware and splunk servers at all.
4) We did a second operation so that application server will write the second 
log. This time also logs did not  come into radware and splunk either.
5) After counting for 30 sec (reconnectDelayMillis="3" in log4j2 config 
file) from first failed log ( i.e the log triggered after radware breaks 
connection) we did a third operation so that application server will write the 
third log. This time SocketAppender works well and this log came into radware 
and splunk servers. This is primarily because application server is able to 
re-establish connection to Radware after 30 sec as reconnectDelayMillis="3"
 
I would like to know why initial logs are lost which are sent after radware 
connection becomes idle. Ideally, tcp connection created by log4j2 should keep 
the data in buffer when connection is broken and should send data from buffer 
when reconnection is established after 30 secs (reconnectDelayMillis="3" )
 
We tried setting up parameters like immediateFail="false" bufferedIo="true" 
bufferSize="204800", so that data can be stored in buffer when radware times 
out tcp connection and can be sent later when reconnection to radware is 
established, Unfortunately which is not happening.
 
Are we missing any configurations because which we are facing this type of 
behaviour or is it known defect.
 
The similar kind of issue is also observed by others and raised in apache 
jira(https://issues.apache.org/jira/browse/LOG4J2-1311)

Context Log:

Listening for transport dt_socket at address: 
2017-05-15 17:27:05.706  1 Using jms interface URL: 
file:/C:/Program%20Files/IBM/IIB/10.0.0.6/server/../common/classes/jms.jar
2017-05-15 17:27:05.724  1 Loaded JPLUG
2017-05-15 17:27:13.946 49 [15/5/17 17:27:13:397 IST] 0031 
ObjectGridRAS I   CWOBJ2507I: Trace specification is set to *=off=enabled.
2017-05-15 17:27:14,671 Thread-39 DEBUG Initializing configuration 
XmlConfiguration[location=C:\ProgramData\IBM\MQSI\common\wsrr\log4j2.xml]
2017-05-15 17:27:14.686 53 2017-05-15 17:27:14,686 Thread-39 DEBUG 
Installed script engines
2017-05-15 17:27:14.754 53 2017-05-15 17:27:14,754 Thread-39 DEBUG Mozilla 
Rhino Version: 1.7 release 3 PRERELEASE, Language: ECMAScript, Threading: 
MULTITHREADED, Compile: true, Names: {js, rhino, JavaScript, javascript, 
ECMAScript, ecmascript}
2017-05-15 17:27:14.756 53 2017-05-15 17:27:14,756 Thread-39 DEBUG 
PluginManager 'Core' found 107 plugins
2017-05-15 17:27:14.757 53 2017-05-15 17:27:14,757 Thread-39 DEBUG 
PluginManager 'Level' found 0 plugins
2017-05-15 17:27:14.765 53 2017-05-15 17:27:14,765 Thread-39 DEBUG 1 
starting Log4j2 ConfigurationScheduler threads
2017-05-15 17:27:14.769 53 2017-05-15 17:27:14,768 Thread-39 DEBUG 
PluginManager 'Lookup' found 13 plugins
2017-05-15 17:27:14.772 53 2017-05-15 17:27:14,772 Thread-39 DEBUG Building 
Plugin[name=layout, class=org.apache.logging.log4j.core.layout.PatternLayout].
2017-05-15 17:27:14.799 53 

[jira] [Commented] (LOG4NET-565) Dependency Injection support appender and logger types

[Dominik Psenner (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16018712#comment-16018712
 ] 

Dominik Psenner commented on LOG4NET-565:
-

Would you please refactor your changes so that the actual modifications are in 
a separate commit? At the moment there are huge number of whitespace 
modifications that make it hard/impossible to review the actual feature 
modifications.

> Dependency Injection support appender and logger types
> --
>
> Key: LOG4NET-565
> URL: https://issues.apache.org/jira/browse/LOG4NET-565
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Reporter: Hitesh Chauhan
>  Labels: Enhancement
>
> I have seen demand for dependency injection support in log4net. I have added 
> that behavior to my local repository. And I would like to push that to 
> log4net library.
> e.g. appender configuration
>  name="ServiceAppender" 
> type="LoggingServiceAppender"   
> serviceLocatorType="Log4NetServiceLocator">



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [LOG4NET] gitflow

[Dominik Psenner]

To me the gitflow concept boils down to a way of tydying up the historical
mess that piles up over the years. The branch
feature/RollingFileAppender-NG dates actually back to 2012. I'd be happy
already if we had a naming convention for the different branch types. From
the branch name alone it is at the moment totally unclear what i.e. the
log4net-1.3 branch is actually about. It is written down only somewhere in
the mailing list archives that we have abandoned it.

What do you think about a simple prefix scheme for named branches like
abandoned/x, feature/y, pullrequest/z,..? These are the three kinds of
branches I see at the moment.

On 21 May 2017 6:11 a.m., "Stefan Bodewig"  wrote:

> On 2017-05-19, Dominik Psenner wrote:
>
> > would we like to use gitflow for our named branches? [1]
>
> I've used gitflow in one or two projects at work and we've never really
> come to a situation where having the release branch really helped. Maybe
> because we didn't create bug fix releases on a regular basis and
> creating a branch off the tag when you needed one was not a big burden.
>
> I do like feature branches for changes you work a bit longer on or bug
> fixes you feel may require a hotfix.
>
> I've never really grasped what the tag-only master is good for, tags are
> kept alive in git anyway, you don't need a branch for them.
>
> That being said, I'm not against using gitflow I'm just not convinced of
> the benefits it claims to offer.
>
> Stefan
>