yes, works over here as well
txs and LieGrue,strub
On Sunday, 18 February 2018, 18:55:20 CET, Reinhard Sandtner
<[email protected]> wrote:
works on my machine too ;)
thx romain
lg
reini
> Am 18.02.2018 um 18:01 schrieb Romain Manni-Bucau <[email protected]>:
>
> Fixed, was related to some test order. A test was using cxf in a close
> callback and creating a default bus since we already cleaned out bus. Issue
> was that the default bus doesnt have johnzon etc and the test was using
> jsonb.
>
>
> 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-17 22:16 GMT+01:00 Romain Manni-Bucau <[email protected]>:
>
>> Java8 131 ubuntu and mvn 3.5.2 or idea 2017.2.
>>
>> Le 17 févr. 2018 20:12, "Mark Struberg" <[email protected]> a écrit :
>>
>>> and broke it again ;)
>>>
>>> NFORMATION: Setting the server's publish address to be /
>>> [20:09:15.645][INFO ][ main][ifecycle.WebContainerLifecycle]
>>> OpenWebBeans Container has started, it took [23] ms.
>>> [20:09:15.647][INFO ][ main][meecrowave.cxf.CxfCdiAutoSetup]
>>> REST Application: / -> org.apache.cxf.cdi.DefaultApplication
>>> [20:09:15.647][INFO ][ main][meecrowave.cxf.CxfCdiAutoSetup]
>>> Service URI: /MultipartTest -> org.apache.meecrowave.Multipar
>>> tTest$MultiEndpoint
>>> [20:09:15.647][INFO ][ main][meecrowave.cxf.CxfCdiAutoSetup]
>>> GET /MultipartTest/ -> Map<String, Object> getBooks()
>>> [20:09:16.659][INFO ][ main][ifecycle.WebContainerLifecycle]
>>> OpenWebBeans Container was stopped for context path, []
>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.135 sec
>>> <<< FAILURE! - in org.apache.meecrowave.MultipartTest
>>> configBinding(org.apache.meecrowave.MultipartTest) Time elapsed: 1.135
>>> sec <<< ERROR!
>>> java.lang.NullPointerException
>>> at org.apache.meecrowave.MultipartTest.configBinding(MultipartT
>>> est.java:53)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:62)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>>> FrameworkMethod.java:50)
>>> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl
>>> ectiveCallable.java:12)
>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr
>>> ameworkMethod.java:47)
>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(
>>> InvokeMethod.java:17)
>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>>> 4ClassRunner.java:78)
>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>>> 4ClassRunner.java:57)
>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>
>>>
>>> We need to figure out why your box is green.
>>> Which jdk do you use? and OS?
>>>
>>> Been here on MacBook + Java8-144 and Linux (Fedora27) also java8.
>>> Both broken..
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> On Saturday, 17 February 2018, 19:00:07 CET, Romain Manni-Bucau <
>>> [email protected]> wrote:
>>>
>>>
>>> pushed a fix reverting the revert ;)
>>>
>>> changes are
>>>
>>> 1. we take the classloader from the servlet context instead of the tccl ->
>>> should be noop but way more secured
>>> 2. if there is no default bus we set one, avoids the server one to ends up
>>> being a default classloader and leaking, we also reset it if we set it
>>>
>>> hope it should fix most of the issues
>>>
>>>
>>> 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-17 16:48 GMT+01:00 Romain Manni-Bucau <[email protected]>:
>>>
>>>> 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
>>>>>>
>>>>>>
>>>
>>
