Making a method synchronized typically isn't the preferred solution to concurrency issues due to the performance penalty it typically imposes. Generally targeted locks are better. However, concurrency issues are often quite difficult to diagnose and resolve so sometimes a less-than-ideal solution is better than broken code.
I currently have a large PR [1] for MQTT 5 support that is yet to be merged. Once that is merged I'll take a closer look at the deadlock issue from ARTEMIS-3622 that you reported. Justin [1] https://github.com/apache/activemq-artemis/pull/3907 On Thu, Jan 20, 2022 at 11:08 AM Takeshi Fukushima <takesh...@gmail.com> wrote: > Hello everyone > > Last month I've opened up a ticket regarding a deadlock that was occurring > on one of our servers. > https://issues.apache.org/jira/browse/ARTEMIS-3622 > > After much trial and error, I think I've narrowed it down the cause and > it's in the comments, but being a racing condition I cannot reliably > reproduce in a test case. I can reproduce manually (carefully advancing the > threads in the debugger). > > I also did patch our server with the quickfix indicated in the comments and > I will let you know if that fixes the problem (so far so good, but its been > only about 18 hours). If everything goes well, I will create a PR but I > would like to know if a simple solution like that (marking a couple of > methods as synchronized) would be acceptable, even though I think it > doesn't fixes all the cases (that one would require much in depth changes I > think). > > Thanks for the great software anyway, > takeshi > > -- > http://mapsdev.blogspot.com/ > Marcelo Takeshi Fukushima >
