Can you share the 2 locking threads plz? Le 17 févr. 2018 16:41, "Romain Manni-Bucau" <[email protected]> a écrit :
> What do you run? Always green here :( > > Le 17 févr. 2018 11:51, "Mark Struberg" <[email protected]> a > écrit : > >> Yes, been deterministic. At my own box but also on Reinhards. Broken 100% >> of all runs. >> >> LieGrue, >> strub >> >> >> > Am 17.02.2018 um 11:16 schrieb Romain Manni-Bucau < >> [email protected]>: >> > >> > Le 17 févr. 2018 10:09, "Mark Struberg" <[email protected]> a >> > écrit : >> > >> > In the test there are 2 classloaders involved. >> > a.) the client side >> > b.) the server (tomcat). >> > >> > with the setExtension using the current TCCL we kind of leak the Tomcat >> CL >> > into the client it seems. >> > It blows up with the Tomcat ParallelWebAppClassloader already not being >> > active anymore. >> > And the location where this happens is on the client side (transforming >> the >> > attachment FROM jsonb to object). >> > >> > i've also seen random CL errors in our real world project in the last >> week. >> > Might have something to do as well... >> > >> > >> > In webapp case then cause in classpath mode it should be the same. >> > >> > Issue is more the client inherit from the default bus instead of using >> its >> > own bus but it always has been this way. Isnt it a side effect of >> creating >> > a classloader to run tests in parallel? >> > >> > Are you able to reproduce it deterministicly? >> > >> > >> > >> > LieGrue, >> > strub >> > >> >> Am 17.02.2018 um 09:41 schrieb Romain Manni-Bucau < >> [email protected]>: >> >> >> >> Le 16 févr. 2018 22:07, "Mark Struberg" <[email protected]> a >> >> écrit : >> >> >> >> Hi Romain! >> >> >> >> Reinhard managed to reproduce the issue when running the latest MW >> source >> >> on his box. >> >> >> >> With git-bisect we figured it has to do with r1822816 >> >> >> >> MeecrowaveBus >> >> "simplifying MeecrowaveBus and enforcing the classloader to avoid to >> rely >> >> on resource in ServletController when unneeded" >> >> >> >> The main change is to move the TCCL resolution and calling >> setExtension. >> >> This seems to break the Tomcat ParallelWebAppClassLoader. >> >> Rather it seems that the cleanup then is being performed on the tomcat >> >> side, even if the server is already shut down. >> >> >> >> I gonna revert this change for now to make all tests pass again. >> >> But tbh I have no clue what setExtension does in detail so plz review >> it. >> >> >> >> >> >> >> >> This is the classloader usee by the cxf deployment everywhere. If not >> det >> >> it is trivial not have a broken setup during all the other loading and >> >> deployment. >> >> >> >> How does it lock parallel loading? I cant reproduce it. >> >> >> >> >> >> >> >> >> >> >> >> >> >> LieGrue, >> >> strub & Reinhard >> >> >> >> >> >>> Am 16.02.2018 um 15:42 schrieb Mark Struberg >> <[email protected]>: >> >>> >> >>> -DreuseForks=false indeed lets the problem go away. >> >>> >> >>> Now we need to find out where this side effect is coming from. >> >>> >> >>> LieGrue, >> >>> strub >> >>> >> >>>> Am 16.02.2018 um 14:31 schrieb Romain Manni-Bucau < >> [email protected] >> >>> : >> >>>> >> >>>> Hi Mark, can't reproduce it but used a johnzon 1.1.6 created from the >> >>>> 1.1.7-SNAPSHOT since the tag is not pushed on asf yet. Not sure it >> has >> > an >> >>>> impact or if it is the test order which is responsible of it.Maybe >> try >> >>>> forcing reuseFork=false in surefire to validate this hypothesis >> >>>> >> >>>> >> >>>> Romain Manni-Bucau >> >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> >>>> <https://rmannibucau.metawerx.net/> | Old Blog >> >>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/ >> >> rmannibucau> | >> >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> >>>> <https://www.packtpub.com/application-development/java- >> >> ee-8-high-performance> >> >>>> >> >>>> 2018-02-16 13:56 GMT+01:00 Mark Struberg <[email protected] >> >: >> >>>> >> >>>>> no worries, we first have to fix a seemingly random test failure in >> MW >> >>>>> anyway >> >>>>> >> >>>>> Tests in error: >> >>>>> MultipartTest.configBinding:51 » ResponseProcessing Problem with >> > reading >> >>>>> the d... >> >>>>> >> >>>>> happens only when this test is executed with all other tests. >> >>>>> Wenn running the test alone all is green. >> >>>>> >> >>>>> Anyone want's to take that up? >> >>>>> I'm offline for the next few hours now. >> >>>>> >> >>>>> LieGrue, >> >>>>> strub >> >>>>> >> >>>>> >> >>>>>> Am 16.02.2018 um 13:49 schrieb Romain Manni-Bucau < >> >> [email protected] >> >>>>>> : >> >>>>>> >> >>>>>> +1 >> >>>>>> >> >>>>>> Side note: can you ensure it is either not deployed or staging repo >> > are >> >>>>> in >> >>>>>> the pom to not break early consumers please? >> >>>>>> >> >>>>>> >> >>>>>> Le 16 févr. 2018 13:19, "Mark Struberg" <[email protected]> >> a >> >>>>>> écrit : >> >>>>>> >> >>>>>>> will roll a MW release in the afternoon. >> >>>>>>> >> >>>>>>> Currently testing the updates to the staged versions. >> >>>>>>> >> >>>>>>> LieGrue, >> >>>>>>> strub >> >>
