Re: [log4j] Recycler and Scoped Values (JEP 429)

[Carter Kozak]

Thanks for raising this, Volkan. I agree with your assessment that scoped 
values won't be very helpful for object pooling.

The first sentence of https://openjdk.org/jeps/446 states:
> Introduce scoped values, which enable the sharing of immutable data within 
> and across threads.

The key pieces of the description are "immutable data" and "across threads".  
We pool objects (rather than using singletons) because they are required to be 
stateful: acquired, used/mutated, reset, and returned. While threadlocal gives 
us some level of threadsafety (no other thread can acquire a value from the 
current threads threadlocal), the scoped value may be read from all threads in 
the scope -- the general advantage is that data isn't duplicated, and doesn't 
need to be because it's immutable, so it may safely be shared, however this 
characteristic makes it unhelpful for recyclers where it's important that at 
most a single consumer can acquire an object at any point in time.

I suspect scoped values may work nicely for detecting recursive logging (even 
across async appender threads in a way that our current threadlocal cannot 
detect) but I don't want to distract from the intent of this thread!

Best,
-ck

On Mon, May 29, 2023, at 15:48, Volkan Yazıcı wrote:
> Hello,
> 
> In #1401  against the
> `main` branch, I am working on moving JSON Template Layout's "recycler"
> concept to `log4j-core` and replacing all `ThreadLocal` usage with that. We
> want to know if there are opportunities to take advantage of scoped values
> (SVs), which will be introduced with JEP 429, and if so, accommodate them
> in the recycler abstraction.
> 
> In its current form, the recycler is designed to offer [reusable] object
> pooling to facilitate garbage-free logging. Log4j components (appenders,
> layouts, etc.) will work against the recycler API and users will either
> choose one of the provided implementations (no-op, concurrent queue, queue
> in a `ThreadLocal`) or provide theirs.
> 
> I am not able to see how SVs would help us with object pooling and, hence,
> the recycler API. I would appreciate some feedback on this.
> 
> Kind regards.

Re: Facing issue in while doing migration log4j 1.x to 2.x

[Nishu Gupta]

Hi All,

Here is the log4j and lo4j2 xml.

I need a help for how jms call trigger?

regards,
Nishu


From: Nishu Gupta 
Sent: Wednesday, May 24, 2023 10:17 AM
To: Piotr P. Karwasz ; dev@logging.apache.org 

Cc: log4j-user-h...@logging.apache.org 
Subject: Re: Facing issue in while doing migration log4j 1.x to 2.x

Hi Piotr,

Thanks for the response.

Currently we are using log4j1.2.17 jar, and PFA log4j.xml used in 1.x.

For 1.x to 2.x I replace the above jar with the below jar.

Jar
log4j-1.2-api-2.20.0.jar
log4j-api-2.20.0.jar
log4j-core-2.20.0.jar
log4j-slf4j-impl-2.20.0.jar

I did the set the `log4j1.compatibility` to `true` in the custom properties.

Do I need to use the log4j.xml while using the bridge jar? or I need to convert 
to log4j2.xml as well?

Regards,
Nishu



From: Piotr P. Karwasz 
Sent: Friday, May 19, 2023 9:41 PM
To: dev@logging.apache.org 
Cc: Nishu Gupta 
Subject: Re: Facing issue in while doing migration log4j 1.x to 2.x

Hi Volkan,

On Fri, 19 May 2023 at 15:22, Volkan Yazıcı  wrote:
>1. As indicated in the Log4j support page
>, `
>dev@logging.apache.org` mailing list is used for development-related
>discussions. In the future, please use `log4j-u...@logging.apache.org`
>instead.

Actually Nishu cross-posted his question to both mailing lists, but I
answered only on `log4j-user`.

Piotr

http://jakarta.apache.org/log4j/;>
   
  
  
   
  



   


  
  
   
  
  
 
 
  


   


  
  
   
  
  
 
 
  

   
   


  
  
   
  
  
 
 
  

   


  
  
   
  
  
 
 
  


   


  
  
   
  
  
 
 
  































































  

  
  



  
  
  

  
  



  
  
  

  
  



  
  
  

  
  



  
  
  

  
  





[%d{MMM dd,  h:mm:ss:a z}] [%X{SM_USER}-%X{MS}]  [%p]  [%C]  [%m]%n