Hi When it becomes virtual threads and Threadlocal to select with
Virtual threads is great option To clarify more Cluster is no message between the nodes but synchronized the cluster Regards Koti On Fri, 5 May 2023, 20:58 Mark Thomas, <ma...@apache.org> wrote: > Hi all, > > I've started to review the use of ThreadLocal within the Tomcat code > base given that using virtual threads will soon be an option. > > The first usage I came to raised a few questions. The usage is in > ApplicationContext: > > > https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/core/ApplicationContext.java#L418 > > My first question - mostly for Rémy - is can you remember why this is a > ThreadLocal. I admit that is a bit of an ask since the use of > ThreadLocal dates back almost 20 years to this commit: > > > https://svn.apache.org/viewvc/tomcat/archive/tc5.5.x/trunk/container/catalina/src/share/org/apache/catalina/core/ApplicationContext.java?r1=301883&r2=301884&; > > My guess, is that a ThreadLocal was used as a way to cache instances of > MappingData and MessageBytes between requests - recycle and reuse rather > than GC. Is that right? > > The second question is what do we want to do about usages such as this. > With virtual threads the end result will be, effectively, a new object > for every request. Do we: > > a) Leave the code as-is. It will work as currently with a thread pool > and virtual threads will effectively create new objects for each request. > > b) Drop the ThreadLocal and always create new objects. > > c) Switch to some other form of caching. My starting point would be > SynchropnizedStack. That may see some contention as it will be global > rather than per thread. Then again, ThreadLocal some overhead too. > > Given these optimization decisions were made 20 years ago and JVMs, > especially GC, have moved on since then, I'm leaning towards option b) > with c) as the fall-back if performance issues are discovered. > > Thoughts? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
