Hi Clebert, Yeah, I can use whatever I want after I prove it out in lower environments.
Thanks, Ben On Mon, Jun 6, 2022 at 10:06 PM Clebert Suconic <clebert.suco...@gmail.com> wrote: > Can you use jdk 11? > > On Mon, Jun 6, 2022 at 8:32 PM Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > > You are likely hitting the bug I fixed at: > > > > https://github.com/apache/activemq-artemis/pull/4098 > > > > I introduced a Thread Local Leakage. I thought by setting > > threadLocal.set(null) I would be clearing it... and in fact I just > > updated the threadLocal variable with null. > > > > That ThreadLocal is created for every new session. > > > > > > I was going to start a release today but I couldn't start it today as > > I'm a bit sick today. I should be able to start a release tomorrow and > > then you could try it out. > > > > > > your other option would be to cherry-pick the change and build the > > version yourself so you can run it in production. > > > > On Fri, Jun 3, 2022 at 4:27 PM Francesco Nigro <nigro....@gmail.com> > > wrote: > > > > > > Some more info about it here https://netty.io/wiki/tcp-fast-open.html > > > > > > Given that Netty can makes use of it and Artemis can as well: if it's > not > > > present in the doc it means we need to expose it in the acceptor > > > configuration (for epoll) and...we love contributions :) > > > But I suggest first to give it a shot first in a test env to see if it > > > solves your problem! > > > > > > Il ven 3 giu 2022, 22:21 Ben Warrick <horseatingwe...@gmail.com> ha > > scritto: > > > > > > > Hi Francesco, > > > > > > > > I don't find anything in the Artemis docs about TCP_FAST_OPEN. It > must > > not > > > > be an exposed configuration on Artemis? Where do I find more on this? > > > > > > > > Thanks, > > > > > > > > Ben > > > > > > > > On Fri, Jun 3, 2022 at 4:08 PM Francesco Nigro <nigro....@gmail.com> > > > > wrote: > > > > > > > > > Are coming, not commenting: typo introduced by the the phone, > sorry! > > > > > > > > > > Il ven 3 giu 2022, 22:07 Francesco Nigro <nigro....@gmail.com> ha > > > > scritto: > > > > > > > > > > > Hi Ben, > > > > > > > > > > > > You can use TCP_FAST_OPEN on Artemis acceptors in case > connections > > are > > > > > > commenting from the came clients (I don't remember if is an > exposes > > > > Netty > > > > > > configuration) or...submit a PR to let Artemis separate > (multiple) > > > > > threads > > > > > > to accept connections but, as you said, this is just an > > anti-pattern > > > > and > > > > > in > > > > > > order to reduce the client code you can think about using a > > transparent > > > > > > connection pooling mechanism, instead. > > > > > > > > > > > > > > > > > > Il ven 3 giu 2022, 21:55 Ben Warrick <horseatingwe...@gmail.com> > > ha > > > > > > scritto: > > > > > > > > > > > >> I'm running Artemis 2.14, and one of the systems publishing to > it > > > > > creates > > > > > >> a > > > > > >> lot of separate tasks -- from its perspective. I can see on > > Artemis > > > > that > > > > > >> the Total connection count vs Total messages acknowledged is > > pretty > > > > > close, > > > > > >> so it's apparent that the client system is making use of the > > > > > anti-pattern > > > > > >> of creating a new connection for each message it publishes. I > > don't > > > > have > > > > > >> access to the client system implementation, but is there > anything > > I > > > > can > > > > > do > > > > > >> on the Artemis end to make it more efficient? Latency with this > > system > > > > > is > > > > > >> becoming an issue. Also every 30 minutes or so there is a spike > > in CPU > > > > > >> usage (~50%) which I assume is garbage collection. During that > > spike > > > > > >> message publishing slows down a lot. > > > > > >> > > > > > >> Thanks, > > > > > >> > > > > > >> Ben > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > -- > > Clebert Suconic > > > -- > Clebert Suconic >
