Jenkins build became unstable: Log4j 2.x #2385

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

Re: In memory appender

The IgniteCache looks richer than both the stock Cache and EhCache for sure: https://ignite.apache.org/releases/1.7.0/javadoc/org/apache/ignite/IgniteCache.html I am not sure I like having to basically use a map with a AtomicLong sequence key I need to manage AND THEN sort the map keys when what I

[jira] [Commented] (LOG4J2-1613) Replace usage of deprecated org.apache.logging.log4j.core.LogEvent.getContextMap()

[ https://issues.apache.org/jira/browse/LOG4J2-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15524928#comment-15524928 ] Gary Gregory commented on LOG4J2-1613: -- [~rem...@yahoo.com]: Do you want this one?

Re: In memory appender

Hazelcast has a Queue implementation. On 26 September 2016 at 22:21, Gary Gregory wrote: > The IgniteCache looks richer than both the stock Cache and EhCache for > sure: https://ignite.apache.org/releases/1.7.0/javadoc/ > org/apache/ignite/IgniteCache.html > > I am not sure I like having to basi

Re: In memory appender

Chronicle is not a cache. Which is good because you don't want a cache if I understand your use case. Chronicle is like an in-memory appender that never runs out of memory. The existing Chronicle Logger appender (https://github.com/OpenHFT/Chronicle-Logger) actually looks like a good fit for

Re: In memory appender

You could use that too but you will need to build more infrastructure. What Chronicle offers is that you can have independent reader and writer threads that essentially talk to each other via a persisted chunk of memory. Chronicle takes care that these threads don't step on each other's toes: t

Re: In memory appender

Here my issue with Chronicle, in net.openhft.chronicle.logger.log4j2.AbstractBinaryChronicleAppender.doAppend(LogEvent, ChronicleLogWriter) you have: @Override public void doAppend(@NotNull final LogEvent event, @NotNull final ChronicleLogWriter writer) { writer.write(

Re: [VOTE] Release Log4j 2.7-rc1

Based in the src distribution: MD5, SHA1, ASC OK. mvn clean install OK. BUT I had to hack the tset org.apache.log4j.config. Log4j1ConfigurationFactoryTest.testSystemProperties2() and add a "appender.stop(10, TimeUnit.SECONDS);" to get the test to pass; this is pushed to Git master. RAT check OK.

Re: In memory appender

Did you look at the ignite queue API link I sent Sent from my iPad > On Sep 26, 2016, at 8:21 PM, Gary Gregory wrote: > > The IgniteCache looks richer than both the stock Cache and EhCache for sure: > https://ignite.apache.org/releases/1.7.0/javadoc/org/apache/ignite/IgniteCache.html > > I am

Re: [VOTE] Release Log4j 2.7-rc1

When I looked at it the Log4j1Configuration stuff said it was experimental so if it has issues I don’t think it matters. Believe it or not I have never run mvn test all by itself. I pretty much only do mvn clean install. So I have no idea if this is new or has always been this way. Ralph > On

Re: [VOTE] Release Log4j 2.7-rc1

That OSGi test failure could be related to the fix for LOG4J2-351, though I'm surprised it hasn't caused a test failure until now. On 26 September 2016 at 23:42, Ralph Goers wrote: > When I looked at it the Log4j1Configuration stuff said it was experimental > so if it has issues I don’t think it

Re: [VOTE] Release Log4j 2.7-rc1

Matt, note that it didn’t fail when Gary ran mvn clean install. If you run mvn install -DskipTests followed by mvn test it fails. This tells me there is something funny going on in the tests that requires the tests to be run as part of the full lifecycle. Ralph > On Sep 26, 2016, at 9:51 P

Re: In memory appender

On Mon, Sep 26, 2016 at 9:20 PM, Ralph Goers wrote: > Did you look at the ignite queue API link I sent > Yes, and the neat thing about the IgniteQueue is that it is a Collection, so you can use it as the backing implementation of a CollectionAppender. My CollectionAppender experiment uses an op

Re: In memory appender

Could AsyncAppender be adapted for this use case? On Mon, Sep 26, 2016 at 12:44 AM, Remko Popma wrote: > That sounds like quite a unique use case! > > Would it make sense to go through a few iterations at your company until > you have something that you're really happy with (to use and to suppor

[jira] [Created] (LOG4J2-1612) log4j.dtd is invalid

Kip created LOG4J2-1612: --- Summary: log4j.dtd is invalid Key: LOG4J2-1612 URL: https://issues.apache.org/jira/browse/LOG4J2-1612 Project: Log4j 2 Issue Type: Bug Reporter: Kip In the last

[VOTE] Release Log4j 2.7-rc1

This is a vote to release Log4j 2.6.2, the next version of the Log4j 2 project. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... The vote will remain open for 72 hours (or more if required). All votes are welcom

Re: In memory appender

AsyncAppender is just a wrapper around any other Appender. So I don't see why it couldn't be used here. On 26 September 2016 at 04:50, Mikael Ståldal wrote: > Could AsyncAppender be adapted for this use case? > > On Mon, Sep 26, 2016 at 12:44 AM, Remko Popma > wrote: > >> That sounds like quite

[jira] [Commented] (LOG4J2-1612) log4j.dtd is invalid

[ https://issues.apache.org/jira/browse/LOG4J2-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15523442#comment-15523442 ] Remko Popma commented on LOG4J2-1612: - I checked the code repository and this file ha

Re: [VOTE] Release Log4j 2.7-rc1

I blogged "A sneak peak into Log4j 2.7 " with a link to the JAX Innovation Awards voting page since the vote closes in a few days. Please share. Remko On Tue, Sep 27, 2016 at 12:50 AM, Ralph Goers w

Re: [VOTE] Release Log4j 2.7-rc1

On Mon, Sep 26, 2016 at 8:50 AM, Ralph Goers wrote: > This is a vote to release Log4j 2.6.2, the next version of the Log4j 2 > project. > You mean 2.7... ;-) Gary > > Please download, test, and cast your votes on the log4j developers list. > [] +1, release the artifacts > [] -1, don't release

Re: [VOTE] Release Log4j 2.7-rc1

Yes. That is what cut & paste does to you… :-) Ralph > On Sep 26, 2016, at 10:27 AM, Gary Gregory wrote: > > > > On Mon, Sep 26, 2016 at 8:50 AM, Ralph Goers > wrote: > This is a vote to release Log4j 2.6.2, the next version of the Log4j 2 > project. > >

[jira] [Commented] (LOG4J2-1612) log4j.dtd is invalid

[ https://issues.apache.org/jira/browse/LOG4J2-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15524024#comment-15524024 ] Kip commented on LOG4J2-1612: - Hmm... I just tried a clean build in Eclipse and it is working

Re: In memory appender

On Sun, Sep 25, 2016 at 3:44 PM, Remko Popma wrote: > That sounds like quite a unique use case! > > Would it make sense to go through a few iterations at your company until > you have something that you're really happy with (to use and to support) > before publishing it in Log4j? > Right now I a

Re: In memory appender

Please allow me to restate the use case I have for the CollectionAppender, which is separate from any Flume-based or Syslog-based solution, use cases I also have. Well, I have a Syslog use case, and whether or not Flume is in the picture will really be a larger discussion in my organization due to

[jira] [Closed] (LOG4J2-1612) log4j.dtd is invalid

[ https://issues.apache.org/jira/browse/LOG4J2-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed LOG4J2-1612. --- Resolution: Not A Problem Closed per user. > log4j.dtd is invalid > > >

Re: In memory appender

Well, the key to this is “proprietary socket protocol”. Today, the Flume appender does everything you want except that it is hardwired to use the Avro RpcClient to send a batch of Flume events. If you need some other protocol you would need to write a new variation of the FlumeManager that send

[jira] [Created] (LOG4J2-1613) Replace usage of deprecated org.apache.logging.log4j.core.LogEvent.getContextMap()

Gary Gregory created LOG4J2-1613: Summary: Replace usage of deprecated org.apache.logging.log4j.core.LogEvent.getContextMap() Key: LOG4J2-1613 URL: https://issues.apache.org/jira/browse/LOG4J2-1613 Pr

Re: In memory appender

So: I write a custom FlumeManager (and add a new FlumeAppender.ManagerType enum called CUSTOM where I can plug in my own class name through a new attribute to be named later). I extract some of the logic out of the FlumeAvroManager for its batch processing logic. My FlumeManager does not send Flum

[jira] [Commented] (LOG4J2-741) Reinstate the package attribute for discovering custom plugins

[ https://issues.apache.org/jira/browse/LOG4J2-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15524467#comment-15524467 ] Frank Conover commented on LOG4J2-741: -- I am experiencing this issue with 2.6.3 and I

[jira] [Commented] (LOG4J2-741) Reinstate the package attribute for discovering custom plugins

[ https://issues.apache.org/jira/browse/LOG4J2-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15524498#comment-15524498 ] Remko Popma commented on LOG4J2-741: We may need to do some digging with extra debug

Re: In memory appender

In addition to the Flume based solution, here is another alternative idea: use Peter Lawrey's Chronicle[1] library to store log events in a memory mapped file. The appender can just keep adding events without worrying about overflowing the memory. The client that reads from this file can be

Re: In memory appender

oh... what about our own http://logging.apache.org/log4j/2.x/manual/appenders.html#MemoryMappedFileAppender ? Gary On Mon, Sep 26, 2016 at 4:59 PM, Remko Popma wrote: > In addition to the Flume based solution, here is another alternative idea: > use Peter Lawrey's Chronicle[1] library to store

Re: In memory appender

I thought you didn’t want to write to a file? The Chronicle stuff Remko is linking to is also worth exploring. Ralph > On Sep 26, 2016, at 5:04 PM, Gary Gregory wrote: > > oh... what about our own > http://logging.apache.org/log4j/2.x/manual/appenders.html#MemoryMappedFileAppender > >

Re: In memory appender

Chronicle seems similar to Apache Ignite in that it is a distributed cache except that Ignite looks like it does a lot more. It does implement a distributed queue - http://apacheignite.gridgain.org/v1.1/docs/queue-and-set . Ralph > On S

Re: In memory appender

On Mon, Sep 26, 2016 at 5:21 PM, Ralph Goers wrote: > I thought you didn’t want to write to a file? > I do not but if the buffer is large enough, log events should stay in RAM. But it is not quite right anyway because I'd have to interpret the contents of the file to turn back into log events.

Re: In memory appender

On Mon, Sep 26, 2016 at 6:09 PM, Gary Gregory wrote: > On Mon, Sep 26, 2016 at 5:21 PM, Ralph Goers > wrote: > >> I thought you didn’t want to write to a file? >> > > I do not but if the buffer is large enough, log events should stay in RAM. > But it is not quite right anyway because I'd have to

[jira] [Created] (LOG4J2-1614) Package attribute for discovering custom plugins within jars fails

Frank Conover created LOG4J2-1614: - Summary: Package attribute for discovering custom plugins within jars fails Key: LOG4J2-1614 URL: https://issues.apache.org/jira/browse/LOG4J2-1614 Project: Log4j 2

Re: In memory appender

On Mon, Sep 26, 2016 at 6:10 PM, Gary Gregory wrote: > On Mon, Sep 26, 2016 at 6:09 PM, Gary Gregory > wrote: > >> On Mon, Sep 26, 2016 at 5:21 PM, Ralph Goers >> wrote: >> >>> I thought you didn’t want to write to a file? >>> >> >> I do not but if the buffer is large enough, log events should

Re: In memory appender

Ignite is a JSR 107 cache and has some benefits over ehcache. Ehcache requires you set preferIPv4Stack to true for it to work. That might be a problem for your client. Sent from my iPad > On Sep 26, 2016, at 7:18 PM, Gary Gregory wrote: > > >> On Mon, Sep 26, 2016 at 6:10 PM, Gary Gregory