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 > >> > > >
