You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2014/07/21 08:41:52 UTC
failling deltaspike-fullstack
Hi
this sample is failing on buildbot cause we don't find all jars from the
app in the classloader (which is wrong since it is embedded ;)).
Here is the info:
INFO - Creating dedicated application classloader for classpath.ear
It is in Assembler if someone wants to have a look , look for this:
if (skipLoaderIfPossible) { ...
Surely a File.equals issue or something like that.
We can log all files in debug mode and activate debug for this sample
to go further
wdyt?
I'll try to find some time to debug further tonight if nobody already did it
Then we should be green everywhere even on trunk ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
Re: failling deltaspike-fullstack
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Regarding deltaspike sample I found something interesting:
app urls are using x1 repo:
FINE - -> file:/x1/buildslave18/repository/org/apache/deltaspike/modules/deltaspike-jsf-module-api/1.0.1/deltaspike-jsf-module-api-1.0.1.jar
and we test them against home m2 repo:
FINE - -> /home/buildslave18/.m2/repository/org/apache/deltaspike/modules/deltaspike-jsf-module-api/1.0.1/deltaspike-jsf-module-api-1.0.1.jar
Now we need to understand why we have these two setup with maven on buildbot
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-07-21 15:19 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> good catch!
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-07-21 15:13 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>
>> StatelessInstanceManagerPoolingTest - I have it, and how obvious these
>> things are when you find them! :-D
>>
>> javax.ejb.ConcurrentAccessTimeoutException in the threads due to 100ms
>> timeout - It's not checked, and so explode is/was not always called.
>>
>> Andy.
>>
>>
>>
>> On 21/07/2014 13:22, Romain Manni-Bucau wrote:
>>>
>>> hehe, now I think to it you are surely right ;)
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>> 2014-07-21 13:19 GMT+02:00 Jean-Louis Monteiro
>>> <jl...@tomitribe.com>:
>>>
>>>> Which channel? That was maybe the reason :p
>>>>
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>>
>>>>
>>>> On Mon, Jul 21, 2014 at 1:17 PM, Romain Manni-Bucau
>>>> <rmannibucau@gmail.com
>>>> wrote:
>>>>
>>>>> well the point is we shouldn't end the method without ensuring all
>>>>> thread
>>>>> are done. join is brutal but the most sure way to do so.
>>>>>
>>>>> Main issue on this test is buildbot since locally it fails very very
>>>>
>>>> rarely
>>>>>
>>>>> (got it once watching tv on the computer during the build ;))
>>>>>
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2014-07-21 12:47 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> Side note: I have been looking at the 'sometimes' failing
>>>>>> StatelessInstanceManagerPoolingTest.
>>>>>>
>>>>>> The issue is not the Thread.join, I tried the same fix but does not
>>>>
>>>> work
>>>>>
>>>>> -
>>>>>>
>>>>>> If we join on each thread then we get a better chance, but only due to
>>>>>> forcing threads to run sequentially and timing.
>>>>>> The issue is the the teardown is called which calls OpenEJB.destroy.
>>>>
>>>> The
>>>>>>
>>>>>> shutdown does not take into account running call contexts and they get
>>>>>> interrupted.
>>>>>> This kills the threads in the 'explode' call and more often than not
>>>>
>>>> they
>>>>>>
>>>>>> never complete - discardedInstances.incrementAndGet() never gets
>>>>>> called
>>>>>> in this case, and the test fails.
>>>>>> It seems wrong to me for the destroy to be so aggressive, it should
>>>>>
>>>>> surely
>>>>>>
>>>>>> give call context threads some time to complete.
>>>>>>
>>>>>> Andy.
>>>>>>
>>>>>>
>>>>>> On 21/07/2014 10:17, Romain Manni-Bucau wrote:
>>>>>>
>>>>>>> 1.7 is affected as well, we just have luck sometimes since this code
>>>>
>>>> is
>>>>>>>
>>>>>>> the
>>>>>>> same. (depend test ordering for some of them but code was clearly
>>>>
>>>> wrong)
>>>>>>>
>>>>>>> I mainly focused on trunk since it showed some bugs of the 1.7 we
>>>>
>>>> can't
>>>>>>>
>>>>>>> see
>>>>>>> while we don't run tests against java 7. All are fixed excepted this
>>>>
>>>> one
>>>>>>>
>>>>>>> which should be trivial once we have the paths.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>> 2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <
>>>>>
>>>>> jlmonteiro@tomitribe.com
>>>>>>>>
>>>>>>>> :
>>>>>>>
>>>>>>> Looks like we are having issues with examples and I was wondering
>>>>>>> why
>>>>>>>>
>>>>>>>> suddenly.
>>>>>>>> Regarding Apache DS fullstack example, I can give that a try if Andy
>>>>>
>>>>> does
>>>>>>>>
>>>>>>>> not have time.
>>>>>>>>
>>>>>>>> Well, while trunk is important, I think we must focus on the branch
>>>>>
>>>>> until
>>>>>>>>
>>>>>>>> it gets released.
>>>>>>>>
>>>>>>>> Jean-Louis
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean-Louis Monteiro
>>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>>> http://www.tomitribe.com
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <
>>>>>>>> rmannibucau@gmail.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> this sample is failing on buildbot cause we don't find all jars
>>>>>>>>> from
>>>>>
>>>>> the
>>>>>>>>>
>>>>>>>>> app in the classloader (which is wrong since it is embedded ;)).
>>>>>>>>>
>>>>>>>>> Here is the info:
>>>>>>>>>
>>>>>>>>> INFO - Creating dedicated application classloader for classpath.ear
>>>>>>>>>
>>>>>>>>> It is in Assembler if someone wants to have a look , look for this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> if (skipLoaderIfPossible) { ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Surely a File.equals issue or something like that.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We can log all files in debug mode and activate debug for this
>>>>
>>>> sample
>>>>>>>>>
>>>>>>>>> to go further
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> wdyt?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'll try to find some time to debug further tonight if nobody
>>>>
>>>> already
>>>>>>>>>
>>>>>>>>> did
>>>>>>>>> it
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then we should be green everywhere even on trunk ;)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>> --
>>>>>> Andy Gumbrecht
>>>>>>
>>>>>> http://www.tomitribe.com
>>>>>> agumbrecht@tomitribe.com
>>>>>> https://twitter.com/AndyGeeDe
>>>>>>
>>>>>> TomEE treibt Tomitribe! | http://tomee.apache.org
>>>>>>
>>>>>>
>>
>> --
>> Andy Gumbrecht
>>
>> http://www.tomitribe.com
>> agumbrecht@tomitribe.com
>> https://twitter.com/AndyGeeDe
>>
>> TomEE treibt Tomitribe! | http://tomee.apache.org
>>
>
Re: failling deltaspike-fullstack
Posted by Romain Manni-Bucau <rm...@gmail.com>.
good catch!
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-07-21 15:13 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> StatelessInstanceManagerPoolingTest - I have it, and how obvious these
> things are when you find them! :-D
>
> javax.ejb.ConcurrentAccessTimeoutException in the threads due to 100ms
> timeout - It's not checked, and so explode is/was not always called.
>
> Andy.
>
>
>
> On 21/07/2014 13:22, Romain Manni-Bucau wrote:
>
>> hehe, now I think to it you are surely right ;)
>>
>>
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>> 2014-07-21 13:19 GMT+02:00 Jean-Louis Monteiro <jlmonteiro@tomitribe.com
>> >:
>>
>> Which channel? That was maybe the reason :p
>>>
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>>
>>>
>>> On Mon, Jul 21, 2014 at 1:17 PM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com
>>> wrote:
>>>
>>> well the point is we shouldn't end the method without ensuring all
>>>> thread
>>>> are done. join is brutal but the most sure way to do so.
>>>>
>>>> Main issue on this test is buildbot since locally it fails very very
>>>>
>>> rarely
>>>
>>>> (got it once watching tv on the computer during the build ;))
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>> 2014-07-21 12:47 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>>
>>>> +1
>>>>>
>>>>> Side note: I have been looking at the 'sometimes' failing
>>>>> StatelessInstanceManagerPoolingTest.
>>>>>
>>>>> The issue is not the Thread.join, I tried the same fix but does not
>>>>>
>>>> work
>>>
>>>> -
>>>>
>>>>> If we join on each thread then we get a better chance, but only due to
>>>>> forcing threads to run sequentially and timing.
>>>>> The issue is the the teardown is called which calls OpenEJB.destroy.
>>>>>
>>>> The
>>>
>>>> shutdown does not take into account running call contexts and they get
>>>>> interrupted.
>>>>> This kills the threads in the 'explode' call and more often than not
>>>>>
>>>> they
>>>
>>>> never complete - discardedInstances.incrementAndGet() never gets called
>>>>> in this case, and the test fails.
>>>>> It seems wrong to me for the destroy to be so aggressive, it should
>>>>>
>>>> surely
>>>>
>>>>> give call context threads some time to complete.
>>>>>
>>>>> Andy.
>>>>>
>>>>>
>>>>> On 21/07/2014 10:17, Romain Manni-Bucau wrote:
>>>>>
>>>>> 1.7 is affected as well, we just have luck sometimes since this code
>>>>>>
>>>>> is
>>>
>>>> the
>>>>>> same. (depend test ordering for some of them but code was clearly
>>>>>>
>>>>> wrong)
>>>
>>>> I mainly focused on trunk since it showed some bugs of the 1.7 we
>>>>>>
>>>>> can't
>>>
>>>> see
>>>>>> while we don't run tests against java 7. All are fixed excepted this
>>>>>>
>>>>> one
>>>
>>>> which should be trivial once we have the paths.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> Twitter: @rmannibucau
>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>> Github: https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>> 2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <
>>>>>>
>>>>> jlmonteiro@tomitribe.com
>>>>
>>>>> :
>>>>>>>
>>>>>> Looks like we are having issues with examples and I was wondering
>>>>>> why
>>>>>>
>>>>>>> suddenly.
>>>>>>> Regarding Apache DS fullstack example, I can give that a try if Andy
>>>>>>>
>>>>>> does
>>>>
>>>>> not have time.
>>>>>>>
>>>>>>> Well, while trunk is important, I think we must focus on the branch
>>>>>>>
>>>>>> until
>>>>
>>>>> it gets released.
>>>>>>>
>>>>>>> Jean-Louis
>>>>>>>
>>>>>>> --
>>>>>>> Jean-Louis Monteiro
>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>> http://www.tomitribe.com
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <
>>>>>>> rmannibucau@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>>> this sample is failing on buildbot cause we don't find all jars from
>>>>>>>>
>>>>>>> the
>>>>
>>>>> app in the classloader (which is wrong since it is embedded ;)).
>>>>>>>>
>>>>>>>> Here is the info:
>>>>>>>>
>>>>>>>> INFO - Creating dedicated application classloader for classpath.ear
>>>>>>>>
>>>>>>>> It is in Assembler if someone wants to have a look , look for this:
>>>>>>>>
>>>>>>>>
>>>>>>>> if (skipLoaderIfPossible) { ...
>>>>>>>>
>>>>>>>>
>>>>>>>> Surely a File.equals issue or something like that.
>>>>>>>>
>>>>>>>>
>>>>>>>> We can log all files in debug mode and activate debug for this
>>>>>>>>
>>>>>>> sample
>>>
>>>> to go further
>>>>>>>>
>>>>>>>>
>>>>>>>> wdyt?
>>>>>>>>
>>>>>>>>
>>>>>>>> I'll try to find some time to debug further tonight if nobody
>>>>>>>>
>>>>>>> already
>>>
>>>> did
>>>>>>>> it
>>>>>>>>
>>>>>>>>
>>>>>>>> Then we should be green everywhere even on trunk ;)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Romain Manni-Bucau
>>>>>>>> Twitter: @rmannibucau
>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>> Andy Gumbrecht
>>>>>
>>>>> http://www.tomitribe.com
>>>>> agumbrecht@tomitribe.com
>>>>> https://twitter.com/AndyGeeDe
>>>>>
>>>>> TomEE treibt Tomitribe! | http://tomee.apache.org
>>>>>
>>>>>
>>>>>
> --
> Andy Gumbrecht
>
> http://www.tomitribe.com
> agumbrecht@tomitribe.com
> https://twitter.com/AndyGeeDe
>
> TomEE treibt Tomitribe! | http://tomee.apache.org
>
>
Re: failling deltaspike-fullstack
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
StatelessInstanceManagerPoolingTest - I have it, and how obvious these
things are when you find them! :-D
javax.ejb.ConcurrentAccessTimeoutException in the threads due to 100ms
timeout - It's not checked, and so explode is/was not always called.
Andy.
On 21/07/2014 13:22, Romain Manni-Bucau wrote:
> hehe, now I think to it you are surely right ;)
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-07-21 13:19 GMT+02:00 Jean-Louis Monteiro <jl...@tomitribe.com>:
>
>> Which channel? That was maybe the reason :p
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Mon, Jul 21, 2014 at 1:17 PM, Romain Manni-Bucau <rmannibucau@gmail.com
>> wrote:
>>
>>> well the point is we shouldn't end the method without ensuring all thread
>>> are done. join is brutal but the most sure way to do so.
>>>
>>> Main issue on this test is buildbot since locally it fails very very
>> rarely
>>> (got it once watching tv on the computer during the build ;))
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>> 2014-07-21 12:47 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>
>>>> +1
>>>>
>>>> Side note: I have been looking at the 'sometimes' failing
>>>> StatelessInstanceManagerPoolingTest.
>>>>
>>>> The issue is not the Thread.join, I tried the same fix but does not
>> work
>>> -
>>>> If we join on each thread then we get a better chance, but only due to
>>>> forcing threads to run sequentially and timing.
>>>> The issue is the the teardown is called which calls OpenEJB.destroy.
>> The
>>>> shutdown does not take into account running call contexts and they get
>>>> interrupted.
>>>> This kills the threads in the 'explode' call and more often than not
>> they
>>>> never complete - discardedInstances.incrementAndGet() never gets called
>>>> in this case, and the test fails.
>>>> It seems wrong to me for the destroy to be so aggressive, it should
>>> surely
>>>> give call context threads some time to complete.
>>>>
>>>> Andy.
>>>>
>>>>
>>>> On 21/07/2014 10:17, Romain Manni-Bucau wrote:
>>>>
>>>>> 1.7 is affected as well, we just have luck sometimes since this code
>> is
>>>>> the
>>>>> same. (depend test ordering for some of them but code was clearly
>> wrong)
>>>>> I mainly focused on trunk since it showed some bugs of the 1.7 we
>> can't
>>>>> see
>>>>> while we don't run tests against java 7. All are fixed excepted this
>> one
>>>>> which should be trivial once we have the paths.
>>>>>
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <
>>> jlmonteiro@tomitribe.com
>>>>>> :
>>>>> Looks like we are having issues with examples and I was wondering why
>>>>>> suddenly.
>>>>>> Regarding Apache DS fullstack example, I can give that a try if Andy
>>> does
>>>>>> not have time.
>>>>>>
>>>>>> Well, while trunk is important, I think we must focus on the branch
>>> until
>>>>>> it gets released.
>>>>>>
>>>>>> Jean-Louis
>>>>>>
>>>>>> --
>>>>>> Jean-Louis Monteiro
>>>>>> http://twitter.com/jlouismonteiro
>>>>>> http://www.tomitribe.com
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <
>>>>>> rmannibucau@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>> Hi
>>>>>>> this sample is failing on buildbot cause we don't find all jars from
>>> the
>>>>>>> app in the classloader (which is wrong since it is embedded ;)).
>>>>>>>
>>>>>>> Here is the info:
>>>>>>>
>>>>>>> INFO - Creating dedicated application classloader for classpath.ear
>>>>>>>
>>>>>>> It is in Assembler if someone wants to have a look , look for this:
>>>>>>>
>>>>>>>
>>>>>>> if (skipLoaderIfPossible) { ...
>>>>>>>
>>>>>>>
>>>>>>> Surely a File.equals issue or something like that.
>>>>>>>
>>>>>>>
>>>>>>> We can log all files in debug mode and activate debug for this
>> sample
>>>>>>> to go further
>>>>>>>
>>>>>>>
>>>>>>> wdyt?
>>>>>>>
>>>>>>>
>>>>>>> I'll try to find some time to debug further tonight if nobody
>> already
>>>>>>> did
>>>>>>> it
>>>>>>>
>>>>>>>
>>>>>>> Then we should be green everywhere even on trunk ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>> --
>>>> Andy Gumbrecht
>>>>
>>>> http://www.tomitribe.com
>>>> agumbrecht@tomitribe.com
>>>> https://twitter.com/AndyGeeDe
>>>>
>>>> TomEE treibt Tomitribe! | http://tomee.apache.org
>>>>
>>>>
--
Andy Gumbrecht
http://www.tomitribe.com
agumbrecht@tomitribe.com
https://twitter.com/AndyGeeDe
TomEE treibt Tomitribe! | http://tomee.apache.org
Re: failling deltaspike-fullstack
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hehe, now I think to it you are surely right ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-07-21 13:19 GMT+02:00 Jean-Louis Monteiro <jl...@tomitribe.com>:
> Which channel? That was maybe the reason :p
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Jul 21, 2014 at 1:17 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > well the point is we shouldn't end the method without ensuring all thread
> > are done. join is brutal but the most sure way to do so.
> >
> > Main issue on this test is buildbot since locally it fails very very
> rarely
> > (got it once watching tv on the computer during the build ;))
> >
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> >
> > 2014-07-21 12:47 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> >
> > > +1
> > >
> > > Side note: I have been looking at the 'sometimes' failing
> > > StatelessInstanceManagerPoolingTest.
> > >
> > > The issue is not the Thread.join, I tried the same fix but does not
> work
> > -
> > > If we join on each thread then we get a better chance, but only due to
> > > forcing threads to run sequentially and timing.
> > > The issue is the the teardown is called which calls OpenEJB.destroy.
> The
> > > shutdown does not take into account running call contexts and they get
> > > interrupted.
> > > This kills the threads in the 'explode' call and more often than not
> they
> > > never complete - discardedInstances.incrementAndGet() never gets called
> > > in this case, and the test fails.
> > > It seems wrong to me for the destroy to be so aggressive, it should
> > surely
> > > give call context threads some time to complete.
> > >
> > > Andy.
> > >
> > >
> > > On 21/07/2014 10:17, Romain Manni-Bucau wrote:
> > >
> > >> 1.7 is affected as well, we just have luck sometimes since this code
> is
> > >> the
> > >> same. (depend test ordering for some of them but code was clearly
> wrong)
> > >>
> > >> I mainly focused on trunk since it showed some bugs of the 1.7 we
> can't
> > >> see
> > >> while we don't run tests against java 7. All are fixed excepted this
> one
> > >> which should be trivial once we have the paths.
> > >>
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> Twitter: @rmannibucau
> > >> Blog: http://rmannibucau.wordpress.com/
> > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >> Github: https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <
> > jlmonteiro@tomitribe.com
> > >> >:
> > >>
> > >> Looks like we are having issues with examples and I was wondering why
> > >>> suddenly.
> > >>> Regarding Apache DS fullstack example, I can give that a try if Andy
> > does
> > >>> not have time.
> > >>>
> > >>> Well, while trunk is important, I think we must focus on the branch
> > until
> > >>> it gets released.
> > >>>
> > >>> Jean-Louis
> > >>>
> > >>> --
> > >>> Jean-Louis Monteiro
> > >>> http://twitter.com/jlouismonteiro
> > >>> http://www.tomitribe.com
> > >>>
> > >>>
> > >>> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <
> > >>> rmannibucau@gmail.com
> > >>> wrote:
> > >>>
> > >>> Hi
> > >>>>
> > >>>> this sample is failing on buildbot cause we don't find all jars from
> > the
> > >>>> app in the classloader (which is wrong since it is embedded ;)).
> > >>>>
> > >>>> Here is the info:
> > >>>>
> > >>>> INFO - Creating dedicated application classloader for classpath.ear
> > >>>>
> > >>>> It is in Assembler if someone wants to have a look , look for this:
> > >>>>
> > >>>>
> > >>>> if (skipLoaderIfPossible) { ...
> > >>>>
> > >>>>
> > >>>> Surely a File.equals issue or something like that.
> > >>>>
> > >>>>
> > >>>> We can log all files in debug mode and activate debug for this
> sample
> > >>>> to go further
> > >>>>
> > >>>>
> > >>>> wdyt?
> > >>>>
> > >>>>
> > >>>> I'll try to find some time to debug further tonight if nobody
> already
> > >>>> did
> > >>>> it
> > >>>>
> > >>>>
> > >>>> Then we should be green everywhere even on trunk ;)
> > >>>>
> > >>>>
> > >>>>
> > >>>> Romain Manni-Bucau
> > >>>> Twitter: @rmannibucau
> > >>>> Blog: http://rmannibucau.wordpress.com/
> > >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>>> Github: https://github.com/rmannibucau
> > >>>>
> > >>>>
> > > --
> > > Andy Gumbrecht
> > >
> > > http://www.tomitribe.com
> > > agumbrecht@tomitribe.com
> > > https://twitter.com/AndyGeeDe
> > >
> > > TomEE treibt Tomitribe! | http://tomee.apache.org
> > >
> > >
> >
>
Re: failling deltaspike-fullstack
Posted by agumbrecht <ag...@tomitribe.com>.
-----
--
Andy Gumbrecht
http://www.tomitribe.com
agumbrecht@tomitribe.com
https://twitter.com/AndyGeeDe
TomEE treibt Tomitribe ! | http://tomee.apache.org
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/failling-deltaspike-fullstack-tp4670567p4670586.html
Sent from the TomEE Dev mailing list archive at Nabble.com.
Re: failling deltaspike-fullstack
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Which channel? That was maybe the reason :p
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, Jul 21, 2014 at 1:17 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> well the point is we shouldn't end the method without ensuring all thread
> are done. join is brutal but the most sure way to do so.
>
> Main issue on this test is buildbot since locally it fails very very rarely
> (got it once watching tv on the computer during the build ;))
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-07-21 12:47 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>
> > +1
> >
> > Side note: I have been looking at the 'sometimes' failing
> > StatelessInstanceManagerPoolingTest.
> >
> > The issue is not the Thread.join, I tried the same fix but does not work
> -
> > If we join on each thread then we get a better chance, but only due to
> > forcing threads to run sequentially and timing.
> > The issue is the the teardown is called which calls OpenEJB.destroy. The
> > shutdown does not take into account running call contexts and they get
> > interrupted.
> > This kills the threads in the 'explode' call and more often than not they
> > never complete - discardedInstances.incrementAndGet() never gets called
> > in this case, and the test fails.
> > It seems wrong to me for the destroy to be so aggressive, it should
> surely
> > give call context threads some time to complete.
> >
> > Andy.
> >
> >
> > On 21/07/2014 10:17, Romain Manni-Bucau wrote:
> >
> >> 1.7 is affected as well, we just have luck sometimes since this code is
> >> the
> >> same. (depend test ordering for some of them but code was clearly wrong)
> >>
> >> I mainly focused on trunk since it showed some bugs of the 1.7 we can't
> >> see
> >> while we don't run tests against java 7. All are fixed excepted this one
> >> which should be trivial once we have the paths.
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >> 2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <
> jlmonteiro@tomitribe.com
> >> >:
> >>
> >> Looks like we are having issues with examples and I was wondering why
> >>> suddenly.
> >>> Regarding Apache DS fullstack example, I can give that a try if Andy
> does
> >>> not have time.
> >>>
> >>> Well, while trunk is important, I think we must focus on the branch
> until
> >>> it gets released.
> >>>
> >>> Jean-Louis
> >>>
> >>> --
> >>> Jean-Louis Monteiro
> >>> http://twitter.com/jlouismonteiro
> >>> http://www.tomitribe.com
> >>>
> >>>
> >>> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <
> >>> rmannibucau@gmail.com
> >>> wrote:
> >>>
> >>> Hi
> >>>>
> >>>> this sample is failing on buildbot cause we don't find all jars from
> the
> >>>> app in the classloader (which is wrong since it is embedded ;)).
> >>>>
> >>>> Here is the info:
> >>>>
> >>>> INFO - Creating dedicated application classloader for classpath.ear
> >>>>
> >>>> It is in Assembler if someone wants to have a look , look for this:
> >>>>
> >>>>
> >>>> if (skipLoaderIfPossible) { ...
> >>>>
> >>>>
> >>>> Surely a File.equals issue or something like that.
> >>>>
> >>>>
> >>>> We can log all files in debug mode and activate debug for this sample
> >>>> to go further
> >>>>
> >>>>
> >>>> wdyt?
> >>>>
> >>>>
> >>>> I'll try to find some time to debug further tonight if nobody already
> >>>> did
> >>>> it
> >>>>
> >>>>
> >>>> Then we should be green everywhere even on trunk ;)
> >>>>
> >>>>
> >>>>
> >>>> Romain Manni-Bucau
> >>>> Twitter: @rmannibucau
> >>>> Blog: http://rmannibucau.wordpress.com/
> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>> Github: https://github.com/rmannibucau
> >>>>
> >>>>
> > --
> > Andy Gumbrecht
> >
> > http://www.tomitribe.com
> > agumbrecht@tomitribe.com
> > https://twitter.com/AndyGeeDe
> >
> > TomEE treibt Tomitribe! | http://tomee.apache.org
> >
> >
>
Re: failling deltaspike-fullstack
Posted by Romain Manni-Bucau <rm...@gmail.com>.
well the point is we shouldn't end the method without ensuring all thread
are done. join is brutal but the most sure way to do so.
Main issue on this test is buildbot since locally it fails very very rarely
(got it once watching tv on the computer during the build ;))
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-07-21 12:47 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> +1
>
> Side note: I have been looking at the 'sometimes' failing
> StatelessInstanceManagerPoolingTest.
>
> The issue is not the Thread.join, I tried the same fix but does not work -
> If we join on each thread then we get a better chance, but only due to
> forcing threads to run sequentially and timing.
> The issue is the the teardown is called which calls OpenEJB.destroy. The
> shutdown does not take into account running call contexts and they get
> interrupted.
> This kills the threads in the 'explode' call and more often than not they
> never complete - discardedInstances.incrementAndGet() never gets called
> in this case, and the test fails.
> It seems wrong to me for the destroy to be so aggressive, it should surely
> give call context threads some time to complete.
>
> Andy.
>
>
> On 21/07/2014 10:17, Romain Manni-Bucau wrote:
>
>> 1.7 is affected as well, we just have luck sometimes since this code is
>> the
>> same. (depend test ordering for some of them but code was clearly wrong)
>>
>> I mainly focused on trunk since it showed some bugs of the 1.7 we can't
>> see
>> while we don't run tests against java 7. All are fixed excepted this one
>> which should be trivial once we have the paths.
>>
>>
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>> 2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <jlmonteiro@tomitribe.com
>> >:
>>
>> Looks like we are having issues with examples and I was wondering why
>>> suddenly.
>>> Regarding Apache DS fullstack example, I can give that a try if Andy does
>>> not have time.
>>>
>>> Well, while trunk is important, I think we must focus on the branch until
>>> it gets released.
>>>
>>> Jean-Louis
>>>
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>>
>>>
>>> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com
>>> wrote:
>>>
>>> Hi
>>>>
>>>> this sample is failing on buildbot cause we don't find all jars from the
>>>> app in the classloader (which is wrong since it is embedded ;)).
>>>>
>>>> Here is the info:
>>>>
>>>> INFO - Creating dedicated application classloader for classpath.ear
>>>>
>>>> It is in Assembler if someone wants to have a look , look for this:
>>>>
>>>>
>>>> if (skipLoaderIfPossible) { ...
>>>>
>>>>
>>>> Surely a File.equals issue or something like that.
>>>>
>>>>
>>>> We can log all files in debug mode and activate debug for this sample
>>>> to go further
>>>>
>>>>
>>>> wdyt?
>>>>
>>>>
>>>> I'll try to find some time to debug further tonight if nobody already
>>>> did
>>>> it
>>>>
>>>>
>>>> Then we should be green everywhere even on trunk ;)
>>>>
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
> --
> Andy Gumbrecht
>
> http://www.tomitribe.com
> agumbrecht@tomitribe.com
> https://twitter.com/AndyGeeDe
>
> TomEE treibt Tomitribe! | http://tomee.apache.org
>
>
Re: failling deltaspike-fullstack
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
+1
Side note: I have been looking at the 'sometimes' failing
StatelessInstanceManagerPoolingTest.
The issue is not the Thread.join, I tried the same fix but does not work
- If we join on each thread then we get a better chance, but only due to
forcing threads to run sequentially and timing.
The issue is the the teardown is called which calls OpenEJB.destroy. The
shutdown does not take into account running call contexts and they get
interrupted.
This kills the threads in the 'explode' call and more often than not
they never complete - discardedInstances.incrementAndGet() never gets
called in this case, and the test fails.
It seems wrong to me for the destroy to be so aggressive, it should
surely give call context threads some time to complete.
Andy.
On 21/07/2014 10:17, Romain Manni-Bucau wrote:
> 1.7 is affected as well, we just have luck sometimes since this code is the
> same. (depend test ordering for some of them but code was clearly wrong)
>
> I mainly focused on trunk since it showed some bugs of the 1.7 we can't see
> while we don't run tests against java 7. All are fixed excepted this one
> which should be trivial once we have the paths.
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <jl...@tomitribe.com>:
>
>> Looks like we are having issues with examples and I was wondering why
>> suddenly.
>> Regarding Apache DS fullstack example, I can give that a try if Andy does
>> not have time.
>>
>> Well, while trunk is important, I think we must focus on the branch until
>> it gets released.
>>
>> Jean-Louis
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <rmannibucau@gmail.com
>> wrote:
>>
>>> Hi
>>>
>>> this sample is failing on buildbot cause we don't find all jars from the
>>> app in the classloader (which is wrong since it is embedded ;)).
>>>
>>> Here is the info:
>>>
>>> INFO - Creating dedicated application classloader for classpath.ear
>>>
>>> It is in Assembler if someone wants to have a look , look for this:
>>>
>>>
>>> if (skipLoaderIfPossible) { ...
>>>
>>>
>>> Surely a File.equals issue or something like that.
>>>
>>>
>>> We can log all files in debug mode and activate debug for this sample
>>> to go further
>>>
>>>
>>> wdyt?
>>>
>>>
>>> I'll try to find some time to debug further tonight if nobody already did
>>> it
>>>
>>>
>>> Then we should be green everywhere even on trunk ;)
>>>
>>>
>>>
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
--
Andy Gumbrecht
http://www.tomitribe.com
agumbrecht@tomitribe.com
https://twitter.com/AndyGeeDe
TomEE treibt Tomitribe! | http://tomee.apache.org
Re: failling deltaspike-fullstack
Posted by Romain Manni-Bucau <rm...@gmail.com>.
1.7 is affected as well, we just have luck sometimes since this code is the
same. (depend test ordering for some of them but code was clearly wrong)
I mainly focused on trunk since it showed some bugs of the 1.7 we can't see
while we don't run tests against java 7. All are fixed excepted this one
which should be trivial once we have the paths.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-07-21 10:09 GMT+02:00 Jean-Louis Monteiro <jl...@tomitribe.com>:
> Looks like we are having issues with examples and I was wondering why
> suddenly.
> Regarding Apache DS fullstack example, I can give that a try if Andy does
> not have time.
>
> Well, while trunk is important, I think we must focus on the branch until
> it gets released.
>
> Jean-Louis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Hi
> >
> > this sample is failing on buildbot cause we don't find all jars from the
> > app in the classloader (which is wrong since it is embedded ;)).
> >
> > Here is the info:
> >
> > INFO - Creating dedicated application classloader for classpath.ear
> >
> > It is in Assembler if someone wants to have a look , look for this:
> >
> >
> > if (skipLoaderIfPossible) { ...
> >
> >
> > Surely a File.equals issue or something like that.
> >
> >
> > We can log all files in debug mode and activate debug for this sample
> > to go further
> >
> >
> > wdyt?
> >
> >
> > I'll try to find some time to debug further tonight if nobody already did
> > it
> >
> >
> > Then we should be green everywhere even on trunk ;)
> >
> >
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
>
Re: failling deltaspike-fullstack
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Looks like we are having issues with examples and I was wondering why
suddenly.
Regarding Apache DS fullstack example, I can give that a try if Andy does
not have time.
Well, while trunk is important, I think we must focus on the branch until
it gets released.
Jean-Louis
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Mon, Jul 21, 2014 at 8:41 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi
>
> this sample is failing on buildbot cause we don't find all jars from the
> app in the classloader (which is wrong since it is embedded ;)).
>
> Here is the info:
>
> INFO - Creating dedicated application classloader for classpath.ear
>
> It is in Assembler if someone wants to have a look , look for this:
>
>
> if (skipLoaderIfPossible) { ...
>
>
> Surely a File.equals issue or something like that.
>
>
> We can log all files in debug mode and activate debug for this sample
> to go further
>
>
> wdyt?
>
>
> I'll try to find some time to debug further tonight if nobody already did
> it
>
>
> Then we should be green everywhere even on trunk ;)
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>