Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [glassfish-dev] Splitting up the jakarta work
Hi,

That might be the case. The strange thing is that the job has an internal retry mechanism, but that doesn't seem to influence the random failure. If it fails the first time on a pod/jenkins-slave, it keeps failing. But if you restart the entire pipeline (schedule a new job), then it may not fail again. 

It's of course absolutely possible (and even likely) it's a result of my bean validation changes, but it's hard to see at the moment why it's failing so randomly. Maybe it has to do with class loader order, and once a pod has somehow(?) established an order it sticks to it, but a new pod may choose a new order. I'm just thinking out loud here.

I've filed this bug for it, just in case; https://bugs.eclipse.org/bugs/show_bug.cgi?id=561229

Kind regards,
Arjan




On Wed, Mar 25, 2020 at 4:37 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:


On Wed, Mar 25, 2020 at 11:25 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Small heads-up, I'm still investigating the Jenkins failure described below. It's all going super-slow and time to dedicate to it is limited, but I've got some pointers to investigate.

In January (I think), I did see some Eclipse Jenkins jakarta-tck CI when running more than one TCK build at a time, that looked like they could be caused by a lack of CPU cores or memory.  I didn't try tuning any of the related "resources" for TCK testing yet but would like to at some point.

I wonder if either of the below linked Jenkins job defined (or default) resources need some tuning to reflect actual available CPU cores/memory?  


[2020-03-19T19:57:14.850Z]     name: "glassfish-ci"
[2020-03-19T19:57:14.850Z]     resources:
[2020-03-19T19:57:14.850Z]       limits:
[2020-03-19T19:57:14.850Z]         memory: "7Gi"
[2020-03-19T19:57:14.850Z]         cpu: "3"

[2020-03-19T19:57:14.850Z]       requests: {}

[2020-03-19T19:57:14.850Z]     name: "jnlp"
[2020-03-19T19:57:14.850Z]     resources:
[2020-03-19T19:57:14.850Z]       limits:
[2020-03-19T19:57:14.850Z]         memory: "1Gi"
[2020-03-19T19:57:14.850Z]         cpu: "1"

[2020-03-19T19:57:14.850Z]       requests: {}
Scott
 Kind regards,
Arjan

On Mon, Mar 23, 2020 at 6:11 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

In parallel to this I've spend time updating some of the dependencies. Unfortunately after working on Bean Validation, randomly in some tests GlassFish doesn't fully boot on Eclipse Jenkins, causing the asadmin start-domain command to time out.

Debugging this is hideously difficult due to the randomness of the hangs.

The master branch also has some seemingly random failures: https://ci.eclipse.org/glassfish/job/glassfish/job/master/

Kind regards,
Arjan



On Mon, Mar 23, 2020 at 4:42 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Same thing is discussed in this JSON-P PR integration https://github.com/eclipse-ee4j/glassfish/pull/22943 where JSON-P should have a small impact given it is a new api but it needs an updated Jersey or the server won’t start.

 

Steve

 

From: glassfish-dev-bounces@xxxxxxxxxxx <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Steve Millidge (Payara)
Sent: 23 March 2020 15:40
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] Splitting up the jakarta work

 

Problem is the code doesn’t compile unless we potentially go through an implementation phase when we support two versions of the library e.g. Jakarta Transactions at the same time with both javax and Jakarta as dependencies which means adding the new dependency in some places then unpicking it later. Which seems brittle.

 

For example I tried to add Jakarta Transactions as it is needed for Jakarta Connectors. So I started changing namespace of references to it in the code base. Unfortunately it is used in public javax EJB apis so now the GlassFish EJB code does not implement javax.ejb interfaces so I need to update EJB to use Jakarta namespace and so on and so on…

 

I’m tempted to change all namespace in one go and fix compilation errors but then I suspect I will also need all the upstream implementation projects to be ready that are not part of GlassFish or I suspect the server won’t start with OSGI errors. Yuk.

 

 

Steve

 

From: glassfish-dev-bounces@xxxxxxxxxxx <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Russell Gold
Sent: 23 March 2020 15:32
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] Splitting up the jakarta work

 

Can this not be one, one library at a time? That is, each PR handles the changes for the library and all of its references, but no more? 

 

Russ

 

On Mar 23, 2020, at 11:29 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

 

I recently started trying to do the work to integrate Jakarta connectors namespace change as the implementation of the api is in core GlassFish. However to do so I also had to start doing the work on Jakarta transactions. Also now I’ve hit that I also need to do all the changes for EJB as well or GlassFish won’t compile. I have a horrible suspicion that this change is likely going to suck in a lot of the apis and hit a huge chunk of the code base.

 

Does anybody have any good ideas on how to work in parallel on a lot of this work?

 

I’m starting to think that a large chunk of the work is going to have to be done in one go in one PR!

 

Does anybody have a better idea?

 

Steve

 

 

_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!KCrJfd9RxFJu3Yvq84Jj8UgY83QDwEKWPYX5Hw-_GeC1B3j0wOFQUWQ7x_RKjmE-7w$

 

_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev

Back to the top